We cannot solve our problems with the same thinking we used when we created them.
~Albert Einstein
Ah, the creation of an open source project. Where once all you had was an idea and a desire to satisfy a personal need, you now have a fully-formed project that numerous other people are finding useful and effective. You’ve formed a community around it, interacting with people from all over the world who are grateful and willing to offer their time and effort to help build up this project. It’s nothing short of exhilarating.
Then things start to happen that you didn’t necessarily want to happen.
Competitors, critics and complaining users appear out of nowhere and seem to grow in number. Some even seem to take pleasure in bringing your project down. Forks start to appear, and what’s worse is that some of them claim to be better than the original.
At this point, it seems rational to react strongly; to defend your project with the same vigor and passion you had in creating it. But this is a totally different scenario. While passion makes for great fuel in initial project creation, it’s often not the best basis for logical thinking, which is what is required once you’re in the thick of project management and its accompanying problems.
Finding the Pros in the Cons
As with any major undertaking, an open source project will have its pros and cons. Achieving the project and gaining support for it are often the biggest pros. Acquiring haters and producing diverting forks are in many cases, the biggest cons. But there are positives to these seemingly negative things, and ways you can handle them that can somehow make them beneficial to you.
First, the Haters
Haters and critics are undoubtedly annoying. They know how to get right under your skin especially if you feel strongly about your project, which is usually the case with most developers.
The first thing you have to realize here is that these haters are a good thing. Why? It means that your project is actually meaningful and significant enough to be “hated”. This could also mean that several people actually used the software and that their numbers increased to a point where some of them have now noticed a few downsides to it.
Speaking of downsides, they’re much more visible when critics are around to point them out, aren’t they? So in this sense, critics are actually quite useful. They help you see the faults you need to work on to improve your software and make it serve the needs of the community better.
When criticisms don’t have this redeeming quality however and simply throw shade your way, the best course of action is inaction. Responding to these criticisms will only acknowledge and validate them, so it’s better to take a breath, turn away and move forward.
The Forks
In the open source world, forks are inevitable. Yet when they materialize, some developers can’t help but feel negatively towards them. They can feel threatened, annoyed, betrayed, bitter and even angry.
But as Apache co-founder Brian Behlendorf once said, “the most important requirement [in open source] is the right to fork.” Forking is a natural effect of open sourcing software, and one that is often beneficial. The creation of forks encourages developers to consistently improve their software and remain competitive to the benefit of the entire community. Forks also make software more customized, which is a good thing particularly for software that have a broad scope. Generally, they’re necessary for the healthy balance and continued development of software and the open source environment.
While there’s nothing you can do to stop forks, there are things you can do in response to them. You can focus on differentiation, setting yourself apart from these forks. You can focus on developing your software and making sure it answers the needs of users, so that it will remain the first choice instead of the forks. Whatever you do, don’t try to deliberately and publicly destroy the forks. Why? First, doing so would give you a bad reputation among community members, one that will most certainly drive users and contributors away. Second, you don’t know what changes the future may bring. You may find yourself having to re-merge with a fork, or be totally replaced by them later on.
Conclusion
Managing an open source project is hard work all on its own, and having to handle annoying forks and haters just makes it even harder. But with every challenge is the promise of reward. By handling these things properly and with the right mindset, they can in their own way become beneficial to your project and help you better embrace and nurture the very nature of open source.