When open source isn't (open enough)

Some open-source software may not be open enough. While "open source" refers to software's underlying license and its adherence to the Open Source Definition, there are numerous examples of open-source projects that offer an open license but a relatively closed development process.

But is it open enough?

(Credit: Open Source Initiative)

It's been called "fauxpen source" and worse, but we may have to get used to it. It seems to be the new normal in open-source development. Only open source foundations like Eclipse, Apache Software Foundation, and Mozilla appear to be able to escape it completely.

Java is one example people cite of "fauxpen-ness." SAP CTO Vishal Sikka on Monday called for a more open process for Java development, arguing that Sun too tightly controls Java's development. It's a complaint that has plagued the Java community for years.

Not that Java is alone. While Google gets plaudits for its open-source investments, some are quick to allege that Google maintains a closed Android community. The same sort of complaints have arisen over Google's management of Chrome and Chrome OS.

Even Red Hat, the quintessential open-source company, is primarily known for what it distributes, not what it develops. Red Hat, of course, works alongside IBM and other corporate and unaffiliated developers to write the Linux kernel, and scrupulously releases its software under open-source licenses.

But when it comes to development of its Red Hat Enterprise Linux distribution or development of its JBoss middleware or other technologies (e.g., KVM), good luck finding many significant external contributors.

MySQL? It's largely the same. The company (now Sun Microsystems) does virtually all of its own development, which is true of every commercial open-source company of which I'm aware. This is one reason Richard Stallman can unblushingly worry about MySQL's openness despite the fact that it uses his preferred GPL license.

Open source, but not necessarily open process.

There are very good reasons that Google, Red Hat, MySQL, and others keep a tight grip on their open-source development efforts. They are responsible--fiscally and legally--to their customers, and have to be able to guarantee quality and security. Understandably, they exercise some control to ensure the products they ship protect the integrity of their brands.

But such corporate open source indicates a real divide between "open source" as a license and "open source" as a wholly transparent way of developing and distributing software. The former is now common and relatively easy. The latter, quite simply, is not.

The companies that seem to do it best are those that don't rely on direct monetization of open-source software. In other words, if you aren't selling open source, it's easier to be open. Doc Searls captures this brilliantly by arguing "you make money because of [open source], not with it."

Examples abound. IBM is a good example. So is Google, though I agree with its critics that it can do better. Facebook, Oracle, and others also provide examples.

In the future, I think we'll see this "fauxpen-ness" fade as companies clearly separate their open-source efforts from their revenue models. Open source can provide a platform for monetization, but it isn't the best way to actually generate cash. Not for most companies, anyway.

[jrepenning]

I agree totally with what you say about the examples you cite, but you've left out a significant portion of the "Open Source Development" world, the Apache family of projects.

Apache projects do "Open Development (of Source)", not just "Development of (Open) Source." Apache projects are not, typically, created predominantly by a single commercial entity. For example, only about 25% of the work that created Subversion came off the CollabNet payroll. But Apache projects are, typically, staffed predominantly by people with "day jobs" that encourage their contributions, because the commercial entities benefit from the projects.

Unlike "open core" arrangements, Apache contributors aren't expecting to make their money directly off the open software. Unlike "open complement" arrangements, Apache contributors aren't farming the open communitissimals for something approaching advertising value. Apache contributors are filling infrastructure pot-holes, so they can get on with the interesting (and profitable) work.

[pentest]

But apache tightly controls commit rights. Sure anyone can fork it, but contribute to the mainline?

[atici]

But why should open source or open process be the goal? I think there are great examples of software that are closed source or closed process based. What gives anyone right to demand for source code or development process to be open?

[jake3373]

People aren't "demanding" for the source code. Most users of Firefox, for example, could really care less about the source. Keeping the source open is a good way to allow other people to examine the code and report bugs or security holes, or use the code in their own applications (with limitations in the open-source license - for example, GPL says that code under the GPL license can only be used in other open-source projects). I personally am a great fan of open source. I try to open-source everything I create (except critical security components).

[Orion Blastar]

Well without Firefox there wouldn't have been improvements made to Internet Explorer nor a Google Chrome or Apple Safari. We'd still be stuck with Internet Explorer, Opera, and maybe a few generic web browsers.

Mac OSX would still be using IE 5.0 for OSX with no Safari as there would have been no KHTML made to compete with Firefox that Safari is based on.

IE 7 and 8 wouldn't be as advanced, or have tabs, or any other advanced feature and be just a simple web browser.

Opera wouldn't have evolved to were it is now and still would have been commercial and adware instead of free.

Google would not have a web browser, as they wouldn't have an example of Firefox to follow after.

[bschmock]

Firefox really did change the web browser community. Although If I remember right safari came out with a public beta a few months before Firefox, perhaps im wrong but that's what I remember. Although I also remember how ****** safari was and how much I loved Firefox. And I though before safari mac used Netscape at least that's what I remember using in grade school. Netscape also sucked it hard.

