How to Successfully Fork an Open-Source Project

• 

  Heavybit
  Heavybit

Why is Heavybit writing a startup guide to forking open-source projects? Because while open source has been an incredible boon to software, we’ve seen licensing and trademark issues, legal issues, and operational challenges lead to dramatic, sometimes painful changes across open source. And a fork can be the most disruptive thing to happen to a project.

In this guide, we’ll absolutely discuss the how of forking, but because it’s such a fraught topic–and the process itself has so many potential landmines–we’ll provide some extra context before we get to the how-to. Here’s what we’ll cover:

• What Forks Mean for an Open-Source Community
• Why Do Open-Source Projects Get Forked?
• When Should a Startup Fork a Project?
• How Should Startups Approach Creating a Fork?

What Forks Mean for an Open-Source Community

In open-source software, a fork is the act of copying the source code from an existing project and using it as the basis of a new project with a comparable license and a noticeably different name. (Using names that are too similar to other projects is a good way to risk trademark infringement–just ask Automattic and WP Engine.)

Despite the ease of hitting the "fork" button in Github, forking an entire project isn't an everyday occurrence, and it shouldn't be. Community is vital to sustainability. A fork splits a project's community into splinter factions. And as users and contributors migrate to the new project, each splinter group ends up with a smaller community than the original project, potentially jeopardizing the future of both versions.

At the risk of stating the obvious, open-source projects live and die on the strength of their communities–having a unified, active group of contributors and users around the world is a key part of keeping such projects sustainable.

For example, the open-source operating system Linux, first launched in 1991, has more than 20,000 contributors who have expanded the Linux kernel to more than 30 million lines of code (and counting).

When we talk about forking commercial software–there can be ‘good’ or ‘bad’ reasons. But a fork is usually a recourse of some kind, for governance, or for another purpose.” -Joseph Ruscio, General Partner/Heavybit

Why Do Open-Source Projects Get Forked?

Historically, these have been some of the most common reasons for projects to get forked:

Continuing an Otherwise Discontinued Project

When the original owners of an open-source project go away, it’s not uncommon to see their communities create a fork of the project to keep the project’s functionality available to public users.

The open-source productivity suite OpenOffice was released by Sun Microsystems in 1999. However, Oracle acquired Sun in 2010, and soon after, Oracle announced it would discontinue OpenOffice, ending its distribution and donating the project to the Apache Foundation. However, one of OpenOffice’s most popular forks, LibreOffice, remains popular today with an estimated 200 million users.

Legal Problems

Sometimes, the future of open-source projects–and the organizations that create them–are threatened by legal challenges. In such cases, communities will sometimes create forks to keep the projects going.

The mid-2000s peer-to-peer file-sharing client LimeWire was an open-source project that ran afoul of the Recording Industry Association of America, which filed a massive copyright infringement suit against the creator, Lime Group LLC. Concerned about the direction of the project, users created a less-successful fork, FrostWire, before the company stopped distributing the software entirely in 2011.

Philosophical Schism

Sometimes, the maintainers of a project can’t come to a consensus on what a project should look like or how it should evolve. In such cases, a community may split along those philosophical lines, with different factions migrating to the subsequent splinter projects that make the most sense for them.

GNU Project creator Richard Stallman’s Free Software Foundation (FSF) clashed with Lucid, Inc. on the direction of the free text editor GNU Emacs. Lucid, focusing on shipping new changes to Emacs, grew impatient with approval bottlenecks from FSF, and created the XEmacs fork, which was initially quite popular, but ultimately saw declining usage compared to the larger and more-vibrant GNU Emacs community.

Forking for Commercial Reasons

Sometimes, companies will fork an existing project because they see great value in it, but want to exert greater control over its development, potentially as an integrated part of their existing product offerings. Depending on the nature of the open-source licenses in play, startups can, have, and will continue to fork open-source projects to build into commercial products.

On the flip side, corporations using existing projects have been known to fork them in response to licensing changes. Massive cloud provider Amazon Web Services has famously forked multiple open-source projects, including ElasticSearch, Redis, and others in response to license changes made by the owners to prevent freeriding.

Corporate forks represent a growing challenge for open-source startups, who need to build thriving user communities but also increasingly feel the need for defensibility against huge orgs scooping up their code and building billion-dollar empires without making significant upstream contributions or paying a cent. But midstream license changes–also known as rug-pulls–have led industry giants to fork, which can be a highly negative outcome that divides the community.

AWS has hosted versions of forked Redis, forked ElasticSearch, and a MongoDB ‘alternative.’ You can put your open-source project out there, but if you piss Amazon off, they might fork you.” -Rachel Chalmers, Part-Time Partner/Heavybit

When Should a Startup Fork a Project?

We believe that forking, when performed properly, can be a valid approach to interacting with an open-source project and its community. There are examples of successful forks that have gone on to see commercial success in one form or another–the popular operating system Ubuntu is a fork of the Debian Linux distribution which, while free to use, carries a commercial license for pre-installations or for commercial products that use Ubuntu itself.

However, we advise founders to approach forks with eyes wide open. Keep in mind that forks are generally a last resort alternative to open-source projects which, for whatever reason, cannot or will not provide the value and functionality that users need.

That said, it may be a good idea to think about creating a fork when:

