Open Source projects have to deal with something most proprietary projects don’t: forked projects. What’s that? It’s when a person or group exercises the terms of an open source license to create a derived version that competes with the original. It’s practically the definition of open source, the ability to take the code and do whatever you want with it.
This frightens most business people. In the business world, attorneys have designed all sorts of non-compete clauses they attach to contracts, to prevent employees from starting other businesses with the knowledge they’ve gained from working for you. In the open source world, anybody is explicitly allowed to take that knowledge embodied in your software project and set up their own shop.
How do you build a business around something you can’t control?
SQL Ledger/LedgerSMB
In the past couple weeks, there was a fork in the main open source financial project out there, SQL-Ledger. The users’ mailing list is full of insults and accusations between supporters of the old project and the people who’ve left to set up shop. It’s quite an ugly place to visit right now…
What gives the upstarts the gall to leave the project and start their own, LedgerSMB? How is this good for users? Why would they do such a thing?
Turns out, a whole bunch of reasons.
First of all, SQL-Ledger has always been tightly controlled by a single developer. While he accepts help from translaters, most other code he does alone. So new features take months to come out. I’ve been using the system for three years, and there still isn’t a payroll module. While there have been developers willing to help on the project, at least from an outside view the developer has not been that receptive to contributions from the community.
Secondly, while the code is free, the documentation is not. The maintainer of SQL-Ledger hordes knowledge about how to use it, and disseminates it only to people who buy the manual from him. While he has every right to do so–open source is, after all, a voluntary gift to the community when you own the code–it does seem to go against the open source ethos. It feels like a disengenious use of open source–hook them with free software but then force them to buy the manual to be able to use it effectively. Few other open source projects get away with this model.
Thirdly, the mailing lists, which are the main free support for the project seems to have been heavily moderated, and not in a fair or balanced way. I’ve had several of my posts that point out apparent bugs not make it to the list, along with a few answers to other people that might’ve helped them solve their problem but might have been considered too close to the secret sauce in the manual. Meanwhile, some vitriolic subscribers spew ugly insults to others on the list, with apparently free reign, as long as it’s in support of the lead developer. It’s not a friendly place to be, on the Internet, and probably does a lot to drive people away from what is really a great piece of software.
But it appears that the final straw was the lead developer’s complete disregard for a major security vulnerability. At least one developer found this hole nearly a year ago and informed the developer. While we’ve seen more than half a dozen releases since then, this hole wasn’t fixed during that time, until another developer stumbled on it. This developer also tried to work with the main developer to get the hole fixed, but was met with hostility and an unwillingness to take the problem seriously.
So the other developers felt like they had no choice but to take the code and start a new project that took these security concerns seriously.
As a result, all sorts of new possibilities become available: a whole new list of features people have wanted to see may get implemented; people can contribute directly to the project to see enhancements they need; a true open source feel, where people are actually helpful instead of just telling you to purchase the manual; and a sense of shared ownership of the code, not held hostage to a single developer who could decide to pack up his toys and go home.
Now, I don’t mean do speak ill of the original developer. SQL Ledger is really a great program, and he’s done a lot to make it that way. I’ve paid for the manual twice, most recently just to give him financial support to keep working on the software, not because I really needed it. But I do think SQL Ledger has outgrown what can be managed by a single developer, and he stands in the way of its growth. So I look forward to seeing a community-forked version thrive.
Mambo/Joomla
SQL Ledger is far from the first business open source project to fork. Joomla recently celebrated its first birthday. Joomla is the result of the core Mambo development team getting into conflict with the company that sponsored it, and owned the Mambo trademark. So they all left the project and started Joomla. It took several months for the dust to settle, but Joomla is the clear winner of this fork, with some 2.5 million downloads already and some major innovations on the horizon. Mambo, while it still exists, has barely been able to keep up with security vulnerabilities, and has already lost some of the replacements brought in after the Joomla revolt, for apparently similar reasons.
SugarCRM/VTiger
Not all forks eclipse the original project. SugarCRM has become one of the most successful companies that uses an open source project as its flagship product. And the product is very well done. And it has also been forked–into a community project called vTiger. The reasons for this split are less clear–it apparently has to do with a group of free-software proponents who didn’t really like the idea of a clearly commercial open source project.
SugarCRM is released under a different license than Mambo or SQL Ledger (Sugar Public License, instead of the GPL), so the viability of vTiger is less clear. vTiger has diverged quite a bit from SugarCRM already, adding more enterprise management features like accounting and inventory management while SugarCRM has focused more on enhancing the customer contact side of things with workflow, email campaigns, projects and cases and the like. At Freelock, we’ve stayed on the SugarCRM side of this split so far.
Asterisk/OpenPBX
Here’s a fork that seems to have dropped off the map. Asterisk is the incredibly popular upstart free PBX (office phone) system that’s starting to decimate the lucrative telecom market. And OpenPBX is an Asterisk fork that doesn’t seem to be going anywhere. It has a stated goal of being more stable and better documented, and while it’s still alive, I don’t hear anybody really taking them seriously.
Mandriva Multi-Network Firewall
I’ve even tried to do my own fork of a project. Mandrake Linux for years had a great firewall distribution, called the MNF. As it got long in the tooth, a replacement MNF2 was developed, but it wasn’t released under the same terms as the original. Mandrake had become Mandriva at this point, and it saw MNF2 as a corporate product, not something they wanted to make freely available.
The source code, however, was still covered by the GPL license, which means anyone can take it and start their own version. So we could take the MNF code, rebrand it, and release it under a new name.
Unfortunately, I’ve got a few too many projects on my plate, and so that project didn’t get off the ground. Meanwhile, the formerly thriving community around the MNF has completely died–the mailing list which used to be very active hasn’t seen a post in months. This is a project that could still make for a very fine fork, but that takes time and effort, and nobody has stepped up to the plate to make it happen.
To fork or not to fork
Creating a successful software project of any kind is a daunting task. In the open source world, forks are a natural part of the development of projects. In a very Darwinian way, some forks succeed and grow to become thriving projects of their own, while others die a silent death. A few fill the niche of the parent project, killing it off completely. Forks can be very unsettling, especially when they happen to projects you rely upon for day to day business. It’s generally better to concentrate developer talent into fewer projects, making them develop faster and better. But in the long run, forks are sometimes unavoidable. Forks are an activity that make open source projects thrive, and ultimately result in better software for us all.