Scott and I were discussing a methodology for use in open source development, and I mentioned that there are some projects that someone posted online as an open source contribution where they’re not looking for input. I have some of these — if someone finds a bug in the code I wrote to gather MS Teams usage stats, I appreciate their help. If they want to change the report format, or what’s being reported, or … well, it’s a script I wrote and use for a specific purpose, and that’s what it does. Feel free to make a fork and adjust the report to suit your needs. But I’m not going to merge a PR in that keeps five years worth of data because I don’t want five years worth of data. And that’s a perfectly valid decision for code I built that I shared in case it helps someone else who needs to achieve a similar goal. I call this a dictatorial project — there’s an individual that makes the decisions. If you want to change something about how the program works, you should run it by the dictator prior to putting a lot of effort into it. Or plan on making changes in your own fork.

There are oligarchic projects — those may be corporate sponsored projects or projects owned by a group of private individuals. As with dictatorial projects, there are a small number of people “in charge” who decide if PRs are merged or not.

And there are democratic projects — at least in theory. I don’t know if this ends up being true in practice anywhere. But, in theory, a large community of developers or users would drive the direction of the project.

I suppose, if I’m discussing theoretical repository management types … I could add in mass chaos. Open for anyone to merge changes. This is an approach that’s worked surprisingly well for Wikipedia, so I suppose it could work for a smaller code base. Someone merges in some malicious or flawed code, someone else puts in a fix.