A useful open-source tool still needs a path from public repo to working environment. That path is product work, not an afterthought.
Most technical builders understand the code. Most buyers or users experience the surface around the code: install instructions, examples, screenshots, error handling, docs, demos, support boundaries, and the first successful run.
When that surface is weak, the tool may be real and still feel unusable.
The implementation surface has jobs
- Explain the outcome in one sentence.
- Show what the tool needs before it runs.
- Give a smallest useful example.
- Prove that the example worked.
- Name what the tool does not do yet.
- Offer a paid path when someone wants the result without doing every setup step alone.
Kyanite's own site follows that pattern: public repos, products, blog posts, /llms.txt, /ai-sitemap.json, implementation intake, and a clear boundary between Kyanite tool implementation and broader PuenteWorks consulting.
Open source does not remove service work
Open source can reduce lock-in and prove capability. It does not automatically handle installation, adaptation, team training, environment differences, docs, examples, or maintenance decisions.
The repo proves the tool exists. Implementation help gets the tool into working hands.
Why this is a real offer
Implementation help is sellable when the public tool is specific enough to trust and the setup path is painful enough that a serious user would rather buy help than burn a weekend. That is the lane for Kyanite: practical tools, public proof, and scoped help getting the result working.