I think the funniest misconception about open source at larger scales is that it's a "do-ocracy".

[dotstdy@mastodon.social]

I think the funniest misconception about open source at larger scales is that it's a "do-ocracy". It's very much exactly the same as when big companies say they're "meritocracy" - weird marketing fluff that's entirely divorced from reality.

Turns out, unsurprisingly, that in order to actually do stuff in open source you need buy-in from the people maintaining the thing you want to do stuff with. Just doing it doesn't mean anybody will merge your code, in fact it means it's probable they won't.

[chrisdenton@hachyderm.io]

@dotstdy I feel this is both true and false. Yes if you turn up unannounced and dump a lot of code or big changes on maintainers you're unlikely to get anywhere unless one or more of the maintainers just so happens to already be enthusiastic for it.

And maintainers absolutely will have strong opinions on at least some areas of their project (either individually or collectively) so poking at those areas will require convincing as well as doing.

But on the other hand OSS (in my experience) is reliant on people showing up and doing. Things literally don't get done otherwise because the maintainers simply don't have the time or even are borderline burnt out. So it is possible to steer projects, to a degree, by doing (or selectively not doing).

Heck, showing up and doing is often how maintainers are made (and often how they burn out).

[dotstdy@mastodon.social]

@chrisdenton yeah for sure. I'm just saying that "sign up a good portion of your life to maintaining something in order to gain the political capital to force through a change you want" isn't what I'd call a "do-ocracy", especially since people tend to throw around those terms in contexts where there's significant friction with maintainers. As problems tend towards the trivial, or the uncontroversially good, then just doing something works.

[oblomov@sociale.network]

@chrisdenton @dotstdy showing up and doing is a necessary but not sufficient condition. If the maintainer has a very different idea about what the software could or should do, you're simply out of luck. Now, if it's end-user software, you can probably work around that with a more or less soft or hard fork, but when it's intermediate libraries, it generally just becomes wasted effort.