Free software needs free tools

Welcome to LWN.net The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net!

One of the contradictions of the modern open-source movement is that projects which respect user freedoms often rely on proprietary tools that do not: communities often turn to non-free software for code hosting, communication, and more. At Configuration Management Camp (CfgMgmtCamp) 2026, Jan Ainali spoke about the need for open-source projects to adopt open tools; he hoped to persuade new and mature projects to switch to open alternatives, even if just one tool, to reduce their dependencies on tech giants and support community-driven infrastructure.

Ainali does contract work for the Swedish chapter of the Wikimedia Foundation, called Wikimedia Sverige, through his company Open By Default. Wikimedia, of course, provides the MediaWiki software, hosts Wikipedia, and much more. He said that all of the tooling, everything in production, the analytics, and so forth is open source. "There is a very strong ethos in the Wikimedia movement to do it like that."

However, that ethos weakens the farther away one gets from development. "When you step away from development to the more peripheral parts of the workflow, it gets less and less open source in the tooling." For example, Wikimedia uses the proprietary Figma software for design, and its annual conference uses Zoom to record talks and publishes them on YouTube. Even projects that have a strong drive to do something open, he said, struggle to do everything using only open-source software.

He emphasized that the presentation was not a rant against open-source projects using proprietary software. He said that he understood that it might be challenging to use more open-source tools and to move away from proprietary ones. It is particularly difficult, he said, for projects that have to work with other parties which have constraints or requirements in the tools they use. "Even though I am going to say a lot of things here, it is all coming from a place of love and a wish for change."

Tools shape culture

Proprietary tools come with many kinds of restrictions, he said. For example, perhaps users are limited in the ways they can export data, or customize tools to suit specific workflows. There are many things that would be possible with open source that are not possible with proprietary tools; a project cannot make a tool its own if it does not have the ability to modify the software.

The tools also shape a project's culture, Ainali said. First, someone suggests using a tool that is not open source. "It's never with a bad intent. It's often like, oh, it has this feature that I cannot find anywhere else." But that is a slippery slope, he said, a bad spiral. Once the decision is made to use one proprietary tool, it becomes easier to do it the next time. "If our design guide is already in a proprietary software; maybe the next thing in the toolchain also could be like that. You don't have the same incentive to stay open." That, in turn, leads to exclusion.

There are also instances where geopolitics come into play, such as the incident when the Organic Maps project lost access to GitHub, presumably because it had some contributors from Russia. "And this is not because GitHub has something against Russia, it's because where they are located and their local laws." The flip side of that is that some contributors may not want to provide data to a platform that might be required to hand over data to its government. Especially when that platform is in another country.

Even in the absence of political interference, he cautioned that dependency on closed platforms posed other problems. "They try to lure you in, and then to lock you in, so that it will be difficult to leave." It is especially easy for open-source projects to be lured in, he said, because many platforms start out with free tiers or special deals for nonprofits and open projects.

And, of course, there's this lovely term from Cory Doctorow, "enshittification". He defined a couple of phases of how things get worse over time. First, you get lured in, and when they have a very large user base, they feel like they can extract more and more value out of you. It's not like they deliberately try to make it worse for you. It's just going to become worse for you as a user. Maybe it becomes more expensive. Maybe they extract more data out of you. Maybe they are trying to monetize on that data by selling targeting ads in the other end. So it's sort of like just working towards something getting worse.

At the same time, proprietary cloud platforms and services get value from open-source projects, he said. The company gets metrics, usage data, bug reports, and may be advertising that "this open-source system is using our product". Projects can also be victims of a company's whims. A platform can decide at any time to end its free tiers for open-source projects, or change its terms of service: "Suddenly it says in the new [terms] update that 'oh, now we're going to use your data for training AI'."

There are also scenarios where a company is not trying to take advantage of open-source projects, it simply makes a business decision to close down a platform or service that it no longer considers profitable. That leaves the open-source projects that depend on it in a bad spot; if a project had been using something that was open source it could spin up a local deployment and maintain the software itself. With proprietary services, of course, that is not an option; once the plug is pulled, the party is over.

Losing contributors

Ainali said that choosing open tools is not "just a purity test". Some people will be discouraged from participating because they simply do not want to use proprietary tools. But if a project is requiring proprietary tools to participate, it may mean that some people literally can't participate. For example, if a tool requires using macOS, then it excludes participants that do not use that operating system. In some parts of the world, he observed, people may only have the option of running an open-source operating system because everything else is too expensive.

Accessibility is another consideration. Many proprietary tools "are very slick, but they may not have good accessibility". Open-source tools may not be beautiful, but they are functional, he said.

Even if the project does not fully lose contributions from a person, it may not get full participation. Perhaps a person continues to make code contributions, but they do not join video calls to discuss project direction, or participate in text chats because the project uses a proprietary product for those activities.

So you're losing an important voice in your community. They might stay on the trusted old mailing list. And these people that are often very experienced, and know very well how their data could be used. So they're happy voting with their feet and not going in there. They care a lot about their freedom and they care a lot about their data. On the flip side, they are also often very knowledgeable in open source too, because they've learned that they don't want to be locked in with proprietary tools.

He encouraged projects to invest in their own ecosystems by deploying open-source tools, adding features if necessary, improving documentation, submitting bug reports, and so on. He anticipated a counter argument: "'The proprietary tools are so much better', you scream. 'We cannot use these [open] ones.' Well, we're getting ourselves in a convenience Catch 22". Ainali acknowledged that, sometimes, proprietary tools were better from a technical perspective. "But they're bad for your resilience, for your project sustainability. And you could be helping to improve those open tools instead."

As long as open projects are using the proprietary tools, they're providing the metrics to improve them. If the projects are paying for proprietary tools, then they're funding the improvement of those tools. "So instead, you should try to help the community catch up and expand." It will be difficult to break free of proprietary tools, he said, if projects keep using them and giving them all the benefits of their use.

Ainali also predicted that people would object to leaving proprietary platforms because "everybody's already on this platform"; he did not say it, but that seemed to be primarily directed at proprietary code forges such as GitHub. The network effects of such platforms do not last, he said. "We have seen plenty of social media platforms rise and go and other tools come and go", because they need to make a profit or perish. "Whereas maybe open-source tools are more resilient because they don't need the same extraction of value from their users".

Start small

Projects should experiment, he said; perhaps try to mirror Git repositories onto a freer platform. When projects need to choose a new tool for something, they should choose an open tool. Above all, he said that a project should listen to its community and start moving to open tools where it makes the most sense for the community. "Don't wait. It really should have started already, but it's never too late to start now. It's never a bad time." It is also not all or nothing, he said. Projects do not have to become "pure" overnight, or try to switch everything all at once. There are many places a project can start.

You pick one tool. You make one change. You evaluate, "did that work?" If it doesn't work, if it turns out you really need that feature, don't be afraid to roll back. Often with your community it will go well if you radiate the intent why you're wanting to do this change. That everybody can see, "oh, this is coming for our sake in the long run". It will make us more sustainable. It is possible, and when it works, it's really contagious. And don't beat yourself up if you cannot do it all at once. It is okay to not be perfect.

He closed out his talk by arguing that projects had made a choice to be open source, and that choice should be reflected in the tools used by the projects as well. Open source, he said, is more than code and licenses: "it is a culture, it's a way of working, it's the community, and it's the freedom that these licenses allow us". Projects, he said, should not try to build that freedom on a foundation that they do not control.

[Thanks to the Linux Foundation, LWN's travel sponsor, for funding my travel to Ghent to attend CfgMgmtCamp.]