Many of the techniques that make you faster as an individual will make you slower as a team.
This is not only a post about LLMs, even if they’re the most obvious example.
0 Boosts
0 Likes
I can only think of three kinds of OSS working styles:
- early days, 1 or 2 maintainers, not much usage
- long-lived, slow, 1 maintainer always at risk of burnout or worse
- long-lived, many people, moving sustainably, not rushing
For example, nixpkgs moves slowly. Even security patches are best-effort, though typically they get merged quickly.
People want Nix and nixpkgs to go faster, and stabilise all the features quickly. The reality is that the process to stabilise a feature (e.g. flakes, or dynamic derivations) is slow for a reason: so everyone is brought along.
There are forks of Nix that have stabilised features. They do this by explicitly dropping maintainership; they revert to a small in-group, and never open up again. They move from model 3 to model 2.
There is nothing wrong with this, but we must not pretend there is no downside.
For open-source software, if you are maintaining a successful project, moving fast and expecting others to keep up… you won’t be successful for long.