Open Source Deserves Better Than 'Move Fast'

I recently heard an opinion that in open-source development it is more important to move fast and ship features than deliver a stable and reliable solution. I can understand where that comes from, but I disagree.

In the ever-changing business landscape, it is essential to impress users, ship features, and win new customers. Otherwise, your competitors will fill the gaps and you will be out of business. This is especially true today, where AI can produce code very quickly. This is the startup mentality – and it works.

But this mindset is not sustainable when applied to open-source libraries used by hundreds of thousands of developers and running on millions of devices. You never know what software will be powered by your library.

If your library powers a game or entertainment system, a functional failure (setting aside security risks) will affect users’ experience and maybe even ruin the business. But the scope and the severity of the damage is limited.

What if your library runs inside a public sector website, on power plant or transport software, in a hospital information system, or any other critical infrastructure? A functional failure can have severe consequences, including loss of life, property damage, and financial losses. Shipping poorly tested code in such cases cannot be tolerated.

This is especially important today, when such systems are more often targets for hackers’ attacks.

The excuse of “we didn’t have time to test” no longer works. AI assistants can identify gaps, generate adequate tests, catch bugs, and ensure stability. Today’s LLM context windows are large enough to analyze an entire repository and spot weaknesses you might have missed.

But it is the Engineer who should have the final say! They are responsible for the final solution. They should instruct AI to write correct, simple, and understandable code so that humans can still control, understand, and maintain the codebase.

The mindset shift for open-source infrastructure projects should be not only to deliver quickly, but to set the quality bar much higher than before. And let’s not forget: shipping non-working code damages your reputation as a developer and the reputation of your company. Users can easily switch to another project.

The tools are there. The question is whether we have the discipline to use them.