In the Free Software movement the typical response to these kinds of demands is pretty simple, “There’s the code, please do feel free to go fix it!”
Likewise in the hippy anarchist movements if you suggest something like a rally or a sit-in the usual answer is “Sounds good, when are you going to organise it?”
Which I tend to think is pretty much the right answer. If someone can’t be bothered to do the things they suggest themselves then I can’t really understand why they think they should be able to convince others to do it for them.
The key is to make the cost for getting in there and starting to do those things really low, making the source available to everyone with a simple download, making it simple to contact the whole group and start organizing.
Personally I’ve helped with and joined loads of differentcultsandprojects, even started one, and found that the key to getting me to do stuff to help at least is to make it both simple to do and obvious how, to ensure that I realize I don’t need permission to go do something.
You’ve said yourself that you were surprised how much of a barrier even having to send an email to OB was compared to having a big “submit your article here” button on Lesswrong,
I have vague plans to take a look at the source code for less-wrong and fix a couple of things that are annoying me, but it won’t be till after the Subgenius show I’m organizing at least, when I have a bit more time.
In the Free Software movement the typical response to these kinds of demands is pretty simple, “There’s the code, please do feel free to go fix it!”
One could argue that a large portion of the success of free software is because the ability to fork means that it is less damaged by internal dispute than other collective efforts.
The ability to fork means that internal disputes tend to cut the number of people working on it in half. Sure there’s two projects now, but that is not twice as good as one project.
In practice, one fork gets an advantage, more people switch over to work on it, and that form decisively wins with almost all the original contributors. Just like Bitcoin.
In the Free Software movement the typical response to these kinds of demands is pretty simple, “There’s the code, please do feel free to go fix it!”
Except in those situations where the response is, “I know you fixed a critical bug, but I’ve simply reverted all of your edits because you used the wrong indent style”
Given that the only indenting style 99%+ of programmers agree on is “the same style that the rest of the project uses”, failing to adhere to the style used is a fairly egregious faux pas and possibly indicative of a disregard for standards and/or lack of attention to context within the program, raising red flags about possible bugs introduced by the patch.
In any case, the correct response would be to reformat your code (any sane code editor can do this with one command) and resubmit the patch.
The point is not that free software programmers specifically refuse to accept wrongly indented code, the point is that they often refuse to accept code based on wholly arbitrary reasons. Arguing that indentation really isn’t an arbitrary reason is fighting the hypothetical; replace it in your mind with something that is.
There’s also the “we won’t accept this bug report unless it fits this list of arbitrary requirements” gambit (if you actually do manage to submit the bug report following all the requirements, it will still get ignored anyway, but doing it this way they can artificially deflate the number of unfixed bugs and blame things on the user for not following the directions)
In the Free Software movement the typical response to these kinds of demands is pretty simple, “There’s the code, please do feel free to go fix it!”
Likewise in the hippy anarchist movements if you suggest something like a rally or a sit-in the usual answer is “Sounds good, when are you going to organise it?”
Which I tend to think is pretty much the right answer. If someone can’t be bothered to do the things they suggest themselves then I can’t really understand why they think they should be able to convince others to do it for them.
The key is to make the cost for getting in there and starting to do those things really low, making the source available to everyone with a simple download, making it simple to contact the whole group and start organizing.
Personally I’ve helped with and joined loads of different cults and projects, even started one, and found that the key to getting me to do stuff to help at least is to make it both simple to do and obvious how, to ensure that I realize I don’t need permission to go do something.
You’ve said yourself that you were surprised how much of a barrier even having to send an email to OB was compared to having a big “submit your article here” button on Lesswrong,
I have vague plans to take a look at the source code for less-wrong and fix a couple of things that are annoying me, but it won’t be till after the Subgenius show I’m organizing at least, when I have a bit more time.
One could argue that a large portion of the success of free software is because the ability to fork means that it is less damaged by internal dispute than other collective efforts.
The ability to fork means that internal disputes tend to cut the number of people working on it in half. Sure there’s two projects now, but that is not twice as good as one project.
In practice, one fork gets an advantage, more people switch over to work on it, and that form decisively wins with almost all the original contributors. Just like Bitcoin.
Except in those situations where the response is, “I know you fixed a critical bug, but I’ve simply reverted all of your edits because you used the wrong indent style”
Given that the only indenting style 99%+ of programmers agree on is “the same style that the rest of the project uses”, failing to adhere to the style used is a fairly egregious faux pas and possibly indicative of a disregard for standards and/or lack of attention to context within the program, raising red flags about possible bugs introduced by the patch.
In any case, the correct response would be to reformat your code (any sane code editor can do this with one command) and resubmit the patch.
The point is not that free software programmers specifically refuse to accept wrongly indented code, the point is that they often refuse to accept code based on wholly arbitrary reasons. Arguing that indentation really isn’t an arbitrary reason is fighting the hypothetical; replace it in your mind with something that is.
There’s also the “we won’t accept this bug report unless it fits this list of arbitrary requirements” gambit (if you actually do manage to submit the bug report following all the requirements, it will still get ignored anyway, but doing it this way they can artificially deflate the number of unfixed bugs and blame things on the user for not following the directions)