Resolutions for Open Source in 2024 - What Has to Change?

Over the past few years, open source has become increasingly polarised. On one side, there are those committed to the Open Source Initiative (OSI) definition of open source. On the other side, there have been multiple commercial open source vendors that have moved to licenses that are not OSI-approved.

What does this mean for open source in 2024? How can the open source community protect its position and ensure that open source software continues to be the first option for new software projects?

Resolution #1: There’s been a loss of trust in open source. We have to fix that Companies release their software under an open source license to get critical mass, grow their communities and develop a potential customer base more efficiently. However, they then see competitors using that same software to build their own products or services that compete with them. Many big names in open source have shifted to a non-open source license to protect their perceived market share and prevent competitors. However they also damaged the reputation of open source in general. These vendors want the benefits that open source offers around community, market reach and developer access, but they don’t want to give up their control and they want to lock out competitors.

For those of us that believe in open source, this is painful. Open source software is valuable because of the community approach that it supports and because it keeps control in the hands of developers that choose software. Without trust in open source as a basis for community development and access to software, everyone loses out.

The answer is that we need more approaches to open source that reflect the needs of the community, not a single company. We have to steer away from the venture capital funding model that demands growth at all costs followed by an IPO or acquisition. Open source foundations represent the needs of the community and all the members involved. They can act as stewards for projects once they have achieved that critical mass, and represent the community more effectively.

Individual companies can also improve how they manage and contribute to the open source community alongside their own business needs. Companies like Confluent and DataStax are successful examples of how to separate the open source project, managed by and for the community, and the products that are aimed at customers. In 2024, more open source companies will have to follow their lead and build both business models and community support together, rather than treating them as separate goals.

Resolution #2: We have to talk about our approach to defining open source Over the last few years, there have been many calls to evolve the open source definition (OSD), which was put together before the advent of cloud computing and ‘as a Service’ providers.

Companies using licenses like the Server Side Public License (SSPL) or Elastic License argue that they are protecting their projects and keeping them viable, rather than letting them be exploited by competitors that don’t pay back to the community. Others argue that open source lets malware creators and other bad actors benefit from software developed by the community, so we should restrict who could potentially use those projects. These arguments have some good points but they go against the primary ethos of open source that everyone should be able to use software for projects as they see fit.

However, open source can’t stand still indefinitely. What started decades ago based on the work of a small but united group of Free and Open Source Software enthusiasts has grown and evolved into multiple groups with different needs and different visions. Proponents of Source Available Licenses with Ethical or Non-Compete restrictions do not see themselves in the same group as Proprietary software, where you do not have access to the source code and can be prevented from doing other things too.

The OSD provides clarity on what can be considered open source and what is not. However, it is easy to see this as two camps that are pitted against each other, when the truth is that there are lots more options available. There is a huge difference in what you can actually do with software that is licensed under the BSD License compared to AGPL 3.0. Each of these licenses exists for a reason. The difference is that open source is about more than free access to software, though that is a major plus point for many that use it. Instead, it is about control.

Open source should be about much more than just the license used for a given piece of software; it is about the community, the governance model for the future of the project, and the value that the project can create over time. However, the license is what provides control over how that software can be used. Without this open and frank discussion around the future of open source, we risk losing what is so important about open source in the first place. Without a strong open source community, we risk handing control back to vendors over what can and can’t be done with software.

Resolution #3 - We have to think harder about the future for projects, good and bad In the technology industry, change takes place all the time, but predicting where the next big leap will take place is hard. For example, AI had been here for decades before ChatGPT launched and generative AI got so much interest. For an outside observer, it might have looked like nothing was happening, but then everything changed. Like a chicken growing inside an egg, there was a lot going on before the breakout moment, and there were many developments and false starts.

What does this mean for open source? It means responding to huge changes in the market as they take place, with new projects reaching a bigger audience than they ever thought possible based on what else is taking place in the market. It means that developers and project leaders have to understand what might happen to them and the projects that they are working on.

At the same time, many open source projects don’t make the impact that they should or fall out of favour. According to research from Sonatype, only 11 percent of open source projects are ‘actively maintained’ by their creators or communities, and this represented an increase of 18 percent over the previous year. Should developers think about handing on control to the source code, letting another person take over leadership on a project? How can a federation or foundation take over when a business or individual can’t generate enough revenue to cover their costs? And what happens to those older projects that are still used, but are not actively maintained?

Talking about sustainability for open source involves thinking about projects that might not have a commercial market opportunity but that need to be supported over time. They may be embedded into other software tools or operating systems, and they need to be looked after where they are viable, and replaced where they are not. The last resolution should be to think about where you can get involved and support contributors and maintainers in these efforts during 2024.