?Solo OSS founder with SOTA results — is there any meaningful IP protection left when LLMs can re-derive your algorithm from a partial README?

On an HN OSS license discussion, commenter bunderbunder framed the realistic fork economics: “keeping your own private fork of a GPL library isn’t all that easy an option if you also expect to be able to benefit from any further work done by the project’s maintainers. By going that route you’re committing to spending a lot of time and money on a lot of hairy merging.” Applied to the OP’s case (single-author OSS hitting SOTA, worried about LLM-derived re-implementations): the algorithm itself isn’t defensible from LLM extraction. But the active maintainer position is — anyone who forks and ships a closed version now owns the merge cost forever while the original keeps moving. AGPL specifically raises that cost further by forcing re-implementers to also open-source derivatives, which most VC-funded teams will not accept.

On an HN OSS maintenance thread, commenter apollyx_jojo described a pattern that kills smaller open source projects: One pattern I’ve seen kill smaller open source projects that isn’t mentioned: scope creep driven by the most vocal users. A focused tool that does one thing well starts getting PRs and issues for tangential features. The maintainer, wanting to be responsive, merges them. Six months later the project is a Swiss army knife that’s hard to maintain, hard to onboard new contributors to, and the original use case is buried under complexity.” Applied to defending a SOTA algorithm: the most defensible OSS project isn’t the one with the cleverest core — it’s the one that stays small, focused, identifiable. Scope creep dilutes the “what is this project question; re-implementers can copy a tightly-scoped algorithm but cannot easily decide which features to inherit if the original drifts into kitchen-sink territory.

A pattern recurring across HN OSS discussions (bunderbunder on fork-merge cost, apollyx_jojo on scope discipline, plus many shorter threads): the algorithm is rarely the durable moat for a solo project — the “long tail of edge-case fixes discovered through real user contact” is. The reasoning that consistently appears: re-implementers (closed-source forks, VC-funded clones) typically get the core algorithm right within weeks, but cannot match the pace of edge-case discovery that comes from being the active project with active issue traffic. As long as the maintainer ships weekly fixes faster than re-implementers can extract + re-derive + integrate, the gap stays open. This is fragile — burnout, day-job, distraction collapses it — but it’s the realistic moat for a solo SOTA project in the LLM era. License (AGPL) raises fork cost; scope discipline keeps the moving target small enough to defend.