You cannot un-publish the source. Why open sourcing is a 1 way door

Someone suggests open sourcing the SDK. The reasoning is familiar: developers will adopt it, contributors will improve it, and it costs nothing because that code was never the product.

Two of those three are forecasts. The third is wrong, because the cost is not the code, it is the obligation you acquire the day you publish it.

The decision is whether to publish part of your product under an open licence, and what to expect if you do. The features that fire are a shared resource that will need governing, an outcome whose frequency is knowable and never checked, and a commitment that cannot be reversed on any terms.

Three lenses. The commons produces a complex answer about what you are creating and who will maintain it. Base rates produce a cycle answer about how often this achieves the specific thing you want. Options produce a random answer about the irreversibility, which is the part discussed least and matters most. The order is deliberate: the third should be settled before the first two are interesting.

Start with the property that separates this from other product decisions. Code released under an open licence cannot be recalled. Anyone who has a copy keeps their rights to that version under that licence, and a fork can continue without you indefinitely.

You can change the licence on future versions, and companies do. What you cannot do is undo the release, and the attempt is itself costly: a licence change is read as a betrayal by exactly the developers the release was meant to attract, and the fork that follows competes with you using code you wrote.

Where a commitment is expensive to reverse and the uncertainty about its value is high, the flexibility you give up is the main cost of acting now, and both conditions hold here at their maximum.1 That does not argue against publishing. It argues for deciding at a moment when you understand what you are giving away, rather than in the quarter when adoption is flat and this feels like a lever.

Every other growth experiment can be stopped. This one only continues.

Because the cost of acting now is the flexibility you give up, the question that resolves it is what you will know in six months that you do not know today. If the answer is nothing, waiting buys nothing and you should publish. If the answer is which goal actually matters, or whether the interface has stopped changing, then waiting is worth something specific and you can name the date it resolves. An irreversible decision deserves a stated resolution date rather than a quarter of drift.

There is a cheaper version that keeps the option open. Publish the documentation, the interface specification and a stable public API, and do not publish the implementation. Most of what a developer needs in order to build against you is there, adoption can begin, and you have granted nothing you cannot withdraw. If demand appears and the interface holds still for two quarters, publish the code then, knowing what you are buying. If demand does not appear, you have learned the same thing at no permanent cost.

The practical consequence is a scoping instruction. Publish the narrowest component that achieves the stated goal, not the most impressive one. An SDK and a client library are almost always sufficient for adoption arguments. The engine is what people reach for when the goal has quietly become attention rather than distribution, and it is the part you cannot take back.

The second lens is about what happens after the announcement, which is the part the proposal usually treats as automatic.

A published repository is a shared resource. People draw on it, and their drawing is not free to you: issues, questions, security reports, pull requests that need review, and expectations about response times that nobody agreed to. Shared resources do not maintain themselves through goodwill; the ones that persist have boundaries, rules matched to their situation, monitoring by the users themselves, and cheap ways to resolve disputes.2

Which means the real question is not whether to publish but who owns the queue. If the answer is whoever has time, the answer is nobody, and the repository will be visibly stale within two quarters. A stale public repository is worse than no repository, because it is a checkable claim about how you maintain things, and prospects do check.

The governance decisions are small and should be made before the release rather than discovered. Who triages issues and on what day. What your stated response time is, published, so that expectations are set rather than inferred. Whether you accept pull requests at all, which is a legitimate no and much better said than implied. What is explicitly out of scope.

One class of issue arrives on a clock you do not control, and small teams rarely plan for it. A public repository attracts security researchers, and a researcher who finds a vulnerability normally works to a disclosure deadline: they report it, then publish on a fixed date whether or not you replied. Your silence does not pause the clock. So the release needs a published security contact, an inbox somebody actually reads, and a named person who can ship a patch outside the normal cycle. All three cost nothing to set up in advance and cannot be assembled in the week you need them.

Be careful with the published response time, because it is a promise and breaking it is worse than never making it. A stated two-day triage that runs to three weeks is a visible broken commitment, sitting in an issue tracker where a prospect’s engineer can read it before a procurement call. Publish the number you can meet in your worst month rather than the one you would like to meet. A long honest number costs you nothing and a short aspirational one is a liability that accrues in public.

