If you don't like it, fork it

If you don't like it, fork it

Summary: If a project's "owner" becomes obnoxious it is both the right and duty of its community to fork that project under a Foundation. Think of the split as a software Declaration of Independence.

TOPICS: Open Source

Tux with forks from YoLinux.comOne of the big concerns arising from the pending Microsoft acquisition of Yahoo, and of proprietary open source in general, is the fear that a project's owner will abuse its power, even kill a worthwhile project.

Well, fork that. (Picture from a YoLinux tutorial on the fork function of Linux, which is actually a different subject.)

Copying a project over and enhancing it on your own, creating a new, related project, has been around since the dawn of open source civilization, several Internet decades ago. (Roughly one real decade.)

As projects get more expensive to manage, as they demand more bug fixes, code enhancements and support, forking the project gets harder.

But it's not impossible. And it's not illegal.It's right there in the Open Source Definition, practically a Third Law of Robotics for open source:

3. Derived Works

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

Rationale: The mere ability to read source isn't enough to support independent peer review and rapid evolutionary selection. For rapid evolution to happen, people need to be able to experiment with and redistribute modifications.

The reason companies, and groups of companies, have come to "own" projects is that volunteer efforts have difficulty scaling. It's fun to be free, as in free beer, until you run out of beer. Then the hangover sets in and everyone starts squabbling.

The answer, which has always been in front of us, is the Foundation.

Scaled volunteer projects are generally controlled by a Foundation. Eclipse is a Foundation. Mozilla the company is under Mozilla the Foundation. Think of it as the .org over the .com.

If a project's "owner" becomes obnoxious, in other words, it is both the right and duty of its community to fork that project under a Foundation. Think of the split as a software Declaration of Independence.

One of the early stories I followed here at Open Source was on just such a split, concerning Mambo, an open source content management system. It is, in some ways, a cautionary tale.

The fork, Joomla, continues to move forward, as does Mambo itself. Over time the code bases separate, the projects become competitors. Think of it as evolution in action.

A fork can cost a project momentum, or not. Wordpress, on which this is written, was originally a fork of b2/cafelog. If the forker knows what they're doing, in other words, they can out-do the forkee.

Which gets us back to all those proprietary concerns about projects "owned" by Yahoo and anyone else. Forking gets harder as projects mature. But so long as forking is possible, project owners can't just say, well, you know.

Even Microsoft.

Topic: Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Amicable forks

    Do keep in mind that some forks are made, not over disagreement, but over the need to move the project forward. Two that come to mind are the [i]egcc[/i] fork of [i]gcc[/i] and the recent fork of [i]Apache[/i]. IIRC Samba may have had one of these, too.

    In all cases, the community doesn't divide itself but it does divide the codebase so that the new version can move free of the support requirements of existing code. In the cases I know of, the forked (experimental) branch eventually became the principal branch of the code once it was proven.
    Yagotta B. Kidding
    • Absolutely.

      Firefox is another example of such a fork. The original Mozilla branch is the Seamonkey branch, remember. :-)
  • RE: If+you+don%27t+like+it%2C+fork+it

    Great post. The power of the fork is what keeps open source software vendors honest. If they start to act in ways that go against the community, the community has the option to fork the software.

    Conclusion: Don't be afraid of open source business models.

    Tristan Rhodes
  • What about for profit businesses?

    In my experience, consumers of open source technologies (both developers and customers) want much more than free code that comes with an option to fork. They want to know that the time and effort they invest in the code, with the community and on the solution has longevity and will generate future dividends. They want the confidence that there is a bigger common vision beyond their own personal use. They don't want to be the only (or last) volunteer on a project.

    You correctly identify Apache, Mozilla and Eclipse as foundations that have the governance, vision and funding in place to draw in developers and customers and provide long term benefits.

    But so do for-profit businesses. My company, Compiere (www.compiere.com), demonstrates that commercial open source businesses can simultaneously create long term value for developers, customers AND investors. Red Hat, Novell, Sun, SugarCRM thrive as for profit businesses through a commercial open source business model. The acquisitions of SuSE, XenSource, Zimbra and MySQL have not slowed these commercial open source technologies...or businesses.

    As you point out, foundations work. But so do commercial open source businesses. ...forks or no forks.

    Bill Freedman
    Compiere, Inc.
    • Bill's right

      Remember that this was in response to Paula's post about Microsoft inheriting Yahoo's open source projects, which has drawn considerable interest from the community here.

      It's true that open source businesses which work in tandem with their communities can succeed. But these communities are a "public" to which they must effectively "relate."
    • What about Compiere?

      Interesting post Bill.

      Your company, Compiere, has a checkered past regarding open-source development. I have personal experience working with Compiere through a partner, and have submitted patches to Jorg and Kathy. I found it very hard to get bugs fixed - despite the fact I submitted a patch with every bug report.

      Compiere added no value to developers - the wouldn't take our patches, so we had to maintain our own code repository, and merge our changes back in after each new release. Then re-test before we could upgrade our sites.

      The bottom line is the product was very much driven by one person, and not by the community. It is irrelevant how good that person is, the community was ignored, and so Compiere itself was been forked - more than once.

      If Compiere has learnt a lesson since then, great, congratulations and well done. If not, then I suggest you start studying...
  • RE: If+you+don%27t+like+it%2C+fork+it

    We at TUSDEC (Technology Upgradation & Skill Development Company in Pakistan have adopted Linux software for all sorts of networking and communication. This is good experience.
    • which Linux?

      The Linux you choose is based on...what, exactly?

      Is it the community? The support? The localization?

      Love to hear more...does anyone but Ubuntu come in Urdu versions?