Uncomfortable truths

Neil Gunton has written an interesting article debunking some common Open Source myths. I agree with most of what he says, and have made similar points myself in the past. Some of the Slashdot thread ensuing from Neil's article is predictable - software is theft, all commercial software needs can be met by HobbyHackers, gratis vs libre blah blah blah, but some of the people commenting do understand and agree with Neil's points, which is refreshing. I don't believe that either closed or open development is necessarily better than the alternative approach. I've seen some goddam awful closed source products, and some equally bad open source ones. Some people inside Sun seem to believe that Closed Source is a dead development model, but I personally just don't buy it. Both open and closed source approaches can yield high quality products with short development times, the key factor is the the team who are working on the project and the tools and techniques they are using, not whether they are from Lilliput or Blefuscu.

There seems also to be a great deal of confusion over the interpretation of the term 'Open Source'. Quite often people assume it necessarily implies Open Development, but I believe the two concepts are entirely different:

  • Open Source
    The source code for a piece of software is available without restriction or cost.
  • Open Development
    Anyone who is so inclined is able to contribute to a project without restriction.

Whilst Open Source undoubtedly exists, I'm not so sure that Open Development in the widest sense actually does. I've been looking at several Open Source databases over the last couple of days, and to take just one example, while MySQL is Open Source, it certainly isn't Open Development. Although it is possible to get patches back in to MySQL, it has to be done by submitting them to the MySQL developers, and when you look at the release notes and development roadmaps for MySQL it is quite clear that MySQL AB (the company) is in complete control of MySQL (the product). Even Linux isn't completely Open Development - Linus keeps a very firm rein on what goes in to Linux, as Bryan Cantrill points out, the Linux LTT folks have been trying to get their stuff integrated for more than five years.

That's not to say there aren't extremely good reasons for this state of affairs - letting everyone who had the whim integrate their changes willy-nilly would lead to anarchy and permanent brokenness. However, when evaluating the 'Openness' of a piece of software, the discussion seems to centre entirely around if it is Open Source - possibly because it's a much easier, almost binary, distinction between 'Open Source' and 'Not Open Source'. Evaluating how a project ranks with regards to Open Development is is much harder - there is a wide continuum of how easy it is to contribute to a project, and of the restrictions which control how you may contribute. MySQL is obviously not Open Development, Linux is more Open Development, but not completely so. Some 'Open Source' projects also require assignment of copyright to the project if any contributions are made. Again there are often very good reasons for this, but it doesn't seem exactly 'Open' if I contribute something and it ends up being owned by someone else.

At the moment Open Source is Soup de Jour, and it is interesting to see how different companies react and adopt their business models to encompass it. It's often convenient for companies to be able to fill in the 'Open Source' checkbox whilst keeping tight control of their intellectual property. I'm not implying this is a necessarily bad thing, after all they have a responsibility to their shareholders to protect their assets. However it's interesting to note the lack of discussion around what access to source code actually means in practical terms. It appears that most of the Open Source bigots can't and/or don't want to distinguish between Open Source and Open Development, and that some companies are taking advantage of this to jump on the Open Source bandwagon whilst continuing to behave exactly as they did before.

Categories : Tech

Re: Uncomfortable truths

You got the definition of 'open source' wrong, unfortunately.

The open source definition [1] does not demand that the source code is available without cost.

Nor does it demand that the source code is available without any restrictions. That would be 'public domain', which is a different beast altogether.

And of course, 'open source' as a class of software licenses does not prescribe how the individuals creating and using the works available under 'open source' licenses interact with each other.

In practice, if you don't like what development model of Linux, MySQL, etc., you just fork the code base and create your own playfield. Then you can set the development model yourself to whichever way of social interaction pleases you. Note that the ability to 'fix' the development model comes from the open source licensing of the software.

If the development model is not to your liking in a software project that's not licensed under an open source license, then you can not 'fix' that. All you can do is cry about it, figuratively speaking. Such crying can be quite annoying for all involved parties, as far as recent history of licensing debates of a popular platform shows.:)

I'd say that 'open source' software licenses encourage 'open development', by reducing the barriers to enter the development [2] , and providing an incentive to participate [3] in the development. The license a work is published under, has nothing to do with its quality, of course.

But, chances are, that with a low barrier of entry, and an incentive to participate, people that are skilled in the creation and modification of such works, would take it up to them and improve the quality of the works in question. And that seems to be how it works in successful open source projects. It's not guaranteed, but it's possible, and seems to happen, ocassionally.

[1] http://www.opensource.org/docs/definition.php

[2] no 'pay-to-play', 'sign those ndas', 'automatic contractual penalties', 'we'll take you to court in a regime of our choice if you don't comply', sort of barriers that are common in non-open-source licenses.

[3] no 'all your code are belong to us', 'for internal reaserch evaluation use on certified platforms only', 'pay-to-use-commercially', 'pay-to-certify', 'pay-to-deploy-internally', 'pay-to-distribute', 'don't you dare say a word about our product's compatibility', and similar funny things that are so common in proprietary software licenses. [4]

[4] http://wwws.sun.com/software/communitysource/j2se/java2/license.html

