Diversity in FOSS - help or hinderance?

  • October 9, 2007
  • Avatar for peter
    Peter
    Upfold

One feature of the free software/open source development model that is largely unique and differs from the proprietary model is sheer diversity.

For any one particular task, there might be several different implementations. Looking for a graphical email client? You've got Kmail, Evolution, Thunderbird; the list could go on. These programs might all bascially do the same thing, yet you've got three different projects with three different sets of developers, three different channels of distribution and so on.

One of the benefits of this, of course, is that you get a certain amount of 'survival of the fittest' within the FOSS world. Two different approaches to solve a problem can be developed in parallel and the strongest solution may win out and go on to become a fully-fledged software solution.

The second benefit is choice for the end user. Not everyone will want a particular bit of software to work in a particular way. When you have multiple solutions for a problem, the user gets to choose the one that works best for them. Variety and choice is most definitely a good thing in this case.

You could also argue that more diversity means more secure solutions as well.

A significant disadvantage of this diversity and fracturing, however, is duplicated work. Two developers working again in parallel on a single solution will end up implementing the same things twice between them. "Don't reinvent the wheel" programmers are told - but that's exactly what they will be doing.

Add in another complication - forking. Forking, for the uninitiated, is when a project splits into two (or more theoretically). The source code from the original is taken and becomes a new project.

In the case of a fork, it is often that the changes from a forked version will not end up propagating back to the original. Licence differences between the two projects can even legally prevent this, so again we get stuck with a high potential for duplicated work.

Also from a commercial viewpoint - having lots of choice and lots of diversity can make it more difficult to pick a solution, as you won't necessarily be able to guarantee the one you pick will remain in development and will 'win' over any competing solutions.

So what can we do to try and make the best of the diversity of FOSS, while minimising the likelihood of and impact of duplicated effort?

Getting developers to talk to each other is certainly a start. Where collaboration is possible, they can work together on common code.

This sort of collaboration is much easier to achieve when you're working with software libraries and frameworks - i.e. code that is mostly on the backend and is shared between applications. A good example of this working well is some of the coordination that Freedesktop does to achieve common standards between desktop environments like GNOME and KDE (although even that is far from perfect).

I think it's more about striking a balance between working together and letting things be done separately. Ultimately, there is no 'solution'. The FOSS model is a double-edged sword with both good and bad points - with unique advantages but also unique challenges.

Avatar for peter Peter Upfold

Home » Articles »