내부 개발자 도구를 오픈소스화해야 할까요? 유지 보수 책임 가격 책정

The code already exists, so open-sourcing an internal tool can look almost free. Publishing is the cheap part. The liability begins when external users reasonably expect releases, answers, security handling, and migration guidance.

Before choosing a license or polishing the README, price twelve months of ownership.

The maintenance-liability worksheet

Obligation Monthly hours Named owner Service promise Exit cost issue triage response or no SLA dependency updates supported versions security reports private intake + acknowledgement release engineering cadence or best effort docs and examples tested versions community moderation conduct enforcement

Calculate a base case and a stress case:

annual liability =
  12 × monthly owner hours × loaded hourly cost
  + release infrastructure
  + legal/security review
  + expected incident cost
  + deprecation reserve

Enter fullscreen mode Exit fullscreen mode

The number will be imperfect. Its purpose is to reveal work that was previously assigned to “the community” without evidence that a community exists.

Four hard gates

Do not publish yet when:

1. no team owns vulnerability reports;
2. the repository still contains company-specific credentials, data, or assumptions;
3. the public API depends on an internal service you cannot support externally;
4. nobody has authority to deprecate or transfer the project.

Passing those gates does not require a large budget. It requires honest expectations. “Maintained when time permits” can be valid if the README, issue templates, and release behavior match it.

Measure the decision after launch

Track outcomes that justify maintenance:

• qualified external contributors;
• issues that improve the internal product;
• successful external installations on declared platforms;
• security reports handled within the stated process;
• recruiting, ecosystem, or adoption outcomes tied to evidence.

Stars can indicate attention, but they do not pay the maintenance bill by themselves.

Define the exit before the entrance

Write an archive rule now: for example, two quarters without an owner, unresolved critical dependencies, or strategic replacement by another project. Define the final release, read-only period, data export, successor link, and security-contact sunset.

The decision is not “Is open source good?” It is “Can we keep the promise this repository makes?” A modest project with a clear owner and a truthful support boundary is healthier than an ambitious launch whose maintenance was never put on anyone’s roadmap.