Open source makes continuation possible. A project can gain a new maintainer, a new direction or a second life when someone builds on its existing foundation. A fork is strongest when it makes that relationship clear.
The go-llama.cpp repository in our open-source work continues from go-skynet/go-llama.cpp. Its documentation names the original project, and its license retains attribution to the original authors. That history is part of the project’s identity and should remain easy to find.
Compatibility has several layers
A function can retain its name and still change its behavior. An import-path migration may compile while a default, resource requirement or deprecated option produces a different result at runtime.
That is why a useful migration guide goes beyond a replacement command. It describes changes that the compiler catches and those that require a person to inspect their application. It also explains what cannot be preserved and why.
For bindings around another library, there is a second compatibility boundary: the underlying engine. A stable wrapper signature does not guarantee identical output after an engine update. Applications may need to recheck their assumptions even when the source change is small.
Make evidence visible
Documentation should distinguish an API that exists, an example that compiles and behavior exercised in a real integration test. These are all useful, but they answer different questions.
The go-llama.cpp README uses this distinction in its capability table. Some behaviors have direct model-backed checks; others have narrower coverage. That gives a prospective user a more useful basis for evaluation than a blanket claim that everything is tested.
A maintainer can extend this practice to platform support, accelerator backends and model compatibility. “Expected to work” should remain visibly different from “checked in this configuration.”
Keep the path back understandable
A fork’s documentation should explain how to pin a version, report a problem and find the upstream relationship. Release notes should identify changes that require action. Where possible, include a small migration example that demonstrates the actual difference rather than only describing it.
None of this requires pretending a small project has unlimited maintenance capacity. Clear scope is more helpful than an expansive promise. Contributors and users can make better decisions when they understand which parts are supported and where further work is welcome.
Maintaining a fork means maintaining a relationship with the people who built the foundation and the people who depend on its continuation. Attribution, precise promises and honest evidence are everyday engineering work.