Apathy of the Commons | Hacker News Reader

Apathy of the Commons

stuartsierra.com

64 pointsbbgm19 comments

>But sometimes that’s the work that needs to be done.

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).

Absolutely. Otherwise it has to compete with all the other things I could be doing with my discretionary time (otherwise known as the rest of my life) and I suspect therefore isn't going to come out on top.

A bug that looks easy but is in fact hard is the worst case: low reputational payoff, but very high effort.

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...

It seems to me though that OP did appreciate the amount of effort involved, and presumably even more so because it was unglamorous work.

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?

How about reputational points gained tied to the number of votes on the bug? This would both encourage coders to fix bugs that impact more people and encourage users to voice their opinion (vote on bugs) more often and more intelligently.

Alternatively, the maintainer assigns a point value to each bug, and whoever fixes it gets those points, which is then used to rank contributors within that project (but not across projects because of bug valuation inconsistencies and differing values of the projects themselves).

> Everyone wants to be the master architect of the groundbreaking new framework in the hip new language.

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.

I've seen this, and it's a ridiculous pre-requisite. If I'm going to work on side projects they need to be things I find interesting, and that I'm willing (and able) to work on when I'm tired/hungry/cranky/otherwise worn out at the end of a day of paid work... which pretty much means they need to be my side projects, rather than dull PRs on some OSS uber-project where I maybe have to deal with a load of politics, jump through a load of hoops, or perhaps the barrier to entry for useful contribution is too high (e.g., due to project complexity).

Drupal has this problem, and has tried to counter this fact with:

- 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]

And Dries (the creator of drupal) touch this same topic (comparing open source with the commons) in a 2014 DrupalCon keynote): https://youtu.be/4NN5EM4CYVE?t=10m45s

[1] https://www.drupal.org/project/issues/search?status[0]=1&sta... [2] https://www.drupal.org/u/catch [3] https://www.drupal.org/contributor-tasks https://www.drupal.org/getting-involved

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: https://lkml.org/lkml/2004/12/20/255

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.

After reading the article, I don't understand why the author didn't fix the bug himself.

Are you sure you aren't being passive aggressive? This is a problem with open source software. If you point out a problem one person at least will tell you that you should be the one to fix it.

Maybe, but it's hard to be moved and stirred by the author's ethical call to action in the last sentence when he himself clearly can't overcome the behavior he's complaining about.

So you are only allowed to point out problems that you yourself don't suffer from?

It's not a problem with open source software.

People who raise reproducible bugs are helping a project to develop, not everyone has to be a coder. However, there's an important difference between commercial software and open source software, which is related to the voluntary nature of open source.

Unless they're paid to work on open source, someone will become an open source developer by 'scratching their own itch', in other words putting the effort in to improve something that matters to them.

Knowing this should be reflected in the attitude of those that find issues. Quite a few times I've seen people get annoyed at developers for not fixing their bugs. Simply put, the developers owe you nothing, they give up their free time to do what they enjoy. Any bug raising should be done respectfully, and the times I've seen the 'you should be the one to fix it' response tend to be after someone is indirectly telling someone else how to use their free time.

If my employer's interests are better served by a 1 hour workaround, rather than an 8-hour open source contribution effort, professionalism requires that I do the former.

More importantly, if it's a problem you found and fixed on company time, the fix is now IP belonging to your employer. You would need the company to release the code to the project. That's not something you can unilaterally do on your own unless there's a prior agreement about it.

Perhaps we can use deep learning to find bugs in the code?

Reply on news.ycombinator.com