Open Source x AI x Privacy: A Builder's Playbook for What's Next

Every few weeks, there is a new model, tool, or agent that changes what developers can build. A small team can now go from an idea to a working product faster than ever. That is exciting, but it also means we are making important decisions about security, privacy, and trust at the same speed.

Sometimes we make those decisions without even knowing we are making them.

We add another dependency. We send user data to another model. We ship a feature before deciding what information should remain private. Then, when the product starts growing, we try to add trust back into the system.

I gave a talk at DevFest Lagos in 2025 about the relationship between open source, AI, and privacy. The point of the talk was not to slow builders down. I wanted to share a practical way to build fast without treating responsibility as something we can fix later.

This is the written version of that playbook.

Three principles to start with

For builders working with AI, open source and privacy, there are three principles worth carrying into the work.

The first is to build in the open so you can move fast and fix fast.

The open source culture gives people a way to inspect your work, question your decisions, report problems, and improve what you have built. The feedback loop is shorter because the people using the technology can also participate in its development.

The second is to treat trust as an engineering requirement.

Trust is not a sentence on a landing page. If a system cannot be verified or audited, then we are asking people to believe what we say about it. That may work until the system is under pressure or something goes wrong.

The third is to make privacy the default.

If your product touches personal or sensitive data, privacy should not depend on whether a user discovers the right setting. It should be part of the architecture from the beginning.

Open source is the foundation, but it is not automatic security

Much of the infrastructure behind modern AI is built on open source.

The frameworks used to train models, the libraries behind data processing, and many of the tools used to deploy AI systems move quickly because developers build and share them in the open. Even when the final model is closed, there is a good chance that open source software exists somewhere underneath it.

I have spent most of my career in open source, from Sugar Labs and OSCA to contributing to the global process behind the Open Source Initiative’s Open Source AI Definition. One thing I have learned is that access matters. People cannot properly study, modify, or improve systems they are not allowed to inspect.

In 2023, during Sam Altman’s world tour, I was invited to join a small group of people from the Nigerian tech ecosystem for a conversation with him in Lagos.

https://x.com/Samson_Goddy/status/1659607174895620098

I used the opportunity to ask whether OpenAI planned to release an open source model because, even then, AI was becoming one of the world’s most important technologies, while most people could only experience it through products controlled by a few companies.

The work around the Open Source AI Definition became important for the same reason. Calling an AI system open source should mean more than making a few files downloadable. People need the freedom and enough information to use, study, modify, and share the system.

But open source creates visibility, not immunity.

Attackers can inspect public code too. Dependencies can be compromised. A maintainer account can be taken over. A small package buried deep in a dependency tree can become a problem for thousands of applications.

I saw this more closely during my time at Chainguard, working around Sigstore and the OpenSSF ecosystem. Software supply-chain security taught me not to confuse “the code is available” with “the code is safe.” Openness makes verification possible, but builders still have to do the verification.

For AI builders, that means thinking beyond the model. Where did the model come from? What data or tools does it connect to? Which packages sit underneath the application? Can you verify the artefacts you are deploying? What happens when one component changes?

An open foundation is powerful, but it still needs security practices that people can rely on.

If your foundation is open, privacy and security cannot be optional.

Privacy is not secrecy

One question I asked during the talk was: why do we keep treating privacy as secrecy?

Privacy does not mean hiding everything. It means giving people control over what they reveal, to whom, and for what reason.

There is a difference between proving something and exposing all the information behind it.

A service may need to know that I am old enough to use it. That does not mean it needs my full date of birth, home address, and a copy of my identity document stored in another database.

A financial application may need to confirm that someone meets an eligibility requirement. That does not always mean it should see the person's complete financial history.

This matters even more with AI because these products depend heavily on data. The easiest pattern is to collect as much data as possible, move it into a central system, and promise to protect it. But every piece of sensitive information we collect becomes something we are responsible for protecting.

The better question is not, “How much data can this product use?” It is, “What is the minimum information this interaction needs?”

That is where privacy-first development begins.

The tools are already here

Privacy-first AI is not only an idea. Builders now have practical technologies that can reduce how much personal information a system needs to collect, move or expose.

Federated learning allows a model to learn across different devices or environments without moving all the raw user data into one central store.

Differential privacy makes it possible to learn patterns from a dataset while reducing the risk of exposing the people represented in it.

Zero-knowledge proofs allow someone to prove that something is true without revealing all the information behind it.

These technologies solve different problems, and using one does not automatically make a product private. Builders still need to understand what they are protecting, who they are protecting it from and what the system could reveal unintentionally.

What they show is that privacy does not have to come at the cost of functionality. We can build useful applications without collecting or exposing more information than the application actually needs.

The age-verification example I mentioned earlier is no longer theoretical. World Foundation recently released ProveKit, an open source toolkit that generates zero-knowledge proofs directly on a user’s device. It can prove that someone meets a minimum age requirement without revealing their exact age or the personal information contained in their passport.

The private information stays on the device, while the verifier only learns that the required claim has been proven. ProveKit also works offline and was designed for browsers and constrained phones, including devices that cost as little as $40. This matters because privacy technology cannot claim to work for the real world if it depends only on flagship phones, expensive hardware or perfect internet access.

The other part I find important is trust. ProveKit does not require a trusted setup; its implementation is open source and it has been independently audited. Developers can also use Noir to define new claims that people should be able to prove privately. This makes it more than an age-verification feature; it gives developers a way to build other applications around selective disclosure.

ProveKit shows what privacy by design can look like in practice: the user reveals only what an application needs, the proof happens on their device and developers can inspect and build on the technology underneath it.

Technology still needs builders

Having the right technology is only one part of the work. Developers still need a clear way to understand it, test it and move from an example project to something people can actually use.

During my time at Midnight Foundation, I worked on developer engagement for Midnight, an open source blockchain built for applications that require privacy while still allowing information and actions to be verified. Its Compact smart contract language allowed developers to define what should remain private and what could be selectively disclosed.

My focus was on the next challenge: how do you help developers move from understanding privacy technology to building real products with it?

We designed a community structure that connected these stages rather than treating documentation, bounties, and hackathons as separate activities:

Docs → dApps → bounties → hackathons → Build Club → real products.

Documentation helped developers understand the technology, while building a first dApp turned that learning into practice. Bounties gave them specific problems to solve, and hackathons created room to test larger ideas and get direct feedback.

Build Club was designed as the next step for projects that showed potential but needed more time after the hackathon. The goal was to stop good projects from disappearing once the event ended and give builders a clearer path towards creating something real.

The structure also created a feedback loop for the product. At every stage, developers showed us where the documentation was unclear, where onboarding became difficult and where the technology did not match the way people wanted to use it.

This is something open source has taught me repeatedly: giving people access to technology is not enough. They also need a path to participate in how it develops.

That is the larger lesson I wanted builders to leave with. Build in the open, treat trust as an engineering requirement, and make privacy the default. The technologies will continue to change, but these principles give us a way to build quickly without asking people to surrender more trust or information than our products actually need.