After finishing the 1st draft of the manifesto¹ with @GeorgLink I decided to start cranking on sustain.md. Right now it’s just a skeleton and I guess I am looking for comments/suggestions, etc.
Grand vision would be if a maintainer got severely hurt, sick, or died; GitHub, npm, (or whatever platform) would be able to grant access to a trusted person² who is capable of keeping things afloat until someone else (or company/org) can completely take over.
Security.txt has an RFC, not sure if that would be necessary, although I always wanted to help write an RFC. ¯\_(ツ)_/¯
So I ask you, fellow sustainers, is this a road worth going down?
¹ not sure if that is the name we are keeping yet
² not everyone has a GitHub or npm account, I know hard to believe but it’s true.
I like the idea of standardizing how a community can make itself more sustainable.
A sustain.md file can be one standardized component. Yes, an RFC for that would be great because it invites a grand discussion, spreads the idea, invites much needed feedback, and helps revise and refine the standard.
On a larger picture, the sustain.md is only one best practices. It lacks a larger incentive system and there are other best practices. To separate the discussion around best practices, I started a thread on the idea of a Sustainable Best Practices Badge and wrote a blog post about it.
Where is funding coming from and how can one donate.
Second, what other information should a project provide in sustain.md to convince anyone that it is sustainable. (maybe not all of it belongs in the sustain.md but rather a badge)? Every idea that I come up with, I dismiss because there is a different place for this information. E.g. Code of Conduct best lives in its separate CODE_OF_CONDUCT.md file; What issue tracker to use lives in CONTRIBUTING.md; how to report software vulnerabilities lives in SECURITY.txt. …
Bringing these two thoughts together: Does it make sense to introduce yet another file or should we promote inclusion of our desired information within existing files?
Who the maintainers are would well fit within the README or CONTRIBUTING, same with how to contribute financially.
I can sympathize that, I personally like to keep as much out of the root directory as possible. With that said, I also believe int he Unix philosophy, and appending this information to another doc does it a disservice. Case in point, look at the webpack README. It’s huge! If they adopted sustain.md and put it at the bottom of their README then how many people would miss it?
I recognize the benefits of the UNIX philosophy.
The discoverability of the information is a major concern that we indeed fix with a separate file. It would also be easier to automatically identify whether a project is providing the information (does file exist?).
On the subject of funding. Rather than just the source of funding, maybe refer in the same breath where to find financial information. Listing sources doesn’t make it sustainable if it boils down to 0.1% of minimum wage being donated.
Also, I think any properties that make sense to list in such a sustain.md file may be issues to look at tooling and or communities that can help here. For example, what can you do when your small open source project takes off? Could there be escrow tools for sharing deployment keys?
A simple learn more link might help when trying to to spread this practice.
