Does publishing open-source tools actually bring clients to a software studio?

It can, slowly and indirectly. A public repository works as proof of competence, as a demo that runs without a sales call, and as a reason for someone to write to you before a proposal exists. It does not create demand or replace selling. The return compounds rather than arriving at once, and the result depends on whether anyone actually searches for the problem your tool solves.

Which licence should a studio pick for a tool it publishes?

Pick by intent. A permissive licence such as MIT lets anyone use the tool in their own product, including a closed-source one, which is what you want when adoption is the goal. A copyleft licence such as GPLv3 keeps distributed derivatives open, which suits a case where the code is what a competitor would copy. Source-available is a third option when the code is the product itself, and it should be described as such rather than as open source.

What should an open-source README contain?

The problem the tool solves in one sentence, then a command that works as written. After that: the limits you know about, the licence, and what you promise about issues. A feature list belongs lower down, because the person reading is deciding whether to spend ten minutes, not comparing specifications.

Do GitHub stars help a studio win work?

Mostly no. A star costs one click and measures how shareable a project looks, not whether anyone uses it. The signals that correlate with work are referral traffic from the repository and package pages, mentions elsewhere, and messages that name the tool. Track those instead, along with the hours the repository costs you each month.

Can I publish a tool built for a client?

Only if the contract allows it and the client agrees. Check who owns the code first, since many contracts assign it to the client. Then remove everything specific to them: names, data, screenshots, private schemas and any code you did not write. Publish the abstraction, rewritten against a problem other people share. If the tool only works with their setup, it is not a public tool.

Open Source as a Sales Channel for a Software Studio

Publishing tools is distribution that compounds: what a public repository really earns a services business, what it never will, and how to run it deliberately.

By Alexandru Secureanu22 October 20269 min read

A public repository is the only marketing asset we own that keeps working while nobody tends it. A sales page needs ads to be seen. A blog post needs a search ranking and then slowly loses it. A tool that solves a real problem gets installed, and every install leaves a trace that leads back to the studio that wrote it. That is the whole argument: publishing is distribution, and distribution compounds.

We run a small studio in Bucharest, so this is not a story about how open source made someone famous. It is what we do with two tools of our own, what it buys a services business, and what it does not. Where a claim is our impression and not a measurement, we say so.

What a public repository does for a services business

Three things, in the order they happen.

Proof of competence. A client cannot audit a proposal, but they can open a repository. The commit history shows how you work when nobody is presenting. The tests show whether you believe your own claims. The naming, the error messages and the issue replies show how you treat people who are not paying you yet. Nobody reads all of it. The people who can read code read enough, and those are the ones who sign.

A demo that is always on. Our config tool runs with npx open-gsd-core-config-manager. VoiceSynth runs a line of Python with a backend flag. There is no account, no trial, no call to book. A prospect can decide whether the thing is serious before talking to us, which reverses the usual order of a sales conversation.

Inbound that arrives without a proposal. The first message is often a question about a flag or a bug report, not a request for a quote. Someone who has already run your code has qualified themselves better than any form could. This part is opinion rather than measurement: our own repositories are months old, and we cannot yet show a conversion rate from repository to signed work.

What a public repository does not do

It will not outrank a marketing budget. A repository is not a search channel in the way a page written for a keyword is. GitHub's own search is used by people who already know what they are looking for, which is useful and also a ceiling. If nobody searches for the problem, the repository waits.

Most repositories get almost no attention, and ours are a fair example. As we write this, both of the repositories linked below show zero stars and zero forks. One has 383 commits, the other seven. Stars measure how shareable a project looks, not whether it earns work for the studio behind it.

It does not create demand. If the problem was not already costing someone time or money, publishing a solution gives you a maintenance bill with no matching interest.

It does not replace selling either. It shortens the part of the conversation where a stranger decides whether you can build, and leaves the price, the scope and the trust where they were.

Start from a problem you were already paid to solve

The rule we use is one tool per problem that a client has already paid us to solve. A problem that has cost someone money has a shape: inputs, failure modes, the workaround people used before, the places where it breaks. That shape is most of the README already.

Our config tool exists because GSD's config.json carries more than two hundred nested keys and the meaning of most of them lives in the source code. We had spent enough hours in that file to know which mistakes people make. The article on this site about treating a config file like an API is the argument; the tool is the same argument with a command attached.

The constraint that matters more than any of this is client material. Publish the abstraction, never the client: no names, no data, no screenshots of their admin, no code you do not own. If the tool only works against their private schema, it is not a public tool. Rewrite it against a problem other people share, or leave it private. When the work was done under contract, check who owns the result before you publish a line of it.

The README leads with the problem and a command

A README that opens with a feature list is written for the author. One that opens with the problem and one command is written for the person deciding whether to spend ten minutes.

Ours opens with a single sentence: understand and safely edit any GSD config.json without reading the gsd-core source. Then the command. That is the pattern worth copying: what it is for, then the thing to type. Features come after, and fewer of them than you think.

Put the limits in the README as well. The VoiceSynth documentation lists which backends are implemented, which need an external package and which are scaffolds, because a feature matrix that claims more than the code is a support queue you created yourself. A stated limitation costs one paragraph and saves months of replies.

The README also has to state the licence and what you promise about issues, both in the first screen rather than in a file nobody opens.

Documentation needs its own site

The README is where someone decides. The documentation site is what gets linked. Search engines index it, forum answers paste a deep link to one page, and a page whose heading matches a question is easier to cite than a long file inside a repository.

