The sustainability of consortium outcomes is always a topic of discussion during the lifetime of a consortium and especially in the final phase. During the project, there is a nice optimism about the outcomes. In the first discussions, people think you can make money with the outcomes; later on, the focus starts to be on a non-profit that should care for the outcomes, and in the end, only a small percentage of the consortia succeed in getting the outcomes sustained.
The Hyve partnered in many consortia and often got the question if we are able to take care of the outcomes, the product, the artifact which was created during the project. People know The Hyve as an open source company. And at least it sounds really friendly to have the outcomes of the project available in an open source way.
The Hyve is indeed a company with almost 15 years of experience with open source products. In this article, we want to share our insights and knowledge about open source. We’ll do that with some firm statements.
Open Source is not free
There are a lot of different models for payment. All have one thing in common: someone should pay. Open source software can not be maintained for free. Of course, the maintenance could be done by volunteers. They pay with their hours.
There are also models for making things open source after a period of time. And in the first period of time, things will be paid for with a fee.
Funding from an NGO is ideal, and sometimes it is also beneficial for the NGO to get the right data in the right formats, because the right open source software has been used.
And a company that is working with a specific type of software? A company like The Hyve charges money from the client, because there are costs. The good thing is that we are talking about fair pricing related to the amount of work.
Open Source fulfills a need
It sounds simple: there should be a need for the product. Otherwise, there won’t be paying clients. In marketing language, a need is translated into a ‘pain’ or a ‘gain’. Especially in scientific projects, it is tough to make the pain or the gain visible in the short term. There is most of the time a focus on the long term. But without real pain or gain, nobody is going to pay for the created product.
Consider the rise of the OMOP common data model as a perfect illustration of turning initial pain into long-term gain. Mapping hospital data to a shared standard dramatically boosts its value: data across multiple sites can finally be pooled for joint research, unlocking far greater outcomes than any single dataset could provide.
Open Source needs a vision and a roadmap
While the focus of many consortiums is on the sustainability of the outcomes, the real focus should be on the vision. What does the world look like in the ideal situation with the use of the outcome of the consortium, and what is the role of the product in that ideal situation? When the vision is defined, the next step is the roadmap. The roadmap in open source is a bit different from roadmaps in proprietary software. Where a company that sells licenses for proprietary software can make its own roadmap after consulting the paying customers, a company that works with open source software is dependent on the willingness of the funders or paying customers to pay for next steps.
Open Source needs a champion
Talking about a champion, there are a few important traits. It is their ability to build something from the ground up (entrepreneur) and their ability to rally people behind a vision with undeniable passion (evangelist). Those traits together bring us to the Champion. The Tech/Product Champion is the Ideal person for emerging technologies. He/she can be defined as an industry advocate dedicated to championing the transformative solution and driving adoption.
Open Source is part of a community
Alone you will be faster, together you will go further. Especially in the world of Open Source, you always need a good community around the software. The roadmap and the shared vision are a community effort. And in a healthy community, there are people with authority and the right feeling of ownership. Analyzing healthy open source communities gives a picture of an ecosystem with a variety of parties, sometimes partnering and sometimes competing. In that ecosystem, there are also more sources of money: partly NGO’s, partly paying clients. Ideally, the leadership role is not a CEO role fulfilled by (a director of) one of the service providers in the ecosystem, but fulfilled by someone who is close to the users. Leadership in a community is a special type of leadership, closer to the champion than to the manager.
Behind each product you need a team
An important but also reasonable lesson about open source is that there should be a team that can guarantee continuity. If there is one person with the knowledge and that person will be off, then there is nobody. In 15 years of The Hyve experience, we have seen that you need at least 4 people with knowledge and capabilities related to the product.
The legal choices around Open Source are important
Two types of legal decisions should be made about the product. The first one is about the license, which can be more strict or more permissive. It depends on the situation what the best license is. In the stricter licenses, everyone has to push back new code to the community. In the more permissive licenses, there is more freedom to use the code in other programs without pushing everything back to the community. The more permissive licenses could help in creating a larger user base. The stricter licenses give the community more guarantee about collaboration with the code.
Open Source survives AI
I started this article with a few bold statements. While most are grounded in nearly 15 years of industry experience, my take on AI's impact on Open Source comes from a different place: a deep focus on community. The explosive growth of AI over recent years has been undeniably disruptive, making the future hard to predict. Yet, I stand by my main claim: Open Source will survive AI.
Some argue that Open Source is near its end. After all, most LLMs are trained on open-source code, theoretically enabling AI to generate custom software on demand. Would establishing clear rules about how LLMs should be trained, help protect open source? Perhaps, but we are likely too late, and enforcement remains a grey area.
However, regulation isn't what will save open source. Its true power has always been its community. While AI can optimize workflows and automate processes, genuine human collaboration - unpredictable, creative, and uniquely human - is irreplaceable. At the end of the day, human connection remains the strongest foundation for achieving goals and realizing a vision with open source software and all the outcomes of a consortium.