Fauxpen Source?

(Updates at the end)

In 2006, some of the interesting conversations at OSCON were around the relevancy of the open source definition when it came to software-as-a-service. Tim O’Reilly suggested open source licenses are obsolete, in the sense that “because their conditions are all triggered by the act of software distribution, they fail to apply to many of the most important types of software today, namely Web 2.0 applications and other forms of software as a service.”

Last week, in the context of preparing the session calendar for OSCON 2007, Nat Torkington asked “Is ‘Open Source’ Now Completely Meaningless?”

He’s reacting to this Jeff Vance piece: “Ten Leading Open Source Innovators,” which included a number of companies that either don’t use an OSI-approved license, or don’t provide source code at all but sell software to run on open source platforms. (He also points to Chris DiBona’s similar complaint: “My outrage is quite present, I assue you“).

Nat writes:

Can you really call yourself open source if you haven’t opened the source? I don’t think so. There’s a flood of “open source” companies selling things that work on open source but which aren’t open source themselves. I think these are proprietary products, not open source. That’s been the attitude that helped me select talks for OSCON–I only want open source products talked about. My rule of thumb is that the audience should be able to download, compile, and use the software that is talked about.

I think this is much too literal a definition of what the phrase “an open source company” can mean. While I can understand the need to preserve a meaningful definition of open source software, is it meaningful to maintain a distinction between open source and non-open-source companies?

Is the difference one of degree (what percentage of the software being discussed can be accessed as source code and used without restriction) or kind (some more fundamental difference of mission or organizing principle)?

I often describe Optaros as “an open source consulting company” – but that doesn’t mean that all of the solutions we’ve delivered to clients are 100% open source. (<disclaimer>I speak for myself here, not as a company spokesperson</disclaimer>).

We encourage clients, when custom coding is necessary to extend or enhance an open source project in the process of developing a solution, to contribute that code (or allow us to do so) to the appropriate communities. Many of the solutions we’ve built are hybrids of open and proprietary software, and clients have the right to not release enhancements they make, or pay to have made, to open source projects. (Even under GPL v2, modification for private use – not distribution – does not require source code release).

Would or should we (or anyone else in the same scenario) be prevented from speaking at OSCON about a solution we delivered, if source code cannot be provided for some portions of the total solution?

What if the solution utilizes proprietary (third-party purchased) software for some specific, but not solution-critical piece?

(Former Optaros colleague) Stephen Walli suggests that the need is to distinguish between projects and products:

First, software projects are interesting buckets of technology. These projects have users and contributors, i.e. a community. Open source has a definition. So does free software. If these projects are open source or free software, then they meet one (or both) of these definitions. Pretty simple really.

Second, products are packaged, installable, tested, documented, supported, and maintained for customers. Companies build products as part of their value proposition to their customers. Another way to say this is that customers buy solutions, not software. Still pretty simple.

So what would it mean, in this context, to consider Optaros an “Open Source Consulting Company,” or an “Open Source Systems Integrator”?
It means we create solutions for customers, leveraging open source projects where possible. We are users, participants, and often contributors in various open source projects, but to our clients we are first and foremost the designers and developers of solutions.

Updates:

Fellow Optaros employee Lukas Kahwe Smith argues that “any company can call itself an ‘open source company’ if its business model depends on being in good standing with an active open source community.” Certainly broadens the conversation, but might be a tough test to apply consistently, since it would be a difficult claim to prove or disprove.

Stephen O’Grady wieghs in reluctantly – “It’s sort of tough to be an ‘open source’ analyst and not weigh in on the subject, much as I don’t like the idea” – and notes that he finds it “difficult to get worked up about firms that want to take a halfway approach in the meantime, as long as they’re a net positive to the open source ecosystem as a whole” – which is in line with Lukas’ perspective, but again difficult to measure. (Was Novell’s deal with Microsoft a net positive to the open source ecosystem?)

Matt Asay put forth this definition: To be “an open source company”:

The company must actually release code as part of its core business. There must be both open source risk and reward in the code it writes and releases. There must be, in other words, some burning of the boats; otherwise, you’re a non-disruptive member of history, not the future. And I believe open source is all about disruption.

This is a kind of mixture of difference-in-degree and difference-in-kind: if you release the important parts (“as part of its core business”) not just some extraneous or insignificant parts, you’re a “real” open source company.