And the expectation to correct in advance: contribution is heavily concentrated. In most open projects a very small number of people produce the overwhelming majority of the work, and the maintainer is usually the largest of them.3 The community that shows up will be smaller and less self-sustaining than the proposal assumes, and planning for three occasional contributors rather than a movement is not pessimism, it is the ordinary case.

The third lens is the one that decides it, and it requires you to name the goal first, which is where most of these discussions fail.

Open sourcing is proposed for several different goals that get blurred together: developer adoption leading to paid conversion, hiring signal, trust in a security-sensitive component, standardising an interface across a market, or reducing your own maintenance burden through contributions. Those have very different frequencies of success and the last one is close to a myth at small scale.

So write the single goal, then look up how often it happened.4 Not whether it can happen, which is a statement about possibility and carries no information, but how often. The evidence is available and specific: find five companies of roughly your size that open sourced a comparable component two or more years ago, and check what happened. Did paid revenue follow. Is the repository maintained. Did the contributor count exceed three.

Record the same four things for each company, because a consistent table answers questions an impression cannot. The date of the first public commit. The date of the most recent one. The number of people with more than five commits. And whether the company still sells the product that component belonged to. The last column is the one people leave out and it changes every reading, because a repository kept tidy by one maintainer looks alive and tells you nothing about whether publishing sold anything.

When you cannot find five comparable companies, that is the finding rather than an obstacle. It usually means the pattern is rare at your size, and rarity is the base rate you were looking for. Widen the sample by component type rather than by industry, since an SDK behaves like other SDKs whether the company sells logistics or payroll. If it is still empty after that, you are proposing something novel, and novel plus irreversible is the combination that earns the longest wait.

That exercise takes an afternoon and it usually reframes the decision, because the honest base rate for the trust and hiring goals is much better than the base rate for the maintenance and community goals, and companies routinely publish for the second pair while telling themselves a story about the first.

The reframing that does the most work is to stop asking whether open source is good and start asking which of the five goals you are buying, because they are not bought with the same act. Adoption wants a client library that is easy to start with. Trust wants the security-critical path visible. Hiring wants activity, which is the one that decays fastest and needs the most upkeep. Publishing for all five at once buys none of them and staffs a queue for all of them.

Where the goal is trust in a security-sensitive component, publishing is often clearly correct: the code becomes a checkable claim, and a checkable claim about security is worth more than any assertion you could make instead.

The commons argument and the option argument disagree about scope.

Governance says publish something small, because a narrow component generates a manageable queue and a wide one generates an obligation you cannot staff. The option argument says the value of the release rises with how useful the published part is, that a component nobody needs generates no adoption and therefore no return, and that a cautious release is the worst combination: irreversible, and too small to achieve anything.

The reconciliation is to scope by usefulness rather than by size, and they turn out to agree once you do. Publish the part that a developer needs in order to build something, which is usually an interface layer rather than an implementation, and keep the part that would be expensive to maintain in public. That is both narrow and useful, and the reason it is not the default is that it is less impressive to announce than the engine.

None of the three prices what publishing does to your own team’s behaviour. Code written in public is written differently: more carefully, more slowly, with more attention to interfaces. That is usually an improvement and it is always a cost, and neither half appears in the proposal.

None of them handles the competitor who uses it. All three treat the published component as something you give to users. A competitor can adopt it, build on it, and in a market where you compete on integration breadth rather than on that component, they may benefit more than you do.

None of them handles the component that becomes a dependency for your own customers. Once a buyer builds against the published version, your ability to change it is constrained by their upgrade schedule rather than by your roadmap, which is a governance obligation acquired without a contract.

And one property the ensemble will not produce: a licence is a legal instrument with consequences that vary by jurisdiction and by how your customers’ own compliance teams read it. A permissive licence and a copyleft one produce entirely different commercial situations, and no amount of strategic reasoning substitutes for someone reading the actual terms against your actual contracts before the repository goes public.

The one action that survives the ignorance: write the single goal in one sentence, then find five comparable companies who published two years ago and check whether that goal was met. If you cannot state one goal, the proposal is about attention, and attention is the one motivation that does not justify an irreversible act.

The founder, because engineering will argue for it on craft grounds and marketing on attention grounds, and neither owns the maintenance queue that results. The instinct is to treat the release as the decision and the upkeep as an operational detail,