What Happens with Open Source in the Age of AI?

AI has changed the calculation on the benefits of Open Source. We have also been affected by this: more often than not, users today just prompt something to Claude or Codex, and then send us the result, with the level of quality ranging from mediocre to outright broken. Because we still place a high value on code reviews, and will continue to do so, this creates a situation where submissions can easily overwhelm the project maintainers.

One common road we see people taking these days is the adoption of "the SQLite model": Open Source, but not Open Contribution, with a proprietary test suite to prevent the now aptly named "slopforks". There are often predictions that this will only increase. This is interesting to see, because our project, Turso, was born exactly in opposition to that model: we are a full rewrite of SQLite in Rust, with an Open Contribution model (which includes the entire test suite and testing methodology).

In this article I want to make one thing very clear: Turso will continue to be a fully Open Source project, with a vibrant community. It is undeniable that AI has drastically changed the calculation on a lot of things, so we will examine what positive and negative effects we are seeing. Then we will discuss how we think about them from first principles, and what we plan to do to handle them.

#Why is Turso Open Source?

For us, the inspiration of building Open Source software has always been the Linux Kernel. Both Pekka and I have spent the first decade of our careers writing code for the Linux Kernel. I was consistently among the top contributors to the Kernel, while Pekka was one of the core maintainers of one of Linux' most important subsystems (memory management). We saw first-hand the transformative power of how a true Open Source community can unleash unbelievable levels of creativity and resilience, and we try every day to bring those lessons to life.

From the start, we always stated that we don't see Open Source as a growth hack. We are replacing one of the key building blocks of the modern software stack. A piece of technology that is reliable and beloved, but doesn't allow any outsider to influence the direction of the project.

In light of that, our main goal can be summed up as: Give people a seat at the table.

The true power of Open Source is not realized when people write code for your project. It is realized when people can set the direction of the project.

At the same time, design by committee is never the way to build anything. Giving people a seat at the table does not mean spreading chairs around, opening the doors, and letting anyone come from the street and take a seat.

#The benevolent dictator model

One of the ways people have commonly referred to Linus Torvalds in the Linux world was as the "benevolent dictator". Below him, the maintainers were the benevolent dictators of their own realms. It was always clear to everyone involved that there was no democracy there. People either follow the person in charge, or they walk. And the reason people stay and contribute is that the incentives of the benevolent dictator are perfectly aligned with the success of the project.

The biggest difference between that and other arrangements is how those people get there. They are not randomly appointed, born into it, nor politically assigned.

People got there because of the work that they did. By doing the work, and by showing that the work was high quality, those engineers have demonstrated a couple of things:

• That they can be trusted to make good technical decisions
• That they are willing to put the technical work to push the project forward
• That their motivations are such that the project success is also their success

At Turso, we follow a similar model. Contributors and maintainers are not appointed: they emerge. Someone who consistently submits high-quality, well-vetted work, engages thoughtfully in reviews, and demonstrates they understand the project's direction will naturally be given more responsibility and trust over time.

#The dynamics of Open Source

Some common reasons software gets Open Sourced are:

• It builds trust: users can see what is going on, and understand that the software does what it claims to do, without any hidden backdoors.
• It drives the cost of adoption to near zero, which helps the project take off and be adopted at scale.
• Users can fix their own issues, which helps the project address a long tail of issues that would otherwise be not handled.
• It gives users peace of mind that the project is sustainable and they will not lose access to the product if a vendor suddenly disappears.

For the participants and newcomers to a community, there are many advantages of participating in OSS as well:

• They learn a lot, which is particularly valuable in the early stages of their career.
• They gain visibility, which helps them find better and more abundant job opportunities.
• They can control or influence the product roadmap, which is particularly important if your company depends on that Open Source technology.

This has traditionally been a fair trade for all involved, which is why Open Source works. Yes, your code can be trivially copied, forked, and used for free. But both the group releasing things as Open Source and the individuals and businesses contributing to the project gain more than what they lose.

So it works.

#AI and Open Source

We are big believers in AI. By now, almost 100% of the code in Turso is written by AI tools. However:

• We review the code closely.
• We participate heavily in the architecture of the code.
• We follow a testing methodology with a rich and extensive mix of unit tests, integration tests, deterministic simulators, differential fuzzers, and the occasional formal verification.

