Why the “living from open source” dream is mostly fiction (and what actually works)

I love open source. I publish, I indirectly contribute by engaging my team in OSS projects, and I use it every day. But if you are a CEO thinking about paying salaries with pure open source, don’t live the dream too hard. For a service company, that plan is mostly a fairy tale. GitHub stars do not pay invoices. Good intentions do not replace contracts. And “maybe sponsors will show up” is not a business model, it’s astrology with a README.

Open source software is literally the backbone of business, most of the internet runs on Linux, one of the biggest open-source projects.

1. The three-headed monster: contributors, companies, clients

Everyone claims to do open source

Every modern service company has a slide saying they do open source. Cool. The problem is: in a client project, the incentives are different from those on Hacker News. In a community repo, you chase elegance and stars. In a client project, you chase delivery and invoices. This split changes everything.

The uncomfortable triangle

There are three parties, and they do not want the same thing. Contributors, usually devs like me (or like I was if you listen to my team saying I’m not a dev anymore), want to build something elegant or fun.

The company wants stability, margins, predictable delivery.

The client wants a result that works, simple and boring is perfect. If you forget this triangle, you end up selling a dream to the wrong person.

2. The service company hustle: OSS tool as the swiss army knife (that cuts the client)

How it normally goes down

I have seen it many times. A service company makes a public tool, then tries to fit it into every client project, even when the framework is too big for the project. Devs are happy because they get to work on their baby during work hours. Managers love the story of “we reuse our components, so we go faster”. On paper it smells like efficiency. In reality, clients become beta testers. The code slowly morphs into a homegrown CMS that nobody asked for, with half of the features being decisions made for previous clients. You know the animal, those internal CMS that try to do everything and become legacy one day.

It’s called open source because it actually is, but in reality, it’s a custom tailored tool fitting the company team, and only them understand how it works. So nobody uses it in the real world. Does it really contribute to the ecosystem? I would say no.

Developer motivations, let’s not kid ourselves

Sometimes we push our tool because we want to improve it. Sometimes because it is comfy, like old pajamas. You know its shortcuts, you know its quirks, so you want to use it everywhere. It feels productive. For the client, it creates hidden costs, because now their needs must adapt to the tool, not the other way around.

Scope creep and business theater

In game dev they have a word for this: scope creep. The line between delivering what is needed and polishing your tool disappears fast. Meetings become theater to justify “one more improvement” that is not essential to the client. The best people get bored and leave, because they find themselves maintaining a Frankenstein CMS instead of solving real problems. Technical debt grows, morale goes down, and the client pays for your hobby. Not a good look.

3. Problem-first decision order: BearStudio & Start UI

Here is our opinionated starter, our Open Source flagship that we could use for every project, but we don’t (but click here and give us a star anyway would you? 😉).

Open source is no longer a niche subculture for idealists. It has become a standard across almost every software field, and that changes the quality bar for everyone. When shared tools become common practice, the whole ecosystem improves its expectations, its patterns, and its defaults. That is exactly why we built Start UI, and why I wrote its story in the article dedicated to starters.

Step 1: what is the client’s problem?

At BearStudio we start with one question: “What is the client’s problem?” Not “which tool do we want to use,” not “how do we reuse our starter”, but what must be solved now, in this exact business context. This is the core of serious consulting work, and it is the most valuable part of the discussion.

Step 2: what is the best solution for this client?

Once the problem is clearly defined, we choose the best solution for that specific client. Sometimes the right answer is a mainstream stack without any of our stuff. Sometimes it is custom architecture. We want to optimize for delivery speed, maintainability, and long-term clarity. Ego stays at the door.

Step 3: does Start UI help solve that problem?

If “custom architecture” is the answer, we start by evaluating Start UI. It is never the default, but it’s often the fastest path when it fits (especially for business applications). If it accelerates delivery without creating lock-in, we use it. If it does not, we drop it. That is the discipline: no internal lobbying, no product-first reflex, no forcing “our thing” where it does not fit.

Knowing when to let go

Look at Formiz → https://github.com/BearStudio/formiz

We built it because at the time, existing libs did not cover our needs for forms. Then the ecosystem caught up. So we stopped putting it on new projects, even if it was our baby. We still maintain it for old clients, we do not leave them in the cold, but we are not a museum. This is key, use what serves the client today, not what served you last year.

Start UI is not a CMS

