Fixed, thanks for the heads up (there was an inopportune line break).
How would this project approach FOSS projects that were abandoned, then sort-of-picked-up by another maintainer, but with no actual continued development?
The idea is that Code Shelter increases the bus factor, ie if the developer (or developers) of a project all drop off, there's a way for people to continue the project through Code Shelter.
What will usually happen is that a CS member will be interested in a project and notice that it's unmaintained. If the project is already in CS, they can just start maintaining it, or ask the maintainer to add it to CS. Since maintainers are volunteers, there's no guarantee that someone will take the project up, but the aim is to have a large enough pool of both maintainers and projects that matching is frequent.
Just to mention a tiny bit of friction that I find, that you're probably already aware of...
I would totally apply to do this but my OSS contributions are pretty sparse and go back a couple of jobs. I'm sure that I have the requisite experience but my GitHub profile for the last year and change is pretty empty. The application process totally discourages me from applying.
Yes, that's one thing that's currently a pain. How do you judge if someone is a good fit to take over (or, even harder, co-maintain) someone else's project just by looking at their Github profile?
Currently it's based a lot of "is this person already a maintainer of widely-used OSS libraries", as this is both a good signal and (hopefully) effectively foils malicious people, since, if you wanted to deploy some malicious code, you'd probably do it on the libraries you already have.
If you have any better ideas for how to "interview" maintainers, please let me know!
My expectation is that someone who is willing to attach their real name to something isn't willing to jeopardize their reputation and career over doing something malicious to a project.
Identity verification, similar to what Keybase supports, where people add a verification code to their social platforms might work here. Enough to verify to a certain degree whether someone is who they say they are. Maybe add a call to their employer to verify that they hold the role that they say they do also.
Hopefully that would solve that issue, but there's also the matter of someone being senior enough to be able to understand the direction of a project, set it, etc. Basically, you need to be able to trust every single one of the maintainers to have commit access on your project, with everything that entails.
For completely abandoned projects, it may not matter as much, but for projects that just need more eyes/hands, it's a larger consideration.
For completely abandoned projects, it may not matter as much, but for projects that just need more eyes/hands, it's a larger consideration.
Maybe add an agreement that if the community calls for a changing of the guard at some point that pending a review the maintainer will step down if the review process agrees.
I know HN is not terribly fond of crypto, but I think KYDcoin is a project that tackles this very usecase (specifically for crypto devs): https://review.kydcoin.io/
They review dev teams and attest they have seen personal information that matches the persons while the developers still can keep pseudonymous nicknames.
Who reviews the contributions? It's a good idea when the project has other maintainers, but when the new person is the only one, that can't really work...
i mean adding a person to the maintainer community. the review can be spread over current members of the community. 5-10 current members review 1-2 patches each from a candidate, regardless of which project the candidate contributes to.
even if you limit that extra work on repos you personally don't care about to once a month you can help one person to join the community per year, which is enough for the membership in the community to double each year.
That would be good, although it would require maintainers to become familiar with repos they might not be, just to review the user's contributions. It's a very good idea, though, since the contributions can just be regular PRs.
I just noticed that CodeShelter webpage is using .co domain name. My problem with that is that it's so often mistaken for .com that virtually any other tld is better.
there is a vast number of top level domains now available. i'd choose a memorable one from there.
.com doesn't actually strike me as the best choice since it used to mean commercial businesses. .co sounds better at least since it matches the first letters of code
.space .info .online .world .care .directory .community (i love that one) .support (also great) .help .cloud .network .codes (maybe shelter.codes :-) .software (shelter.software?)
just some ideas.
there is also codeshelter.fail, but i think it was established that negative connotations are a bad idea :-)
Comments
Fixed, thanks for the heads up (there was an inopportune line break).
The idea is that Code Shelter increases the bus factor, ie if the developer (or developers) of a project all drop off, there's a way for people to continue the project through Code Shelter.
What will usually happen is that a CS member will be interested in a project and notice that it's unmaintained. If the project is already in CS, they can just start maintaining it, or ask the maintainer to add it to CS. Since maintainers are volunteers, there's no guarantee that someone will take the project up, but the aim is to have a large enough pool of both maintainers and projects that matching is frequent.
Just to mention a tiny bit of friction that I find, that you're probably already aware of...
I would totally apply to do this but my OSS contributions are pretty sparse and go back a couple of jobs. I'm sure that I have the requisite experience but my GitHub profile for the last year and change is pretty empty. The application process totally discourages me from applying.
Yes, that's one thing that's currently a pain. How do you judge if someone is a good fit to take over (or, even harder, co-maintain) someone else's project just by looking at their Github profile?
Currently it's based a lot of "is this person already a maintainer of widely-used OSS libraries", as this is both a good signal and (hopefully) effectively foils malicious people, since, if you wanted to deploy some malicious code, you'd probably do it on the libraries you already have.
If you have any better ideas for how to "interview" maintainers, please let me know!
My expectation is that someone who is willing to attach their real name to something isn't willing to jeopardize their reputation and career over doing something malicious to a project.
Identity verification, similar to what Keybase supports, where people add a verification code to their social platforms might work here. Enough to verify to a certain degree whether someone is who they say they are. Maybe add a call to their employer to verify that they hold the role that they say they do also.
To me that would be enough skin in the game.
Hopefully that would solve that issue, but there's also the matter of someone being senior enough to be able to understand the direction of a project, set it, etc. Basically, you need to be able to trust every single one of the maintainers to have commit access on your project, with everything that entails.
For completely abandoned projects, it may not matter as much, but for projects that just need more eyes/hands, it's a larger consideration.
Maybe add an agreement that if the community calls for a changing of the guard at some point that pending a review the maintainer will step down if the review process agrees.
I know HN is not terribly fond of crypto, but I think KYDcoin is a project that tackles this very usecase (specifically for crypto devs): https://review.kydcoin.io/
They review dev teams and attest they have seen personal information that matches the persons while the developers still can keep pseudonymous nicknames.
Maybe an inspiration?
how about a probation period? in that time, contributions are more actively reviewed than usual.
eg 3 months or 10 patches (whichever takes longer)
only after that they become a trusted member.
it's like joining any other project. new members need to show their will to contribute, and that doesn't necessarily relate to past contributions.
Who reviews the contributions? It's a good idea when the project has other maintainers, but when the new person is the only one, that can't really work...
i mean adding a person to the maintainer community. the review can be spread over current members of the community. 5-10 current members review 1-2 patches each from a candidate, regardless of which project the candidate contributes to.
even if you limit that extra work on repos you personally don't care about to once a month you can help one person to join the community per year, which is enough for the membership in the community to double each year.
That would be good, although it would require maintainers to become familiar with repos they might not be, just to review the user's contributions. It's a very good idea, though, since the contributions can just be regular PRs.
I just noticed that CodeShelter webpage is using .co domain name. My problem with that is that it's so often mistaken for .com that virtually any other tld is better.
Hmm, I chose it specifically because it looks like Com, but the latter was unavailable. I'll see if I get another one as a backup, thank you.
there is a vast number of top level domains now available. i'd choose a memorable one from there.
.com doesn't actually strike me as the best choice since it used to mean commercial businesses. .co sounds better at least since it matches the first letters of code
.space .info .online .world .care .directory .community (i love that one) .support (also great) .help .cloud .network .codes (maybe shelter.codes :-) .software (shelter.software?)
just some ideas.
there is also codeshelter.fail, but i think it was established that negative connotations are a bad idea :-)