>Some recent blog postings from influential members of the software community have gotten me thinking about Open Source software and particularly why I’m involved with it. Michael Kay, author of the widely used Saxon XSLT 2.0 and XQuery 1.0 processors, recently announced a repackaging of Saxon. Kent Beck, co-author of Junit and creator of JunitMax, also announced a break with a principle he has had for 27 years.
Both of these people have influenced the way we work with code. Michael Kay always has been a guy that promoted the use of standards, and helped greatly enhance the advancement of XML at a time when tooling was desperately needed. Kent Beck has influenced many with his ideas on software development and his approach to how we do things. Imagine the world with out JUnit and it’s influence on test driven development.
Like Kent, I think Michael in some ways is at a cross roads. If your lively hood is based on selling of what you create, how do you get others to share the burden in the cost of the development of the software. Michael’s entry is worth a read, as is Kent’s. Both have hit the same cross-roads but from different directions. Honestly, I don’t know if the direction Michael is going is the correct one, only time will tell.
Now this brings me to my own involvement in open source. I do not put myself on the level of a Kent Beck or Michael Kay. I work on open source for a variety of reasons:
- I’ve benefited from the work of others.
- It’s a way of artistic expression.
- I believe in the betterment of the community that uses that source.
I do not have financial interests in general in the open source work I do. That isn’t why I do it. I program because I like to create and solve problems. If others can benefit that is fine, and if my open source work can help get me a job that is even better. I managed to get a contracting assignment based on some C programming work I had done for a MUD based on CircleMUD.
Michael mentions in his blog:
With open source there’s always the risk that if you don’t keep your users happy, someone will fork the code. However, Saxon is now 200K lines of code, so that’s a formidable undertaking. One of the reasons I’ve never published the test suite is that I wanted to make forking difficult for people. I find it hard to imagine that anyone would have the stamina to make a success of it, or to win the trust of a significant number of users.
Not publishing a test suite isn’t going to stop somebody from forking, or from a commercial entity from taking the code and enhancing it for their own internal use. Whether somebody could make a success out of a freely available Schema Aware XSLT 2.0 processor is a matter for debate. The eXist XML Database is a very good implementation of XQuery and is a viable competitor to the open source Saxon engine for XQuery development. It also has a significant and growing following of users. True it’s not a fork of Saxon, but if the users don’t get what they want from Saxon they can always choose something else.
IBM (WAS XML Feature Pack), and Oracle also have their own commercial implementations of XSLT 2.0 processors. Something I’m actually sad to see from IBM, who helped create the Xalan processor that was donated to Apache. What is really disappointing is that at one time the Apache foundation had started work on an XSLT 2.0 compliant version of Xalan, but the committers that were working on it were pulled and moved to other internal applications. It would appear that WAS XML Feature Pack may be the result of that original work, or it may just be a big coincidence.
Which brings me around to Commercial Open Source software. I’m more directly involved with eclipse, but have benefited immensely from the projects hosted by Apache. One issue I see with the long term success of Commercial Open Source software in general is the dominance of the commercial side of things. Particularly from the donation of committers to a particular project. If a commercial open source project is entirely dominated by commercial interests, and those interests or the direction the companies change it can drastically affect the overall community. I’ve seen this direct affect at eclipse projects. Internal company interests can greatly affect the what happens on an eclipse project. Particularly when the company pulls the paid committer to work on internal company projects and doesn’t replace that knowledge base.
I would venture to say except for a hand full in the eclipse community, that if their companies were not paying them to work on eclipse code they would not be working on it. There are several that do it because they believe in the long term success, but most commercial committers are not in it for the same reasons that most individual committers.
There is nothing wrong with this, but I think it can affect the long term viability of a commercial open source project. Linux has greatly benefited from the influx of Commercial blood, but it will also continue along even if it were to drop off. What happens to an eclipse project that is entirely staffed with commercial committers, and the interest change? Particularly if their isn’t enough diversification on the project? What happens to WTP if IBM pulls all of their committers to focus on internal IBM projects? Oracle pulls their JEE committers to work on Oracle internal projects?
My view of open source is for the benefit of the community as a whole. To provide software that meets the needs of 80% of the community, and to provide a framework in which it can be enhanced for the other 20%. If you want to help with cost of development, make sure you encourage others to contribute. One person shows only go so far. Go ahead and give away the base functionality, charge for the advanced features, but beware that eventually the base functionality needs changes. Somebody will eventually create an open source equivalent to what you offer in your pay version.