>But sometimes that’s the work that needs to be done.<p>So pay me. Like you said - it's work - I expect to be paid for work and if you need it done or it's in your interest it gets done - pay someone to do it (or do it yourself).
A bug that looks easy but is in fact hard is the worst case: low reputational payoff, but very high effort.<p>The first thought is that there ought to be an objective measure of the work done that can incentive contribution by accurately reflecting what someone has added to the community. On the other hand, measure lines of code added might have some unintended consequences...<p>It seems to me though that OP did appreciate the amount of effort involved, and presumably even more so because it was unglamorous work.<p>If all the community members understand that, then it seems to me the system is working to some extent. If peers are able to value the most useful contributions - that's what you are looking for, right?
> Everyone wants to be the master architect of the groundbreaking new framework in the hip new language.<p>Especially considering that more and more companies are (trying to) use this as a prerequisite for finding any paid work. I can't find the link, but I remember reading a writeup from a startup whose hiring manager required a couple of pull requests from well-known open source software as part of the interview process. This wasn't Facebook or Google, either, just another no-name startup.
Drupal has this problem, and has tried to counter this fact with:<p>- novice tags for bugs [1]
- mentions on your project bio page detailing how many contributions you have on drupal projects in the past three monts (even if it was only rolling a patch or commenting, if your name is just mentioned in the commit, you don't need to be the author) [2]
- and a lot of documentation on getting started [3]<p>And Dries (the creator of drupal) touch this same topic (comparing open source with the commons) in a 2014 DrupalCon keynote): <a href="https://youtu.be/4NN5EM4CYVE?t=10m45s" rel="nofollow">https://youtu.be/4NN5EM4CYVE?t=10m45s</a><p>[1] <a href="https://www.drupal.org/project/issues/search?status[0]=1&status[1]=8&status[2]=13&issue_tags_op=%3D&issue_tags=Novice" rel="nofollow">https://www.drupal.org/project/issues/search?status[0]=1&sta...</a>
[2] <a href="https://www.drupal.org/u/catch" rel="nofollow">https://www.drupal.org/u/catch</a>
[3] <a href="https://www.drupal.org/contributor-tasks" rel="nofollow">https://www.drupal.org/contributor-tasks</a> <a href="https://www.drupal.org/getting-involved" rel="nofollow">https://www.drupal.org/getting-involved</a>
I enjoyed this article, because it's just a concise, interesting observation of open-source incentives. There's no grandiose point or sweeping call to action, it just states an interesting observation.
An old LKML message that perhaps conveys why / how this is important: <a href="https://lkml.org/lkml/2004/12/20/255" rel="nofollow">https://lkml.org/lkml/2004/12/20/255</a><p>I think we often forget that sometimes, even just reporting bugs can be incredibly valuable, much less fixing them. Sure a lot of this is thankless work, but many OSS projects don't even get bug reports when they need them most.
I liked it very much. Applies not only to open source projects but also to regular software that you get payed for. May be you should not try get satisfaction from recognition, but get it from knowing that you are doing a good job; every day. Let the job be the reward. And yes, programming is a hard job.
I'm not sure I'd consider this apathy. My guess is that everyone who considered fixing this over those 8 years instinctively knew it was going to be a leaky fix. And that "fixing" it would likely lead to more bugs.