The Rise and Fall of Open Source

It's now been quite a while that OpenSource projects started to die out due to lack of developers, while on the other hand the number of similar projects in the same area is astonishing. 2006 then turned out to be the year when the first major OpenSource projects started to run into a similar crisis.

In almost every area of computer science, there is an awful lot of similar projects which basically have the same goal but try to achieve it in only slightly different ways. There are, for example, gazillions of different Wiki projects, web fora, mail readers, editors, Linux distributions or window managers. This diversity does of course have a lot of advantages, but the amount of people working in the area of OpenSource in their free time is limited. Also, the amount of people who work in the area and are able to contribute quality code is quite low.

The usual life cycle of an OpenSource project nowadays starts with its creation, of course. Then, it is usually maintained to the point where it is about half finished in terms of features. Then, there is usually a clash over some subject (Specific features that go/don't go in, the use of specific version control systems, the attitude of the maintainer), followed by a fork. Usually, this fork results in 3 or more different projects. The parent project usually dies off due to a lack of resources, which have been drained to the child projects. Normally, most of the child projects also lack a security practitioner, which usually leads to vulnerabilities, and consequently to a high load of security incidents which slow down the progress of the child project even further. Also, a lot of people think that in a fork project, they can now finally get rid of the scourge of good coding habits. This usually leads to the project wasting away due to a load of bugs that nobody can manage.

There are various reasons for this. Of course, a prime reason lies in the evangelism that a lot of OpenSource developers just bear inside them. Projects get forked because they don't use the Only Beatific Technology, but some Inferior Technology from The Past. The original maintainer usually refuses to adapt to the new technology because he prefers to have a stable and well-known base to build on.

Another big reason for this is the ego of some developers. A lot of people can't stand it if somebody tells them to bugger off with their patch because it doesn't meet the quality standards of the project. They fprk off a new project with the old code plus their patch, and either a number of developers from the original project fork off as well, or the child project quickly falls behind.

Of course, there is also a problem on the maintainer side. A lot of maintainers don't like the fact at all that there are people who write better code or adapt new features that really are required for the project. This usually leads to one successful child project forking off while the parent project continues to float into space for a while with barely any maintainers left. This is of course one of the better ways to fork, but it still means a significant resource drain.

Also, today's source control systems make it incredibly easy to fork off a project. It usually only requires a fork of the current repository, which is an usually action because today's source control systems just use project forks and push/pull technologies for concurrent development. Also, there are usually tools which convert an entire repository from source control system A to source control system B without even losing the metadata. This means that there is less hassle involved in forking off a project than there used to be, so it's easier to overcome one's inhibitions because the technical bar is lower.

Another drain of resources isn't specific to an OpenSource project. An inherent problem of OpenSource resources lies in the fact that nowadays there is a new technology of the day out every other month, which means that most of the developers just try to learn a new Latest Thing (and start off projects with it, trying to solve problems that have been solved years before). This means that a lot of precious time is spent on learning Your Favorite Programming Language on Rails rather than writing code. On the other hand, the new technologies usually introduce new security problems that were previously unheard of, and that have to be taken into account as well. The .NET hype for example totally forgot to address that buffer overflow vulnerabilities aren't the only security problems in the world, and that .NET itself may also be a security problem.

Finally, there will also be some positivism and a couple of suggestions (or maybe even guidelines) on how to get along a lot better in our projects than we used to.