There’s No Other Logistical or Practical Recourse

If a project’s owner is about to wink out of existence, one of the best ways to save it from becoming an abandoned ghost town could be to fork it. On the other hand, if you’ve identified an important new direction you think the project should take, but you can’t convince the owners to expand the scope or pivot, a fork may be your only alternative.

There’s No Other Technical Recourse

When open-source projects aren’t serving all the needs of its users, contributors may also have the option to consider building alternatives, such as developing non-disruptive plugins or implementing inversion of control, which can grant external frameworks control of certain aspects of how applications run.

In some cases, external fixes can’t change fundamental architecture issues that keep users from getting what they need. There may be a need for deeper change across the codebase that the owners aren’t willing to support.

There’s a Genuinely Valuable Use Case For a Significant Audience

If you’ve identified a genuinely valuable use case for a non-trivial user base that requires a real change in direction, a fork might be a good way to go. The TokuMX fork of MongoDB significantly modified the NoSQL database’s architecture to handle heavier write operations and larger datasets.

The Tokutek team identified opportunities for improvement over the core project and launched in 2013. The fork was considered valuable enough to lead the OSS database organization Percona to acquire the company in 2015 and make TokuMX the basis of its server product.

There’s a Genuinely Huge Community Upside

Your fork of an open-source project will create your own net-new open-source project–which will need a substantial community itself. When you fork an existing project, you’re fundamentally creating a schism in that project’s community that can very easily lead to hard feelings and resentment among users and contributors who are involved on a purely volunteer basis.

Ultimately, your new community will have to come from one of two sources. You will need to either spin up a new community full of brand-new people who are not active users of the original project (not impossible if you plan and resource it properly), and/or you will need to siphon off people from the existing project’s community to support your project (more likely).

The original project’s community will see exactly what you’re doing. And they are more than likely to question your motives, and hesitate to join you based on their concerns.

Licensing and Trademarks Allow a Path to Success

More than likely, your fork will need to carry the same open-source license as the original project. It’s important to ensure your future project makes sense under those licensing terms, and that your startup can and will abide by all copyright and trademark restrictions.

How Should Startups Approach Creating a Fork?

We recommend taking the following steps when planning to fork:

1. Ensure You, and the Community, Have Exhausted Every Other Option

As mentioned above, there are alternatives to forks. Creating a fork–and a startup around a fork–means making a major commitment. The last thing any founder wants to do is make an enormous investment into launching a new project only to find out there’s a free community plugin that does the same thing.

2. Contact the Original Project Owners Directly

Aside from being an important courtesy, making contact with the original project’s owners will help you identify any potential alternatives and also hopefully help you pave a path for upstream contributions to the original project–an important part of forking you should absolutely plan to resource in your product roadmap.

3. Make Your Announcement to the Community

Making anything public should come after you’ve confirmed that forking is the only path forward to solving the problem you’re setting out to solve, and after you’ve made civil, positive contact with the project owners. Skipping ahead to the public announcement without alerting the owners will almost certainly set a hostile, competitive tone that won’t help your project.

Your announcement should be:

• Comprehensive - Explain in full detail why a fork is needed
• Value-Driven - Explain how the fork will benefit its intended audience
• Candid - Discuss how you exhausted every alternative, and your conversations with the owners–knowing that misrepresenting those conversations could have a disastrous effect on your reputation
• Respectful - Knowing that forks can cause resentment, all public statements should be deeply respectful to a project’s community and owners
• Clear -Communicate your call-to-action and next steps, like explaining where and how to participate, and inviting new contributors to join the buildout for early materials

It’s a best practice to plan to hunker down with the community wherever they meet between your community announcement date and your launch. You should plan to spend your time answering questions and taking all feedback as it comes. While there may definitely be unhappy comments, there may also be extremely valuable feedback from potential future contributors.

4. Create Your Fork per Licensing and Trademark Restrictions

Only after you’ve explored every alternative, contacted the owners, and made your intentions clear in the community should you actually fork the original project’s code.

Your fork should, as mentioned, have a distinctly different name than the original project to avoid trademark infringement, and you should plan to provide for any and all provisions of the original project’s license, like preserving copyright notices and attribution, distributing source code, documenting modifications, and the like.

5. Begin the Long Journey of Supporting a New Project

After you’ve forked the original project, your work has only just begun. Now, it’s time to build up a new community around what amounts to a net-new project that provides distinct value, while ensuring you don’t fall hopelessly behind the original project’s version updates.

Congratulations. You Forked It.

If you’ve made it this far, you should hopefully have a better understanding of why forks aren’t common and why they carry significant risk. Your job as an open-source founder is to build and maintain a vibrant project with an equally vibrant community. We wish you the best of luck and invite you to check out these additional resources that may be helpful.

More Resources

• Article: The Power User’s Guide to Open-Source Licenses
• Article: Forking Protocol: Why, When, and How to Fork an Open Source Project by James Dixon
• Article: Why Do Open Source Projects Fork? by Pete Bratach
• Article: Why Open Source Forking Is a Hot-Button Issue
• Article: What Success Looks Like for Modern Open-Source Software Startups
• Article: Understanding Legal Issues for Open Source Software Start-ups
• Article: How to Successfully Invest in Open-Source Startups