Re: Uncomfortable truths

Thanks for the comments Dalibor.

I was trying to avoid quoting chapter and verse of the OSI definition, but under item one you are only allowed to charge reasonable distribution costs, not for the software itself - so the software does have to be free. I also said the software should be available 'without restriction or cost', i.e. I was talking about restrictions on the availability of the software rather than restrictions on what you did with it after you had it - i.e. OSS can't require you to sign an NDA in order to obtain it - sorry for not being clearer.

The 'You can always fork' argument is often put forward when anyone points out the restrictions in any particular project's development process. Unfortunately it's a completely unrealistic and inappropriate 'fix' for what is an organisational rather than a technical problem, and it extremely disruptive on all sorts of levels if a fork ever does occur. Take for example the LTT folks who have been trying to get their bits back into Linux for so long - if forking was really a workable option, wouldn't they have done so long ago?

I absolutely agree that Open Source encourages Open Development, and in fact I suspect it is a prerequisite. However the point I'm trying to make is that Open Source of itself does not mandate Open Development.

Re: Uncomfortable truths

Thank you very much for your kind reply, Alan. I'm sorry about the misunderstanding, too, as we seem to mostly agree.

The open source definition only requires that the source code is available for no more than a reasonable reproduction cost under the condition that the source code is not distributed with the program. If you distribute both the source code and the program together, you can charge as much as you wish. The open source definition was modified in version 1.5 to meet GPL's terms. See [1] for an elaborate treatment of the issue from the stand point of the GPL.

Forks take passion and commitment to happen, of course. I don't think forks need to be disruptive, though. For example, there are many, many forked versions of kaffe. That's not a problem for anyone involved, as far as I can tell, nor is it disruptive for Kaffe.org. Quite to the contrary, ocassionally code from the forks is merged in into the main tree.

For a different example from Linux development, take uclinux. It has been forked from a 2.0 kernel, ported to mmu-less systems, and merged back again in 2.6.

There is a rather nice write up on how forking works on [2]. Why it sometimes works, and why it ocassionally doesn't. Forking obviously comes with a cost, but that is unavoidable. What many people oversee, is that forking comes with a few very positive things, as well: it lets people with different goals work on achieving those goals, instead of fighting each other.[3] The latter is quite important in open source development, as people tend to fight quite emotionally ocassionally ;)

cheers, dalibor topic

[1] http://www.gnu.org/philosophy/selling.html

[2] http://linuxmafia.com/faq/Licensing_and_Law/forking.html

[3] http://www.kerneltraffic.org/kernel-traffic/kt20001204_96.html#1

Re: Uncomfortable truths

Hmm, is there anyone out there who actually charges for the software+binaries? As far as I know, companies that do obtain revenue from GPL software do so either for support and services (e.g. Redhat) or charge for commercial distribution rights (e.g. MySQL). It looks to me very much like a poor attempt to pacify those people who have complained that they can't make money off distributing GPL software rather than a practical business model.

I think it is also important to distinguish between development forks, which are done with the intention of merging back into the mainline at some future date, and forks that take place because of a bust-up of some sort. The former are largely benign, the latter are usually not. The history of the Firebird RDBMS project is well worth studying as a case in point.

However, having said that I do agree that we are pretty much in agreement :-)

Re: Uncomfortable truths

Sun, for example, sells GPLd [1] software for more than the media cost in form of the Java Desktop System. It goes for around 50$-100$ per desktop. So Sun must be distributing the sources along on the media, or they'd have to offer a reasonable cost download of the sources, or something equivalent.

If you look at 'What's included' section of the single user kit on the JDS [2], it says "Perpetual Software Licenses" and "Software Media Kit including CDs and Documentation", which I hope meets your definition of 'software+binaries' ;)

For all I've heard about it, Sun claims to be making money selling JDS to corporate customers, so it seems to work for them. Good luck, whoever it is at Sun!

The FireBird/InterBase split seems to have worked out, though. Borland's project looks dead from outside, FireBird is the fork that lives on. It's hard to merge back into a dead main tree ;)

cheers, dalibor topic

[1] Linux, at least. I've got no idea what else is in there. There must be some Java in it, judging by the name.

[2] http://wwws.sun.com/software/javadesktopsystem/get/index.html

Re: Uncomfortable truths

The JDS model very similarto the Redhat model - you are paying for the integration work and the support that sits on top of the GPL components, you aren't really paying for the software itself.

Re: Uncomfortable truths

Mandrake are another example - you can buy the boxed set (in various flavors + manuals), or you can just grab the ISO for free. They also have an enterprise version and sell professional services as well. The value-add is in how a distro is put together , and what they can offer on top of just the OS. But without the "open" model of development, Mandrake's excellent urpmi package manager just wouldnt exist. Open development allows a stack of sorts to be built - an eco-system so to speak. Without the initial seeding, then the ecology couldnt develop. The seeds or individual plants dont matter - it's the ecosystem that does. And it's this networked ecology that gives the customer the value-add. "the network is the computer" - it's not just a marketing slogan - it's a reality , and it's happening now.