Skip to content

Improving Open Source: On Duplicate Projects

In this weekly post, we talk about ways that Linux, and the overall open source community could be improved.  The focus is on providing constructive criticism and feedback to the open source community to drive development towards better offerings that can as a whole better compete with the classic commercial contenders.

Last week, I talked about a first step in improving user experience in open source software.  This week, I’m going to talk about collaboration.  If you look at the Apache Foundation website, there are a good couple of dozen projects under the foundation’s wing.  Looking in to what all of these are, you start to wonder: why does the Apache Foundation have so many projects that are basically the same thing.  The reason is a good one: competition. With the projects competing with each other, they drive innovation off of one another.

The down side from the public’s standpoint though, is the only way to tell which one you want, is to try both.  And in a lot of cases, you won’t find a meaningful difference until it’s too late.  You’ve already chosen one, gone to implement your application, and you find some critical flaw.  Upon researching a way around it, you discover that if you had gone with the other solution, it wouldn’t have been a problem.

Now, that’s not to say that this would happen if there was only one solution, but it removes a lot of the time you spend on looking at the differences and weighing options.  What I’m getting at though, is that open source projects should try a different model.  First off, if projects are relatively similar, they should join forces.  Then, if groups develop inside the project that want to do different things, they can split.

Compiz is a great example of this.  At some point, two factions developed, and the project split in two.  That resulted in Compiz and Beryl.  Eventually, they then joined forces once again, and the result was a much better product.  I see no reason why the rest of the open source community wouldn’t benefit from this.

Be Sociable, Share!

Posted in Open Source, Weekly Updates. Tagged with , .

2 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. aaron said

    I think the ability to create your own branch is the most compelling property of open source software, and I agree, it allows variations to compete. There is the issue of effort – projects need a critical mass of developers to work, but when a few developers disagree and can convince a few others to join them in creating a branch, good things can happen.

    MySQL development recently kind of fell apart, with no one really in charge of the direction. Luckily, anyone is free to take it wherever they want and the consensus will most likely create something that works for a large number of people.

    Oh and by the way, any of the people involved can be a for-profit organization too. Development isn’t restricted to coders in basements. Companies can take whatever’s out there, add features and fix bugs that, for whatever reason, benefits them, and contribute the changes back to the community. Everyone wins. But even if they don’t contribute back, the community hasn’t lost anything, and the company and their customers gain a lot. This is why I often choose the MIT license, which allows people to created closed derivative products if they want. I opt for as much freedom as possible, including the freedom to leave the open source community, in the hopes that it will remove any barriers to joining.

    This type of freedom really enables innovation.

  2. You stole some of my thunder actually with that. I had planned on talking about licensing at some point, but maybe you didn’t spoil it. We’ll just have to see!