20060707

Why Open Source Projects don't practice what they preach

A lot of people use OSS resources, OSS projects want lots of people to use them, but my experience is that OSS projects don't use other OSS project resources as much as their closed source counterparts.

In my experience closed source projects tend to use twice as many open source libraries as similar open source projects. So I thought I would investigate why...

Developer Ego


This was my first thought. Historically it has taken a certain type of developer to make that step towards and open source project; and knowing a few of these developers I would expect that they would prefer to show off rather than save time and effort. So there must be an element of "not invented here".

Also when you make use of a large number of applied resources your project changes from being a development exercise into one of integration. But integration projects don't carry as much kudos as green field developments for their founders. If you have an ego then you would much prefer to be known for your development skills than your ability to integrate.

The Problem With Being Open


If your users are the inquisitive kind, and a lot of them are, then they are going to look at the choices you have made regarding the supporting services upon which your project is based. That is why so many projects use Apache commons logging, for example, because it alleviates the developer from fixing that choice in stone. But not every service can be abstracted so cleanly, and bad choices can reduce the scope in which your project can be applied. The most common one is the persistence layer where a choice such as Prevayler can prevent your project from scaling in an enterprise context. But the solution, to provide alternative options, can drain your development resources and give you an increasing number of maintainability issues.

Another issue is the rate of change of your chosen supporting resources. Say, for example, your project is based on Azereus libraries which update every few weeks. The question in your mind is which version or versions do I support? If 2 projects make conflicting choices then it gets harder to use them in conjunction (as happened with Cobertura, Hibernate & ASM). The other side of this coin is that you also don't know what versions of your own project are still in general use, and so when you make changes to your API are you creating compatibility problems for those that might re-use your software? Closed source projects don't have this issue because they are rarely used outside the sphere of knowledge of the creators.

Responsibility


End user applications need to go through some degree of systems testing. Bugs in live systems need someone to accept responsibility for fixing them. And there is always a license to uphold. Closed projects have an advantage with all of these areas of responsibility because there is usually some money to pay for extensive testing of incorporated systems, fix bugs in other people's code and investigate the legal basis of the product.

But open source projects typically do not have the luxury of a budget for supporting their re-distributed software. And more scarily, license compatibility and patent infringement are really nasty issues to have to deal with.

Feeling Exposed?


So the reason why OSS projects don't make use of many of their own kind are really related to the way in which most projects are run; a small number of personally involved developers working usually for small change handouts. The effects of this scenario subtly drive the developers to work in greater isolation, which is ironic.

No comments: