4 ms·

It used to be you could email a patch to someone and that patch would get reviewed and committed. Since then there has sprung up a fetish for bureaucratic proc

It used to be you could email a patch to someone and that patch would get reviewed and committed. Since then there has sprung up a fetish for bureaucratic process, and tooling has arisen to foster that, such that the barrier to entry is significantly higher now than it was in the 90s. All you needed was a text editor and an email account. Now you need accounts on whatever code forge is involved, and you didn't write enough unit tests, and you failed to properly format your pull request, and what do you mean you're not an expert in whatever version control we've adopted? This pull request sat in an open state because you didn't tag it appropriately. The CI system was updated and your code wasn't covered in the automated integration test, please resubmit after making minor punctuation changes in a metadata file. Over time, this stuff filters out contributors and leaves a core of people who are comfortable with the structure of the engineering process for that specific project. It's not a bad thing that engineering standards are higher, but it's no longer a world of people 'scratching an itch' -- there's yak shaving to be done, and the number of people willing to shave that yak has always been smaller than the number of people who are not. I don't think the author is right about things having been harder in the old days led to a higher proportion of the internet being qualified to contribute. I think it's much harder now to patch software upstream than it ever has been.

nerdponx 6y ago
In my experience, bureaucracy is mostly uncorrelated with the willingness of a project to accept a PR from a new contributor. Homebrew has very strict contribution requirements but has a huge number of contributors and is generally easy to contribute to. Meanwhile there are lots of little projects that go dead for lack of interest by the sole maintainer in reviewing and merging patches. Also this: Since then there has sprung up a fetish for bureaucratic process, and tooling has arisen to foster that, such that the barrier to entry is significantly higher now than it was in the 90s. All you needed was a text editor and an email account. Now you need accounts on whatever code forge is involved, and you didn't write enough unit tests, and you failed to properly format your pull request, and what do you mean you're not an expert in whatever version control we've adopted? This pull request sat in an open state because you didn't tag it appropriately. The CI system was updated and your code wasn't covered in the automated integration test, please resubmit after making minor punctuation changes in a metadata file. Doesn't really make sense to me. How many projects have you actually had this problem with? I don't think the author is right about things having been harder in the old days led to a higher proportion of the internet being qualified to contribute. I think it's much harder now to patch software upstream than it ever has been. For some people, using Git and Github is a barrier to entry. For others, submitting a patch to a mailing list is a barrier to entry.
- musicale 6y ago
  > dead for lack of interest by the sole maintainer in reviewing and merging patches I think you mean "lack of action" rather than "lack of interest." It's easy to be enthusiastic about developers doing lots of work for you (usually for free) and to cast them as "uninterested" if they don't comply quickly (or at all) with your requests. I suspect many maintainers are "interested" in reviewing and merging patches but are simply unable to perform large amounts of work without pay, due to time and financial constraints.
microtherion 6y ago
> It used to be you could email a patch to someone and that patch would get reviewed and committed. May I ask what communities you were involved in, and when? Even formatting patches so they could be reliably applied was a nontrivial matter. It was not uncommon for them to be applied manually (and sometimes faultily). Sometimes you would mail patches to maintainers directly, other times you would share them on mailing lists, where they would undergo a bit of "social review" (works for me!) and would or would not be applied. Some people just mailed entire modified files and expected maintainers to figure out the changes on their own. As for "committed", many maintainers may not even have used source code control (notably Linus didn't use any), and I can't recall a single project with publicly accessible repositories in the 1990s as opposed to tarball releases. > All you needed was a text editor and an email account. Now you need accounts on whatever code forge is involved [...] Getting an account on any of these code forges in 2020 is almost certainly much easier than getting an e-mail account at all in the early 1990s for many people. I don't agree with the author that contributing was easier in the 1990s. Generally, it involved a bit of a social process, trivial drive by fixes were not any more popular than today, there were coding standards to be observed (and not always written ones), in larger projects, you could expect to navigate some flame wars, and sometimes your contributions were rejected anyway because RMS decided to cancel your OS.
- tom_ 6y ago
  Very much mirrors my experience. Github provides a very useful project-independent unified UI for drive-by patches and off-the-cuff issues. No more mailing lists or bug trackers to sign up for and manage! And it's also even got an integrated version control system, that 99.9% of projects then use, and it's one that makes it easy to version control a fork of your own as you work on any patches you might be making. Progress!
  - Conan_Kudo 6y ago
    > Very much mirrors my experience. Github provides a very useful project-independent unified UI for drive-by patches and off-the-cuff issues. No more mailing lists or bug trackers to sign up for and manage! And no more need to become emotionally invested in the project, thus furthering its development into a proper community of users and contributors that propel it forward. :(
ekiwi 6y ago
> It used to be you could email a patch to someone and that patch would get reviewed and committed. Yes, but 1990 is also when this study came out: https://ftp.cs.wisc.edu/par-distr-sys/technical_papers/fuzz.pdf https://ftp.cs.wisc.edu/par-distr-sys/technical_papers/fuzz.... They find that a lot of UNIX tools could be easily crashed by generating random inputs. The quality of our most popular open source software has dramatically improved over the last 30 years.
- pjmlp 6y ago
  Check the updated version of that paper, it hardly changed in 30 years. https://www.researchgate.net/publication/348025458_The_Relevance_of_Classic_Fuzz_Testing_Have_We_Solved_This_One https://www.researchgate.net/publication/348025458_The_Relev...
throwaway2245 6y ago
You could re-frame 'bureaucratic process' as 'expectation setting'. It also benefits the contributor to know what is expected of them. If you know that your contribution will be properly considered when it meets the outlined expectation, then it is easier to put in the effort to contribute.

nerdponx 6y ago

In my experience, bureaucracy is mostly uncorrelated with the willingness of a project to accept a PR from a new contributor. Homebrew has very strict contribution requirements but has a huge number of contributors and is generally easy to contribute to. Meanwhile there are lots of little projects that go dead for lack of interest by the sole maintainer in reviewing and merging patches. Also this: Since then there has sprung up a fetish for bureaucratic process, and tooling has arisen to foster that, such that the barrier to entry is significantly higher now than it was in the 90s. All you needed was a text editor and an email account. Now you need accounts on whatever code forge is involved, and you didn't write enough unit tests, and you failed to properly format your pull request, and what do you mean you're not an expert in whatever version control we've adopted? This pull request sat in an open state because you didn't tag it appropriately. The CI system was updated and your code wasn't covered in the automated integration test, please resubmit after making minor punctuation changes in a metadata file. Doesn't really make sense to me. How many projects have you actually had this problem with? I don't think the author is right about things having been harder in the old days led to a higher proportion of the internet being qualified to contribute. I think it's much harder now to patch software upstream than it ever has been. For some people, using Git and Github is a barrier to entry. For others, submitting a patch to a mailing list is a barrier to entry.

musicale 6y ago
> dead for lack of interest by the sole maintainer in reviewing and merging patches I think you mean "lack of action" rather than "lack of interest." It's easy to be enthusiastic about developers doing lots of work for you (usually for free) and to cast them as "uninterested" if they don't comply quickly (or at all) with your requests. I suspect many maintainers are "interested" in reviewing and merging patches but are simply unable to perform large amounts of work without pay, due to time and financial constraints.

microtherion 6y ago

> It used to be you could email a patch to someone and that patch would get reviewed and committed. May I ask what communities you were involved in, and when? Even formatting patches so they could be reliably applied was a nontrivial matter. It was not uncommon for them to be applied manually (and sometimes faultily). Sometimes you would mail patches to maintainers directly, other times you would share them on mailing lists, where they would undergo a bit of "social review" (works for me!) and would or would not be applied. Some people just mailed entire modified files and expected maintainers to figure out the changes on their own. As for "committed", many maintainers may not even have used source code control (notably Linus didn't use any), and I can't recall a single project with publicly accessible repositories in the 1990s as opposed to tarball releases. > All you needed was a text editor and an email account. Now you need accounts on whatever code forge is involved [...] Getting an account on any of these code forges in 2020 is almost certainly much easier than getting an e-mail account at all in the early 1990s for many people. I don't agree with the author that contributing was easier in the 1990s. Generally, it involved a bit of a social process, trivial drive by fixes were not any more popular than today, there were coding standards to be observed (and not always written ones), in larger projects, you could expect to navigate some flame wars, and sometimes your contributions were rejected anyway because RMS decided to cancel your OS.

tom_ 6y ago
Very much mirrors my experience. Github provides a very useful project-independent unified UI for drive-by patches and off-the-cuff issues. No more mailing lists or bug trackers to sign up for and manage! And it's also even got an integrated version control system, that 99.9% of projects then use, and it's one that makes it easy to version control a fork of your own as you work on any patches you might be making. Progress!
- Conan_Kudo 6y ago
  > Very much mirrors my experience. Github provides a very useful project-independent unified UI for drive-by patches and off-the-cuff issues. No more mailing lists or bug trackers to sign up for and manage! And no more need to become emotionally invested in the project, thus furthering its development into a proper community of users and contributors that propel it forward. :(

ekiwi 6y ago

> It used to be you could email a patch to someone and that patch would get reviewed and committed. Yes, but 1990 is also when this study came out: https://ftp.cs.wisc.edu/par-distr-sys/technical_papers/fuzz.pdf https://ftp.cs.wisc.edu/par-distr-sys/technical_papers/fuzz.... They find that a lot of UNIX tools could be easily crashed by generating random inputs. The quality of our most popular open source software has dramatically improved over the last 30 years.

pjmlp 6y ago
Check the updated version of that paper, it hardly changed in 30 years. https://www.researchgate.net/publication/348025458_The_Relevance_of_Classic_Fuzz_Testing_Have_We_Solved_This_One https://www.researchgate.net/publication/348025458_The_Relev...

throwaway2245 6y ago

You could re-frame 'bureaucratic process' as 'expectation setting'. It also benefits the contributor to know what is expected of them. If you know that your contribution will be properly considered when it meets the outlined expectation, then it is easier to put in the effort to contribute.