3 ms·

Systems code is extremely prone to slowing down into a "legacy" maintenance project because it's at the base of what software does - not the future itself, but

Systems code is extremely prone to slowing down into a "legacy" maintenance project because it's at the base of what software does - not the future itself, but a vehicle to arrive in the future with. To make a vehicle that can arrive, you also have to live with a past decision about how it's designed, or else you've already started over in trying to redesign it. I don't think Linux is unique in that, just uniquely visible: it's allowed the barriers to entry to steadily rise to favor corporate contributors instead of allowing a faster break to a streamlined mechanism. I hate it, but I don't see it as a project-specific issue, because big projects in open-source routinely develop an unwelcoming level of complexity, it's just a "pick your poison" kind of deal. Aiming for an intentionally small project is also hard, but for different reasons: you have to have a pretty good sense of your philosophy to not end up either being a useless toy that nobody uses as a serious vehicle or falling right back into mindless accumulation.

mschuster91 3y ago
The thing is, a lot of the barriers would be pretty easy to solve - especially, move from cgit and mailing lists to GitLab - hell even a self-hosted Community Edition instance would be enough. Having merge requests with detailed annotation threads instead of patch series on mailing lists is just so much a better experience for everyone, but it seems like many of the core contributors have so grown into their paths they literally cannot see the sunlight at the horizon any more.
- aragilar 3y ago
  But that wouldn't change needing to support an older gcc, nor change the "no breaking userspace" rule. CI won't run on every platform (nor all the different hardware that's out there). Random PRs will be just as ignored as random patches (probably more so if the idea is to increase the volume of contributions). A "build it and they will come" attitude only works if you're ready for the volume, if not (and based on the original discussion, the problem is lack of maintainer time), then it just adds more work.

mschuster91 3y ago

The thing is, a lot of the barriers would be pretty easy to solve - especially, move from cgit and mailing lists to GitLab - hell even a self-hosted Community Edition instance would be enough. Having merge requests with detailed annotation threads instead of patch series on mailing lists is just so much a better experience for everyone, but it seems like many of the core contributors have so grown into their paths they literally cannot see the sunlight at the horizon any more.

aragilar 3y ago
But that wouldn't change needing to support an older gcc, nor change the "no breaking userspace" rule. CI won't run on every platform (nor all the different hardware that's out there). Random PRs will be just as ignored as random patches (probably more so if the idea is to increase the volume of contributions). A "build it and they will come" attitude only works if you're ready for the volume, if not (and based on the original discussion, the problem is lack of maintainer time), then it just adds more work.