Skip to content

Latest commit

 

History

History
20 lines (10 loc) · 2.52 KB

history.md

File metadata and controls

20 lines (10 loc) · 2.52 KB

History

This organization was initially an experiment in code maintainance. Can decentralized people maintain packages over many years under a centralized GitHub organization? And can they do so without any funding for managerial overhead or for training and supporting new maintainers?

Lessons

The people who initiated this experiment ran into some rather predictable troubles and were not able to keep up with their initial vision. Over time it became clear that a more traditional approach (which has its own problems) would still work better overall. In the more traditional approach:

  1. Packages are created by independent authors under their own name, like alice/typed-svg or bob/easing-functions. Authors run projects however they want, and the packages succeed or fail based on all the factors that go into that. Code quality, API design, blogs, docs, conference talks, etc.

  2. If the needs of certain users do not match alice/typed-svg or bob/easing-functions, certain users can decide if it is worthwhile to make their own version and take on the full burden of development themselves. If it is not worthwhile to them, they will not do that. If it is worthwhile to them, they will do so under their own name and the package will succeed or fail on its own merits. Not by piggybacking on the reputation or usership of an existing package or organization.

This is a decentralized way for decentralized people to end up with the code they want. There is no central point to ask permission for anything. And there is no official sounding organization that (with prior versions of this repo) might dissuade potential new package authors from pursuing their vision of a particular package. If your needs do not match what is freely available online, the next steps to solving your own problem are fully in your own hands.

Current Usage

No new projects are added, and existing projects are maintained as they always have been.

So existing packages continue along as they are. If the existing maintainers take specific actions to fix bugs or add features, that is their perogative. If they want to add people to the repo, that is up to them. If someone with their own vision for one of these packages creates their own version, they should go for it and see how it goes. This way (1) there is no disruption in how any existing package works or will continue to work and (2) we will gradually switch back to a decentralized way of managing these projects to the extent that new packages provide practical benefits over existing ones.