We run two this way: gsd.danubelabs.net and tts.danubelabs.net. Both open with what the tool does and the command that starts it. The GSD site documents 201 canonical keys and leads with the promise that every key is explained, validated and reversible. The VoiceSynth site carries install, CLI and GUI, a backend matrix derived from the source, limits and an FAQ. The design is not the point. Each page answers a specific question under its own heading, so it can be found and linked away from the repository.

The cost is a second thing to keep in step with every release. Generate the reference part from the code, keep the prose short, or accept that some pages lag and date them. Drift is a standing item, not a task you finish.

Choose the licence that matches the intent

A licence is a business decision wearing a legal costume. The two directions are easy to state, and choosealicense.com puts them in one line each: MIT lets people do almost anything with your project, including making and distributing closed source versions, while GPLv3 allows the same except that.

We use MIT for both tools because the goal is adoption. Someone should be able to drop the tool into their own product, including a commercial one, without asking us first. That is what turns a repository into distribution. If the tool were also the product we sell, MIT would be the wrong choice.

Copyleft fits the other case: the value you sell is a managed or hosted version, and the code is what a competitor would copy. GPLv3 keeps distributed derivatives open. If people reach your software over a network instead of receiving a copy, read the AGPL text itself rather than a summary like this paragraph.

There is a third option, source-available. You publish the code, let people read, run and evaluate it, and do not let them redistribute modified versions. One of our desktop apps ships that way. It is not open source and we do not call it that, but it is honest when the code is the product.

Maintenance is part of the price

Every public repository is a promise to strangers, and the promise is paid in hours. Issue triage, dependency updates, upstream churn, security reports that arrive in private mail, and the recurring question about an old operating system.

Decide the promise before you publish and write it into the README. Either a response window you can actually keep, or a plain sentence saying that issues are read, fixes are best effort and no support is promised. Both are acceptable. Silence is not, because people read silence as support and then get angry when it turns out to be nothing.

Budget the hours explicitly. For us it is a dependency pass on a schedule, keeping the documentation in step with releases, and reading issues. It is not enormous, but it recurs, and it comes out of the same week as client work.

Measure referrals, mentions and work won

Four things are worth watching, and none of them is the star count.

Referrals in analytics. Sessions arriving from github.com, from npm and from the documentation domain. The number can be small. The question is whether it is above zero and rising.
Mentions. Links from other sites, package dependents, a line in someone else's README. These are the ones that keep sending people for years.
Inbound that names the repository. A message saying they found us through the tool is worth tagging in whatever you use to track leads, because it is the only clean attribution you will get.
Time spent against work won. Hours per month against signed work you can trace back to a tool. The attribution will be incomplete, and a rough ratio is still enough to decide whether to continue.

Do not optimise stars. A star costs the person one click and tells you how shareable the project looks, which is a different question from whether anyone uses it. A repository with a thousand stars and no referrals has bought you nothing you can invoice.

A repository without users is a cost, and deleting is allowed

The failure mode is not a controversial licence or an ugly README. It is a tool nobody installs that you keep updating out of guilt. It costs hours every month, it makes the portfolio look busier than it is, and it teaches you nothing.

Set a review date when you publish. If by that date the referrals are zero, nobody has opened an issue, and you no longer use the tool yourself, archive it with a note in the README or delete it. Deleting removes the obligation and the false signal. A studio with two tools people use is in a stronger position than one with six that nobody touched, and the portfolio is more convincing when it is not padded.

Our own position, for the record: the two tools above are months old and have no stars. We are not going to claim a repository brought us a client, because so far it has not. What we can defend is the mechanism, and the honest description of this bet is a low monthly cost against a compounding return that has not arrived yet. If the referrals stay at zero on the review date, this article becomes the record of something we tried, which is also useful.

If you are building something worth publishing

Danube Labs is a founder-led software, AI and automation studio in Bucharest. If you have a problem you have solved twice by hand, it may be worth turning into a tool. See custom software for how that work runs, browse the portfolio for the tools we have published so far, or book a free intro call.

Frequently asked questions

Does publishing open-source tools actually bring clients to a software studio?: It can, slowly and indirectly. A public repository works as proof of competence, as a demo that runs without a sales call, and as a reason for someone to write to you before a proposal exists. It does not create demand or replace selling. The return compounds rather than arriving at once, and the result depends on whether anyone actually searches for the problem your tool solves.
Which licence should a studio pick for a tool it publishes?: Pick by intent. A permissive licence such as MIT lets anyone use the tool in their own product, including a closed-source one, which is what you want when adoption is the goal. A copyleft licence such as GPLv3 keeps distributed derivatives open, which suits a case where the code is what a competitor would copy. Source-available is a third option when the code is the product itself, and it should be described as such rather than as open source.
What should an open-source README contain?: The problem the tool solves in one sentence, then a command that works as written. After that: the limits you know about, the licence, and what you promise about issues. A feature list belongs lower down, because the person reading is deciding whether to spend ten minutes, not comparing specifications.
Do GitHub stars help a studio win work?: Mostly no. A star costs one click and measures how shareable a project looks, not whether anyone uses it. The signals that correlate with work are referral traffic from the repository and package pages, mentions elsewhere, and messages that name the tool. Track those instead, along with the hours the repository costs you each month.
Can I publish a tool built for a client?: Only if the contract allows it and the client agrees. Check who owns the code first, since many contracts assign it to the client. Then remove everything specific to them: names, data, screenshots, private schemas and any code you did not write. Publish the abstraction, rewritten against a problem other people share. If the tool only works with their setup, it is not a public tool.
When should you delete or archive an open-source repository?: When it costs maintenance and returns nothing. Set a review date when you publish. If by then referrals are zero, nobody has opened an issue and you no longer use the tool yourself, archive it with a note or delete it. A tool nobody installs is not a portfolio asset, and removing it makes the rest of the portfolio easier to believe.