Start UI is an opinionated project starter, not a product you marry for life. It gives a clean base, a structure, sane defaults, and then you can swap parts. It is there to accelerate first steps, not to lock the whole architecture into our worldview. This difference changes the conversation with clients. We are not pushing a platform, we are proposing a starting point we can adapt or drop.

The official image of Start UI Web on GitHub

4. Financials in open source

Spoiler, donations do not feed teams

So many maintainers try donations and while it is beautiful in spirit, it does not pay rent. Freelancers know it well. Companies know it even more. Yes, Wikipedia and Firefox survive, but they are exceptions with massive visibility and legacy. For normal teams, donations are a tip, not a business.

Docker started free and friendly, then reality arrived, they had to build a model that pays salaries. Snapdrop, that simple tool to share files on a local network, got acquired by LimeWire and changed its model. SpacetimeDB exists because there is a huge game studio pushing it with their VC earn dollars, because they are making a commercial product with it.

https://github.com/ClockworkLabs/SpacetimeDB

Github sponsors: the tip jar

Sponsors are nice, it buys you a coffee or two. It will not pay a team of five for a year. It is a thank you, not a plan.

Talent drought

Every open source project is hunting for contributors. They are rare. Even in a professional setup, you get contributions only during limited windows, a sprint here, a hackday there. After that, people go back to client tickets. Sustained, free labor is a fantasy. You, the maintainer, will do most of the work for a long time.

5. How professional OSS actually pays off: the real value

Leveling up, for real

When your code is public, you raise your own standards. You write better docs because strangers will read them. You avoid weird shortcuts. You follow community standards, not internal jungle rules invented in a rush. The bar goes up, and the team grows with it. I saw junior devs accelerate fast because they had to prepare a pull request others could critique. This is something we discussed in our first article about open source: How We Almost Didn’t Start Doing Open Source

Brand, prestige, and street credibility

Developers enjoy contributing. It feels noble, a bit hacker, it gives pride. For the company, it is marketing and positioning. Not the fake kind, the one you earn by shipping useful code and talking about it. It shows that you are building knowledge.

Not owning, not getting bored

In services you never own the product. After delivery you move on. That can kill motivation. An OSS project gives a shared piece of work the team can point to and improve over time. It breaks the loop of closed private repos that nobody will see again. It’s kinda THE product of a service company.

Economic upside, the adult part

The money rarely comes from licenses. It comes from trust. Open source brings audits, leads, workshops, training, architecture reviews. The code is free, but expertise is a product. We have signed projects simply because Start UI proved we know our craft. People come for support and guidance, not for the repo. This is a repeatable model.

6. Networking actually happens: OSS as a magnet

Case 1, the American audit

A US company found us through Start UI on GitHub. No warm intro from a friend, just the repo and docs. They reached out for an audit. We delivered, they were happy, and it paid well. The repo did the outreach so I did not have to.

Case 2, the lazy convention hack

2 years ago at a business event, I joined a small talk group discussion (the guy was speaking about coffee) as I wanted to chill a bit from work discussion. But we are nerds, so the discussion shifted to technical, as usual. I shared my opinions about the importance of opinionated frameworks, of making choices (tradeoffs) to save time, and to own those choices, like we did with Start UI in my second article about open source.

We shared contacts as you should always do in conventions or workshops, and one guy of the group called me back because he needed opinionated techies. That small talk led to €200k in 2 years of work together. We don’t just pretend to know what we’re doing: thanks to OSS everyone can check what we claim.

7. Final word: don’t drink the kool-aid, and don’t serve it either

• Open source in a service company is strategy and reputation, not a magic passive income.
• Give clients what they need, not the tool you want to improve this month.
• Use OSS to raise quality, to teach the team, to build network and trust.
• Keep your tools humble. If the ecosystem catches up, let your thing go, or scope it as a starter, not a CMS.
• The “OSS makes you rich” myth is tired. The version that actually pays is simple, OSS gets you seen, heard, and booked.

This naturally leads to the third article of this OSS series. If more service companies contribute to open source, the ecosystem produces more tools built for real service-company constraints, not only solo-dev workflows. That is exactly the context behind Start UI in the article dedicated to starters, a practical response to recurring delivery problems we saw in the field.

More open source projects lead to a better overall culture and ecosystem, that’s why it’s important to contribute, it’s the pirate bay spirit, like back in the great days of Kazaa, emule and P2P (I miss those days).

If you run a service shop, do open source with clear eyes. Publish because it improves your work, and because it opens doors. Sell your expertise, not a fantasy. The rest is just noise.