From Open-Source Side Project to Product

It starts as an itch. You write a small tool to fix a problem of your own, you put it online and you forget about it. Then someone files a bug report. Then someone else sends a fix. A year later a company you have never heard of is using it, and you are getting messages at the weekend.

This is a happy problem, and a real one. Your side project has become something people rely on. The question is what you want it to be now: a hobby that stays a hobby, a service, a product or a business. This guide is about the choices at that fork: licences, expectations, money and the way you talk to the people who use your work.

Decide what you want first

Before any licence or price, be honest about your goals.

• Do you want to earn from it, a little or a lot?
• Do you want to keep it open for the community?
• Do you want to keep your evenings?
• Do you want to build a team?
• Do you want to hand it on one day?

There are no wrong answers, only choices with consequences. Many projects stay comfortably as hobbies. Some become services. Some become full businesses. Knowing which you want stops you from drifting into duties you never chose.

Licences, plainly

A licence is the permission you give others to use your work. Without one, people generally have no clear right to use, copy or change your code, however public it appears.

The Open Source Initiative publishes a definition of what counts as open source, with criteria such as free redistribution, availability of source code and permission to make derived works. Projects choose from a range of licences that meet it.

Simple guidance sites describe the main families.

Permissive licences, such as the MIT licence, are short and let people do almost anything with your work, including using it in closed-source products. They are easy to adopt and encourage wide use.

Copyleft licences, such as the GNU General Public Licence, require that derivative works are shared under the same terms. They protect the commons: improvements flow back.

Choosing is partly about values and partly about business. A permissive licence maximises adoption but lets others build commercial products on your work without sharing back. A copyleft licence encourages sharing but may deter some companies from using it.

If you are unsure, the "choose a licence" resources help you match a licence to your situation, and a short conversation with someone experienced is worth an hour. This is not legal advice, and licences have legal effect, so read the text and consider professional advice if money is involved.

Changing a licence is hard

Be careful about changing a licence later. If other people have contributed code under the current terms, you may need their agreement. Users who adopted the project because of its licence may feel betrayed by a change, and communities have reacted strongly to such moves.

Better to decide thoughtfully early, and, if you accept contributions, to say clearly how they are licensed. Some projects ask contributors to agree to terms that allow future changes. Others do not. Either approach is a choice. Make it openly.

Ways projects earn

Many successful open projects earn through a few well-known routes. None is automatic, and each takes work.

Support and services. Paid help for companies using the project: setup, training, consulting, priority support.

Hosting. Running the project for people who do not want to run it themselves.

Paid features. A model sometimes called open core, in which a core is open and some additional features are proprietary or paid.

Dual licensing. Offering the code under an open licence and, separately, under a commercial licence for those who want different terms.

Donations and sponsorship. Voluntary support from users and companies. Reliable for a few, modest for most.

Related products. Books, courses, templates or tools around the project.

Open core is a well-known pattern, and also a sensitive one. Communities care about where the line between free and paid falls, and about whether features that were free are moved behind a paywall.

The social contract

Beyond the legal licence, there is an unwritten agreement with the people who use and contribute to your project.

• Users expect the project to stay usable.
• Contributors expect their work to be respected, credited and not taken away.
• Companies expect stability.
• Everyone expects honesty about direction.

Break it carelessly, and you lose goodwill that took years to build. Keep it, and the community will often back you when you need to change.

Practical commitments to consider:

1. Never take away what is free without a long, clear notice and a good reason.
2. Be clear about what will always be open. Write it down.
3. Explain what will be paid and why. Ordinary people understand that maintenance costs time.
4. Credit contributors.
5. Say what you will not do.
6. Give notice of changes.

Expectations and boundaries

A project that gains users gains demands. Without boundaries, they can swallow you.

• Say what support you offer, and when. "Best effort, weekdays, no promises."
• Use issue templates to ask for the information you need.
• Label requests and be clear when you will not build something.
• Close what you will not do, kindly.
• Share the load. Invite co-maintainers you trust.
• Rest. A burned-out maintainer helps no one.

Being a maintainer is a role, not an obligation for life. You are entitled to say "I can't keep this going" and hand it on or let it rest.

From project to product

If you decide to build a product around the project, a few things change.

Reliability matters more. Paying customers expect it to work. Plan for testing, backups and a way to be told about problems.

Support becomes a job. Decide what you offer and set expectations in writing.

Your documentation must improve. A README, getting-started guide and clear FAQ.

You need a legal and financial footing. Once money flows, you may need to register a business, keep records, handle tax and take payments properly. Government guidance describes how to register as a sole trader, for example, and what records to keep. Take advice for your country.

You need clear terms and a privacy approach if you handle other people's data.

Naming matters. Make sure you have the right to use the name, and think about the difference between the open project and the commercial product.

Communication matters. Tell the community what is happening before it happens.

Pricing and what to say

Keep money talk plain.

• State what is free and what is paid, on one page.
• Keep prices in one place, and link to them instead of copying figures into many pages.
• Do not hide paid features behind vague wording.
• Say how paying customers help the project.
• Be honest about limits.

A launch platform listing can help a growing project find new users. The submit page here is one route, and the pricing page explains what is free and optional.

Telling the story

People like to know why a project exists and where it is going. A short post titled something like "What is next for this project" can calm worries and invite support. Cover:

• What the project has become.
• What you are changing and why.
• What will stay the same.
• How people can help.
• How you will communicate.

Invite questions and answer them. Expect some pushback. Most people accept a clear, fair plan.

When to stay a hobby

It is a perfectly good choice to keep a project as a hobby. Signs that it may be the right choice:

• You enjoy it more without obligations.
• The user base is happy and steady.
• You do not want to manage customers.
• The project is small enough to maintain in spare time.

You can still accept donations, welcome contributors and write honest documentation. You are allowed to remain small.

A short worked example

A maker writes a small command-line tool for converting files and publishes it under a permissive licence. Within a year, a few hundred people use it and two companies ask about support. He decides to keep the tool open and to offer paid support plans and a hosted version. He writes a page stating what stays free, what is paid and a promise not to move existing features behind a paywall. He thanks his contributors by name, closes feature requests he will not build with kind notes and invites one of the active contributors to co-maintain.

He registers as a sole trader, writes simple terms and keeps prices on one page. Revenue is modest, the community stays, and he keeps his weekends. The project is still his hobby, with a small business beside it.

Common mistakes

• No licence.
• Changing the licence suddenly.
• Moving free features behind a paywall without notice.
• Promising support you cannot give.
• Hiding the commercial side.
• Ignoring contributors.
• Burning out.
• Skipping the legal and financial basics.

On this site

The submit page lets you list a project as it grows, the launches page shows what other makers have built and the developers page describes the free API and MCP server. The pricing page explains what is free and what is optional, and the founders page tells the story of the people behind this place.

The short version

Decide what you want from the project before you choose a path. Pick a licence that matches your values, remember that changing it later is hard, choose earning routes that fit and keep a clear social contract with users and contributors: do not take away what is free, explain what is paid and credit people. Set boundaries on support, get your legal and financial basics right and tell the community before changes happen. You are allowed to stay small.