[tzs108]

Firefox initial release:November 9, 2004

Safari initial release: January 7, 2003.

KHTML: November 4, 1998.

Bschmock is correct. Your timeline is completely screwed up.

[Rants&Raves]

You are right that companies have an obligation to insist that code be safe to use by customers (existing and future). Let`s take a step back though:

The area where open source contributors are great at include massively collaborating on core code, or going off on a tangent on pet projects. They`re great at that. What they generally suck at is building testing & other quality-assurance systems (regression testing, that sort of thing -- which can be, granted, insanely boring) and drawing roadmaps for future development.

So, if a company wants to get the benefits of open source (and save a lot on development time), then they should define and impose the roadmap AND have its own in-house developers write regression tests, unit tests, and functional tests to insure that whatever is written falls within a closely-defined set of self-validation tools.

Besides, the test writers are much cheaper than other developers (although you typically can't keep them around in that position for very long), so you save both ways.

[billburke]

I don't think its fair to put JBoss within this fauxpen source label. We hire from our community and sometimes we hire faster than we recruit external contributors. Its actually fairly easy to become a committer (just actually do something!). I have about 8 contributors to my little project that I run alone. I know others can boast similar numbers. In fact, I'd say that in many cases we are more open than other organization like Apache. We just don't have the bureaucrats that many of these organizations have (just search my blog for a few of the stories).

[ITRebel]

Matt,

You sometimes seem to forget that the purpose of software in business is to make money. It is not to prove how open you can be. In fact, it is usually the case that being open will make you a lot less money, which you do seem to hint at finally in this post. The value of purely open source products is certainly questionable. Even though Sun paid a lot for MySQL, they should have simply forked it and they might still be separate from Oracle. Amazon has the right approach; you fork what you can. The end result though is that the value of open source commodity software continues to go downhill.

[Thad Boyd]

Did you RTFA, ITRebel? Matt quite clearly draws a distinction between open-source software and revenue-generating software.

Your idea sounds good in theory, but can you think of a fork of an open-source project that has really been a moneymaker for a corporate owner? And no, IE very definitely does not count.

[jrepenning]

"The value of open-source commodity software" can be evaluated several ways.

- Its price starts out low (free), and doesn't change much.
- Its ability to create eye-popping IPOs may be on the wane.
- Its contribution to end-user productivity seems to be rising strongly.

It's funny ITRebel accuses Matt of focusing on openness over profit: the accusations have gone the other way at least as often. If you catch flak from both sides, does that mean you're in the middle of the road?

[Thad Boyd]

An excellent point, Matt. Apple, of course, had its knuckles rapped for WebKit, which was open in name but not well-documented, and has improved on that score.

[fedoraguy]

In regards to RHEL, I would argue that since Red Hat has given Core to the Fedora community they have in many ways benefitted. The community has added many features and functionality to Fedora that ultimately goes into RHEL (and other distros), while Red Hat continues to play a strong part in making the Fedora code reliable and more suitable for mission-critical applications. The relationship is such where the community can drive one distribution and RHEL still has a solid, reliable offering for it's customers.

[shusseina2]

Ingres, the maker of the open source database of the same name, the Icebreaker BI Appliance, the Icebreaker DB Appliance and the Icebreaker ECM Appliance, is very open to contributions from the community. I coded a bug fix for them (which I have yet to submit) and they were very welcoming, to the point that I wish I had more time to contribute.

The arguments for why Google, Red Hat, MySQL and others keep a tight grip on their open-source development efforts do not stack up. I'm sure these companies have stringent QA procedures which would protect their products from poor outside contributions. In any case, open source software from Mozilla, Apache and the like have shown outside contributions are of the highest quality.

[dave_neary]

"Even Red Hat, the quintessential open-source company, is primarily known for what it distributes, not what it develops"

At least in the GNOME community, that is because Red Hat has always worked discretely, but effectively, within the community, rather than trying to put their stamp on everything. Printing works on Linux now? Red Hat did much of that. Wifi Just Works? Red Hat was behind much of that work. Plugging in USB drives Just Works? Red Hat's behind that too, for the most part.

Cheers,
Dave.

[pentest]

CUPS is developed by Apple, something people tend to forget.

[pentest]

The best programming languages are tightly controlled.

Python- OSS, but controlled - Great language
Perl- OSS, but controlled - Great language
Ruby- OSS, but controlled - Outstanding language, interpreter needs some work.
Java- sort of OSS, but controlled - Great language
C open,but developed by committee(a smart committee)-awesome language.
C++ open, but developed by committee- Horrible bloated mess of a language
PHP- open but who cares? It is an insecure hacked up mess. Makes VB seem like a legitimate language.