That work is exactly what we expect our contributors to do.

SQLite is one of the pillars of our industry. We couldn't do any less if we want to carry forward the task of replacing it. We have been doing that work from the beginning. We were doing all of that, and writing code. Now we do all of that, just don't write the code that often.

What is clear in that description is that regardless of who is writing the code, there is still a lot of work to be done. And because of that, nothing really changes in our motivation and calculation: we want to give people willing to do the important work, whatever that work might be, a chance of being a part of our community and a way to earn their seat at the table.

In a lot of ways, the work of a Linux maintainer was always very similar to a modern LLM engineer: you have a flurry of code coming your way constantly, and your work becomes less about writing code, and more about helping people figure out what standards to follow, what work to do, and where to keep the bar for acceptance.

Because of that, a lot of what is going on feels familiar, and we truly don't mind the avalanche of PRs coming our way. The PR authors benefit from it, and that is great. And the project benefits from it. However, writing the code used to be enough proof that you have done the work to earn a claim on other people's time to review it. This part is no longer true.

The work has to be valuable, and writing code just isn't anymore. But so much else still is.

#The current landscape

At Turso, we have been as plagued by clearly slop submissions as anybody else. The amount of PRs have grown so much that it's become essentially impossible to review them. Most of the time it is abundantly clear that the submitter has done no real work: they just prompted "implement X" on OpenCode, and submitted the result.

No work was even done to figure out what to do, since we have a compatibility matrix of SQLite features that are not implemented yet. Submitters have a large list of features to choose from, that they can just prompt and get a result.

Prompting OpenCode and submitting the result generated zero work for the submitter, and a lot of work for the reviewer, who had to go over the submission and find the often large amount of flaws in it.

We could have done that. We could look into the list of missing features in a loop, ask AI to implement them, and commit the result. If we haven't done that, we have our reasons.

And the reason is: we want to make sure that all the code that goes into Turso is high quality: it is extensible, well architectured, and performant. That requires work. We want anyone to be able to do that work and as a result, earn their seat at the table. That is the work that has to be done.

#In practice

We expect the PRs to be the result of a long and arduous process in which it becomes apparent that you have done the work to vet the output of the LLM, and iterate on it until it is good. That doesn't mean the work is perfect. Maintainers will be there to help you get that code to where it needs to be for merging. But you must have done the work first, and the result of you interacting with the LLM to produce the work has to be of very high quality.

Especially for newer contributors, there are two ways to show that this work has been done: one of them is just the fact that the resulting code is of high quality, and passes other people's scrutiny. But also, our PR templates include a session where you are encouraged to describe how AI was used. You shouldn't see this as an opportunity to disclose the use of AI: we at this point would find it weird if you didn't use it, but rather to tell us what you did, and how you employed AI to achieve the result you are now submitting.

If it becomes clear that you have done zero work to submit your PR, your PR will be closed. If it becomes clear that this is not a one-time issue, but your modus operandi, we will just not look at your future PRs at all.

This may sound elitist. And unfortunately, it is. But that is the bar we need to keep, and we can assure you that if you show up and demonstrate that you can do this work, you will earn your seat at the table, regardless of what your motivation is: be it learning, improving your resume, or because you are using Turso in your business and want to make sure that it goes in a direction that makes sense for you.

Expect this to evolve with time. In this article, we are more concerned with presenting the spirit and motivations of these policies, rather than making final determinations. The landscape is just changing way too fast for us to set something in stone.

#Conclusion

From the start of our project, we have had a strong commitment to Open Source. AI is a thing now, and it changed the calculation for everybody, including us. Many projects are steering away from Open Source altogether, or experimenting with hybrid models.

Turso wants to reiterate, and in fact double down, our commitment to Open Source. There is lots of work to do to redefine what SQLite could be. The bar to participate in this development has not gotten lower. On the contrary: just "writing code" just doesn't cut it anymore. On the other hand, the tools are getting so good, so fast, that we expect a lot more people to be able to contribute to it in a significant way.

It is genuinely exciting to see in practice how people with very little prior experience in databases can go from zero to hero in just a few weeks and become active members of our community. And those who do good work, will always have a seat at the table.

If you are interested in joining us for the ride, open your LLM-powered code editor, engage with the result, iterate on it, and come build Turso with us on Github.