I agree that this passage says more about the author than about any fundamental law of organization.
It is true however that there is more organizational overhead if you have two people working on a thing than if you have one doing it solo.
But that is a problem that can be solved, e.g. by dividing responsibilities very clearly or by having clearly defined procedures that guarantee a decent handover. I have also experienced people that do better, more accurate and resonable work when they work together with someone else, because they will anticipate the other seeing their code.
The quoted passage tells me one thing: If you invite people to work on your project, no matter if it is a film, a garden party or a software product, the right casting is crucial. Don't invite people that won't understand the thing you're doing, and if you absolutely have to make sure there is something in it for them when they do their own job well and see your thing succeeding — but the crucial thing is, you should always know what is in it for the other person.
As someone who has been on a number of amateur film sets where nobody got paid the ones that really sucked where the ones where the initiator treated everybody like dumb paid labour that should just do as they were told, pushing people that might have cared into actively sabotaging the project.
If you want people to care about your project it is your task to find people who do and it is your task to keep them there, if they are needed for the project.
And very often that means not doing it 100% dictator-style, but letting people play and evolve within their own domain. From what I have seen the results of allowing this outshine micromanaging dictators nearly all of the times.
This hugely assumes that the point of an open source project is to have other people do it, and 'caring about it' means doing the work of it.
Not always true.
My own open source world operates on different principles: I'm there to explore in a particular direction, not always fruitfully. Near as I can tell there isn't anybody else walking that particular beat, which among other things implies that it's a really niche interest, and that suits me just fine.
But it means I can't get other devs in to pursue this direction, because they simply won't. So my use of open source turns into a one-way faucet: rarely is there a situation where I'm able to take anything back, it's always about facilitating other people to build THEIR projects making use of whatever they find useful in my codebase. I almost never get any help with my project, and this is fine.
Maybe it works better for everyone that I don't try to get people to do my will, don't treat them as dumb paid labor. People are often very clever but caught up in doing things I don't find at all useful, not unlike the author's objections as a 'helper' tries to convert his social-media-democratization project into a much more elaborate creation that fails all the author's requirements. This is where the other person would fork and be done with it: seems rude to try and shake the original dev from his fundamental motivations with the project.
Question. If the original person is so niche that they'll create something original but unhelpful to most people, and the interloper is far more in tune with popular demand and will create something that is meh but popular, is forking the project and making two projects, the niche one and the meh popular one, bad?
If this is done and it upsets the original dev, who sees his vision desecrated by a garbage knock-off, and he quits and goes and jumps off a cliff, is THAT bad?
The latter is an extreme, but I'm reminded of so many stories from history and media along these lines. The most popular comic strip in history is named 'Peanuts', and was always the work of one man, Charles Schulz. Everything about it was him on the page… except the name, which was forced on him by the syndicate, over his preferred Lil' Folks. Schulz never came to terms with the name Peanuts. He saw it as 'little worthless things, things of little value'. This of course echoed the neuroticism of his very intelligent and fretful characters, forever worrying about their own value, and so lampshading that in the title of the strip has probably helped its popularity, as it's a guide to the kind of humor within.
Let's postulate that Schulz was able to use Lil' Folks, or even 'these are awesome self-actualized people worthy of love and respect, just like me the cartoonist', and let's imagine that he could do this and totally nerf the adoption of the strip, allowing the cartoonist's needs to intrude on the art. Should he have? What's more important, his ownership of the project, or what it could become?
> This hugely assumes that the point of an open source project is to have other people do it, and 'caring about it' means doing the work of it.
>Not always true.
Thank you for saying this. The shift of this mindset in the open source community is part of why I stepped back a bit from the open source community. I still produce open source projects, but I no longer use the term "open source" because I don't accept changes from the larger community. I do my projects, release the source, and people can fork if they want to work on it.
I do this because once you start accepting work from others, you start having to be a manager. I don't want to be a manager.
It is true however that there is more organizational overhead if you have two people working on a thing than if you have one doing it solo.
But that is a problem that can be solved, e.g. by dividing responsibilities very clearly or by having clearly defined procedures that guarantee a decent handover. I have also experienced people that do better, more accurate and resonable work when they work together with someone else, because they will anticipate the other seeing their code.
The quoted passage tells me one thing: If you invite people to work on your project, no matter if it is a film, a garden party or a software product, the right casting is crucial. Don't invite people that won't understand the thing you're doing, and if you absolutely have to make sure there is something in it for them when they do their own job well and see your thing succeeding — but the crucial thing is, you should always know what is in it for the other person.
As someone who has been on a number of amateur film sets where nobody got paid the ones that really sucked where the ones where the initiator treated everybody like dumb paid labour that should just do as they were told, pushing people that might have cared into actively sabotaging the project.
If you want people to care about your project it is your task to find people who do and it is your task to keep them there, if they are needed for the project.
And very often that means not doing it 100% dictator-style, but letting people play and evolve within their own domain. From what I have seen the results of allowing this outshine micromanaging dictators nearly all of the times.