You get this slush pile of unsolicited contributions, whether you're a book
publisher or an open source software publisher.

What you're doing is
you're reading through the slush pile, selecting a very small subset of it and
telling the rest to go away, polishing _if_ you have time, but as
these projects mature a good maintainer whose attracted a lot of contributions
whose project has scaled up to something big and complicated will have less
and less time to do programming. I mean Linus Torvalds drinking from
the firehose, there have been three seprate occasions he's had to reorganize his project
to scale better, we'll get into those.

But you polish it if you have time, or you bounce it back with comments.
You then stitch together these selections into something vaguely coherent,
rinse repeat. Release early, release often.

And that's the central model of open source development is a publishing
model. Fighting off sturgeon's law. Now if you look at the maintainer,
getting back to the hobbyist context, it's all volunteers,
the maintainer has veto power only. he's not paying any of these guys.
he can't go out and solicit contributions, he can't sponsor contributions
becaue he can't hire people to write stuff. Companies sometimes can but
because the companies that can afford to do this are large bureaucratic
conglomerates mostly, they don't interface well with the mindset because
bureaucrats and hobbyists don't mix almost never see eye to eye. One of
the big tools the maintainer has is using their veto power to do bounceback
negotiation. You sent me a patch. You would like this patch integrated.
I conditionally reject the patch, but I provide feedback saying "if you
modify it to do X, Y, and Z, then I'll take it". And one of the things
whether you're trying to write the great american novel, whether you're writing science fiction or you're writing software, a personalized rejection letter
is a good thing. If you get a form rejection letter or no response at all,
that's not a good thing. But if the editor took time to tell you why they're
rejecting you, the only reason to do that is because they want to hear
more from you in the future, and they believe this feedback can help you
provide things that they would be able to accept. If they don't think
you're capable of producing that they would be able to accept, they don't
bother giving you personalized feedback. So a personalized rejection letter
is a good sign.

So with a guided veto what a maintainer is doing is saying here's what I
would accept, and hoping thet their desire to get the patch in is enough
to make them do the extra work, and there's negotiation that goes back and
forth. if the maintainer pushes too hard, the patch submitter will just
go "ok, I'll live with not having the patch in, or I'll maintain it out
of tree". And if they don't push hard enough they don't get what they
want.

Another thing the maintainer does is act as the architect setting direction
for the project. Even when they stop writing any code whatsoever; Linus
Torvalds almost never writes any code anymore because he just doesn't
have any time. he occasionally does some to keep his hand in, but what he's
doing by saying what patches he'll accept what patches he won't accept,
it's not just a matter of quality, it's a question of saying this should
not be our job. This feature is beyond the scope of this project. That's
not a direction I want to go in, so that we don't become mozilla. One of the
reasons I harp on mozilla is its source code is bigger than the linux kernel source
code. That's kind of a bad sign.

So they say what the project does not do. It's part of "a maintainer's job is
to say no", they set the boundaries for the project.

Now leading vs coordinating is one of the things that a project maintainer...
as a project scales up, the project maintainer in part is figuring
out "this is is where I want to take the project", but they do more of
that early on when they're the ones writing the code. Later on, they've got
twelve different people each interested in doing their own things with
the project, and they're trying to coordinate it and produce some kind of
unified vision, out of what the other people want to do. So they have to
balance having a vision of what the project should do with listening to
other people's vision of what the project should do. And that's _hard_.

I mean there's some want vs need things in there, the reason I mention
ownership vs attribution is this is actually one of the big things that
hobbyists sort of understand instinctively but can't always articulate and
big business just completely misses a lot: hobbyists tend not to care
that much about ownership. It's open source, nobody owns it. But we care
very deeply about attribution. This code was written by X. X deserves _credit_
for this code. In academia the whole publish or perish thing: you want to
get it out there, you want everyone to use your idea, and you want
everyone to know that you had that idea. You want attribution.

Source of authority we went into a little bit earlier.

Reputation as currency.

6 minutes