Should You Open Source Your AI Side Project?
Publish the repository and you give away the implementation, not your users, your evals or your domain judgement. Here is how to work out which of those is actually the asset, which licence matches the outcome you want, and what maintaining a public repo really costs per week.
Open source your AI side project if the code is not what makes it valuable, and keep it closed if it is. That is the whole decision, and most people get it wrong in the same direction: they assume the code is the asset, when for the overwhelming majority of AI side projects the asset is the prompt work, the eval set, the data, or simply the fact that you shipped it and nobody else did.
Publish a repository and you give away the implementation. You do not give away your users, your domain judgement, your evaluation harness, or the two hundred hours you spent learning what breaks. Whether that trade is good depends entirely on what you were planning to sell.
First, name what you are actually giving away
Go through your project and mark each piece as published or withheld. Be specific, because "the code" is not one thing.
Component | Usually the moat? | Notes |
|---|---|---|
Application code | Rarely | A competent developer with an agent rebuilds this in a weekend now |
Prompts and system instructions | Sometimes | Easy to copy once visible, hard to arrive at independently |
Eval set and test cases | Often | This is where your real knowledge lives, and almost nobody publishes it |
Training or fine-tuning data | Almost always | Also the piece most likely to carry legal obligations |
Deployment and ops config | No | Publishing this mostly helps people run their own copy instead of paying you |
Users, distribution, brand | Always | Cannot be open sourced, which is the point |
If everything valuable sits in the bottom half of that table, publishing the top half costs you nothing and buys you credibility, contributors and inbound. If your only real edge is in row one, you have a weaker business than you think, and open sourcing will make that visible faster than staying closed will fix it.
Worth being honest about the second row. Publishing prompts is the step people regret most, because a prompt is expensive to develop and free to copy. If your product is essentially a well-tuned prompt over a public model, that is a thin wrapper and publishing it removes the only thing between you and a clone.
The three reasons that actually justify it
Not "community" and not "giving back", which are outcomes rather than reasons.
Distribution. For developer-facing tools, a public repository is a marketing channel that works while you sleep. People find the repo, try it, and some fraction end up paying for the hosted version. This only works if there is a hosted version worth paying for.
Trust. If your tool touches customer data, code, or credentials, being auditable is a genuine commercial advantage. "You can read exactly what we send to the model" closes deals that a privacy policy does not.
Recruiting and proof. A public repo is a portfolio piece that survives your side project dying. For freelancers this is often the highest-return reason, and it does not require the project to succeed.
If none of those three apply, the honest answer is that you want to open source it because it feels good, which is fine, but do not expect it to grow the project.
Picking a licence that matches the outcome
Licence choice is where good intentions turn into commercial mistakes. Match it to what you want to happen next.
You want | Licence | What it means in practice |
|---|---|---|
Maximum adoption, no strings | MIT | Anyone can use it in anything, including a closed competitor |
Adoption plus patent protection | Apache 2.0 | Same as MIT with an explicit patent grant and attribution terms |
Stop a cloud provider reselling it | AGPL-3.0 | Network use triggers the obligation to publish modifications |
Keep commercial control | Source-available, e.g. BSL | Readable and forkable, but not open source under the OSI definition |
The Open Source Initiative's definition is the line between the last row and the rest, and it matters more than it sounds: calling a source-available project "open source" is the fastest way to lose the goodwill you published it for. choosealicense.com is the practical reference for the first three.
One thing specific to AI projects: your licence covers your code, not the model weights or the outputs. Model weights carry their own terms, which are frequently not open source licences at all despite being called open. AI model licences covers the distinction, and who owns AI generated code covers the part where your own repo contains agent-written code.
The cost nobody budgets for
Publishing is free. Maintaining a public repository is not, and the bill arrives in a currency you may not have.
Expect, in the first six months of a project that gets any traction at all:
Issues that are support requests for other people's environments, not bugs in your code.
Pull requests that are 80% correct and take longer to review than to write yourself.
At least one person who is annoyed that you will not add their feature.
A README that is now a product surface and needs to be kept true.
Two hours a week is a realistic floor if anyone is using it. If you do not have two hours a week, publish it with a README that says explicitly that it is unmaintained and issues will not be answered. That is a completely respectable position and it prevents the slow guilt that kills side projects.
The middle options people forget
This is not binary, and the middle is usually right.
Publish the client, keep the server. Very common and very effective. The SDK, CLI or extension is public. The service it talks to is not.
Publish late. Ship closed, get to a stable shape, then open the parts that have settled. Publishing a moving target is what generates the worst maintenance load.
Publish a reference implementation, not the product. A stripped example that shows the technique, with the production hardening left out. You get the credibility without the support burden.
Publish the evals, keep the code. Rare, counterintuitive, and occasionally the strongest move for a domain tool: the tests demonstrate you know the problem better than anyone, and they are the hardest thing to copy usefully.
Decide in ten minutes
Answer these four and the choice makes itself:
If a competent developer read the whole repo tomorrow, what could they build that would hurt you? If the answer is "nothing much", publish.
Are you selling the software, or selling something the software enables? Only the first case is threatened by publishing.
Do you have two hours a week for it? If not, publish unmaintained or do not publish.
What specifically do you want to happen after you post it? If you cannot answer, you are not ready, and validating the idea is the more useful next step.
If you are still weighing whether the project should make money at all, the monetisation guide covers the models that coexist with an open repository and the ones that do not.
FAQ
Can I make money from an open source AI project? Yes, but not usually from the code. The workable models are hosted service, support and deployment, dual licensing, and using the repo as distribution for a paid product. Donations are not a business model.
Will open sourcing get me contributors? Probably not for a while. Most public repositories receive no external pull requests. Contributors arrive when the project is already useful to someone else, not because it became visible.
Which licence should I use for an AI side project? MIT if you want it used everywhere and the code is not your moat. Apache 2.0 if you want the same plus a patent grant. AGPL-3.0 if you are worried about someone hosting it as a competing service.
Does open sourcing my code mean I lose rights to it? No. You keep copyright and you can license the same code commercially to others. What you cannot do is retract the licence from copies already distributed.
What if my repo contains AI generated code? It almost certainly does, and it does not block publishing. Do check that no generated code reproduced something recognisable from a training set, and that your dependencies' licences are compatible with yours.
How did this land?
About the author
Growth & SEO Lead
Manuele covers distribution: SEO, content strategy, and how AI-built products find their first thousand users. He tests everything he recommends.
