Software fork avoidance: a new business model

Libre and open source software is subject to certain patterns over time. A lot has been created and much of that is arguably in a state of decay- user needs are constantly changing and when software stops evolving then it gradually stops meeting end-users’ needs. Even if software does continue to change, it might not always be in your desired direction. One way to solve this is to fork it, i.e. to take ownership of a copy and inject your custom needs into it. However, as we will see, this is a risky strategy that has its downsides. Its on these observations that we began to imagine a new development support model for open source software.

A short tale

Once upon a time, there was a team of valiant developers who needed a tool to better manage their software projects, tasks, bugs and source code.
On their quest, the team were pleasantly surprised to come across an open source solution which fitted their needs. They began to realise that open source software is fantastic! It’s free, there’s no licence cost so it’s not included in the “purchase” budget. Furthermore, there were no dependencies upon non open source tools. It could be installed in a standalone way, in its own corner.
One day, the team found itself in need of a feature that the software didn’t have. They said to themselves : “well, it’s open source software, we can access the source code and make changes. The license grants us the rights to make changes and we have the abilities so let’s do it!”
However, in the meantime, new versions of the original software had been released. This included new features and importanat bug fixes. The team wanted to upgrade but realised that their custom modifications wouldn’t necessarily be compatible with the new version and it would require a bit of work to adapt them again. However, they had managed it once so they could undoubtedly manage it again. They reverted all their changes, upgraded the software and set-about re-implemening their enhancements.They were happy; they were able to take advantage of new features and keep their custom features.
But soon, the team realized that this way of doing things was not sustainable. It takes time and the upstream software is sometimes subject to fundamental changes. Furthermore, some of the team members had made useful but quick’n’dirty hard to understand changes to the software. The cost of upgrading began to outweigh the benefits and the team became stuck on their own fork.

 

This is what is sometimes referred to as the butterfly effect, the double kisscool® effect or the problem of forking open source software …

At Enalean we analysed the situation so that the story could have a happy ending.

The roles in the world of the open source software

We identified four major roles. Each one has different but complementary objectives

 

The editor The community The user The IT department
Develops the software. Has expertise on the subject Pushes things forward. Creates discussions, contributes, animates Uses the software. Their value: sharing use cases, detecting bugs, general feedback
They need to guarantee the service and security of the deployment. They adapt the tool to the different jobs of the company
Some of the roles will have generic goals that are not specific to themselves such as being more efficient, going faster, gaining notoriety or increasing revenue. However, they have different motivations.
The editor looks for the notoriety or profitability They want to share, meet people, to build a vision, the fun side They are looking for a tool to facilitate their work which fits their needs and helps them work better They want to reduce the TCO and be in control of the tools already in place.

We can analyse more precisely the situation of the companies using the software:

  • They want to modify the open source software because they think they understand their specific need better than anyone else…
  • … but at the same time they don’t know or understand the software as well as the editor …
  • … and they know that software maintenance is very expensive. According to Gartner, maintenance is 70% of the cost of using software.

We can also analyse the software editor’s situation:

  • They want to develop their product.
  • They need to earn money.
  • They know that external contributions bring value to the product even if they can sometimes be expensive to integrate.

The companies using the software are focused on doing something with a product whilst the software editor is focused on the product itself. Based upon this analysis, Enalean has developed an innovative service named “Development support“.

Development support and its benefits

Enalean’s development support aims to avoid the software fork. A fork can be see as a divergence of a piece of software where the source code has been modified. We worked on the principle that everyone has a value to provide and that value exchanges are the best way to avoid a software fork.

We set up this process with our clients, so we know what it provides to each one :

 

Companies subscribing to support development The editor
  • Get an evolutive and high quality product
  • The product fits their needs
  • Reduced costs of maintenance overheads
  • Integrates high quality contributions
  • The product logic is respected
  • Integrating contributions becomes financially viable

 

What you have to remember

  • Forking open source software can be avoided, but it has to be handled upstream
  • A good partnership works
  • It requires an integration process and efficient engineering
  • It creates an economic balance between the players

To go further, I invite you to read the article: Agility and Devops or how to reduce shadow IT & software TCO.

 

About the Author

How great is the challenge of creating economic value for a company with a libre software. I enjoy this! It encourages me to think business and communication in a disruptive way. I believe in the core value of FLOSS and agile spirit: open minded listening, transparency and co-creation. I'm Marketing Manager at Enalean.

Write Your Comment

17 + one =

You may use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Websites located at enalean.com and other enalean.com subdomains need to store and access cookies on your device. We need your acceptance. Get more information. Yes, I agree No, I disagree