For everyone that calls for ways to make open source more secure, or for all their magical solutions that will provide money and resources to FOSS maintainers, please read this.
This is a rare account of the reality of maintainers, things that are hard, but also how much knowledge and niche expertise you need for anything in there.
That is why just giving money to experts will not help that much. It is too hard to train experts in this. But we may make it easier
@Di4na A very thoughtful piece, another factor I think that is often downplayed is the role of talent - the author of this piece is clearly very talented, but the number of people with enough talent in the world to work on highly complicated software like this is limited, so that adds YET ANOTHER filter on the number of people who can end up working on these things.
I think society as a whole tends to like to act as if anybody if they only want it hard enough could do these things whereas the reality is only a small fraction could.
@Di4na I agree with you but also, money buys time* and time is required to make new experts. One issue I see is getting non-experts funded so they can one day become experts
if the money allows maintainers to go from part time to work full time on the project.
@Paxxi I mean maybe, but the problem is that once you do the maths on how much money you need to get there, the sustainability become... Surprisingly hard.
@Di4na rethinking the structure might also make things easier. Instead of funding two+ maintainers for every project, a team of 5 could probably maintain many critical libraries that don't have a need for lots of new development
@Di4na but money would help with the training, though. if someone would be paid a full salary just to immerse themselves into the codebase of a project, that would motivate people more to be able to participate, wouldn't it?
Like, whatever your scheme is, it needs to take something like this into account
"There's one particular patch I remember committing - I won't mention which one - where I spent weeks and weeks of time reviewing the patch before committing it, and after committing it, I lost most of the next six to nine months fixing things I hadn't caught during review"
@Di4na scalability of reviewing is a real problem: I could probably go full time review code -but at the expense of my own work. But the barrier to giving people the commit bit is not just the ability the write great code -it’s to rigorously review other code and be ruthless about the quality of product and test code, even from colleagues
I’m pleased that none of my colleagues trust my code and treat it as a threat to the happiness their weeks being on call: ultimately they are correct.
Add comment