4 ms·

Open source is really hard. * Sometimes, issues are just questions that belong on StackOverflow or any other forum online. * Often people suggest pull request

Open source is really hard. * Sometimes, issues are just questions that belong on StackOverflow or any other forum online. * Often people suggest pull requests that don't really fit what you see as the roadmap for the project, you have to be polite and respectful. * There's the case of beginners trying to jump in, if your project is something that appeals to beginners (eg:Rails), you are in for a whole bunch of other issues supporting the getting-started. * There's a lot of stress involved with managing all of this, if you are alone in the project it can get pretty overwhelming. * Finding collaborators on open source projects is not easy as well, most of the times the project README doesn't suggest that collaborators are welcome and appreciated. * Forking creates a lot of fragmentation. * I can think of many projects that lost the steam. Resque is the perfect example for me, even with new contributors it failed to get going and Sidekiq won. * We still need to figure out a reward system for open source to prevent maintainers from losing steam along the way.

seiji 11y ago
Sometimes, issues are just questions that belong on StackOverflow or any other forum online. Exactly. GitHub offers no support for on boarding new issues, so a lot of well meaning misplaced questions can pile up quickly. There's no GitHub issues MOTD or "have you tried X, Y, Z first?" or even a way of saying "issue tracker is for provable bugs only — not for asking why our software doesn't compile on your 16 year old version of RedHat." We still need to figure out a reward system for open source The universal currency for exchanging units of time for units of economic productivity is money. (and not "oh, my employer gives me $5 a month to donate anywhere I want, we are so special!" but rather, $200k to $3m per year to projects that help run your company.)
- x0x0 11y ago
  In other news, people continue to be surprised that demand for free labor outstrips supply :D We've discussed this here before, but I bet the majority of companies are parasites. Heavy consumers of open source, with virtually 0 contributions of money or time. I think we should resolve, particularly those of us in a position to make it happen, to donate to open source projects. I do (and I stay anonymous for multiple reasons) run a small open source ML project. I ignore virtually all support requests, but if you are a heavy open source contributor, you will get a response. You should mention that in emails; I'll go out of my way to help you (and often even promptly!)
  - mpdehaan2 11y ago
    +Lots to wanting to help heavy contributors first. While there are a lot of "hey free software" people who don't contribute back, I love those non-contributor companies when they pay actual money for something. My experience is those are usually very reasonable with time-table on fixes and understanding, and the business relationship adds value. Maybe this is more about the maturity level of the company you are likely to be working with, I don't know. If someone is however just a user, though, often they feel obligated to get infinite value rather than just the value they are paying :)
  - avitzurel 11y ago
    I don't think it's about being a parasite. I definitely think there should be a more established system of contributing money to open source. There's also a matter of perception that Open Source means FREE, while yes, you don't HAVE to pay for it. a lot of times you SHOULD. I am working on a big open source project now in the DevOps space and right out of the box I am going to have a "Pro" version. Maybe more projects should adopt this approach.
  - chrismartin 11y ago
    I would call those companies epiphytes [0], not 'parasites', which is untrue and pejorative. Adoption of FOSS is good for society whether or not adopters contribute back to the project (even though they should). [0] https://en.wikipedia.org/wiki/Epiphyte https://en.wikipedia.org/wiki/Epiphyte
  - meric 11y ago
    Well, they provide software engineers with a living so these same software engineers can build open source software in their free time, so that software engineers can use the open software at work. Just like doctors who, without fees and in their own time, devise new ways to perform life-saving surgery and trying it out on willing patients.
  - pedrocr 11y ago
    > I ignore virtually all support requests, but if you are a heavy open source contributor, you will get a response. You should mention that in emails; I'll go out of my way to help you (and often even promptly!) Seems like a very sensible policy but will people really volunteer that in emails with no notice? Or do you state that somewhere in the project documentation? I'm a reasonably active open-source contributor but it wouldn't occur to me to mention it when sending an email to a project in an unrelated space.
- avitzurel 11y ago
  > The universal currency for exchanging units of time for units of economic productivity is money. (and not "oh, my employer gives me $5 a month to donate anywhere I want, we are so special!" but rather, $200k to $3m per year to projects that help run your company.) This! I would love to see this happening.
- daxelrod 11y ago
  > There's no GitHub issues MOTD If you put a CONTRIBUTING or CONTRIBUTING.md file in the root of your repo, a link to it will appear on the top of the page when people create issues or pull requests. https://github.com/blog/1184-contributing-guidelines https://github.com/blog/1184-contributing-guidelines
  - Lukasa 11y ago
    Yeah, so this is an interesting feature because in my experience it doesn't work. [We added one](https://github.com/kennethreitz/requests/blob/master/CONTRIBUTING.md https://github.com/kennethreitz/requests/blob/master/CONTRIB...) for the Requests module a little while ago because we kept getting bug reports that contained incomplete tracebacks or vague problem statements, or questions that were better suited to Stack Overflow. However, we still get plenty of issues opened that suggest that the user hasn't read the CONTRIBUTING.md. We still get questions on the tracker, we still get people not telling us what version they're using or what platform they're running on. What I want to know is: is this our fault? Is our text bad? Or does GitHub's UI not accentuate the need to read this document firmly enough?
    - kelnos 11y ago
      People don't read. That's pretty much it. Maybe, maybe, if there was some in-line text above the issue form submission, and it was very short (like one or two sentences), people would read that. But any long-form prose is going to be skipped, and likely something that requires clicking a link to read an external CONTRIBUTING document isn't going to be read either. I ran into this a lot in pre-GitHub (and pre-git) days when maintaining OSS. It got to the point where I would reply to emails with a simple one liner "Addressed here: [link]" or, "Bug report requirements: [link]". I felt horribly rude doing so sometimes, but I realized that people were not respecting my time by failing to take a minute or two to read through the bug report guidelines, and so I wasn't going to waste my time being polite. There's unfortunately a lot of entitlement among open source users, and it gets tiring after a while.
    - mpdehaan2 11y ago
      Yeah contributing.md doesn't get read much, or it gets skimmed over. Issue templates seem to MOSTLY fix the problem, so we wrote a bot that sticks in some canned questions when it looks like your bug didn't follow the template. People recoiled to the bot for months but new users were totally fine with it. I really wish GitHub had some sort of optional facility for a stock template for the "bug" field, as it would save collective years of people's combined lives. It would just need to populate some text in the issue box by default. Call this ISSUE_TEMPLATE.md if you want, etc. Various third party attempts to do this - like use this bug page instead of github's new issue form, don't really work as the one NICE thing about github is that everyone knows how every project sort of works. Sort of. Which is also the one nice thing as they don't join the lists or really understand how various projects really really work :)
mpdehaan2 11y ago
Amen... I totally got the second job feeling. I mean I love all the contributors - I do, but a few nights a week is fun, all of them is bad, when it starts to eat your Saturday, that's a steamroller. There's reward, yes, but mostly there's a lot of people who (queue up the Sixth Sense voice) that WANT THINGS. I mean, everybody totally means well, they do... but so many people wanting so many things. You could spent all your time just helping people who didn't read the docs, helping misunderstandings, restating the obvious, code review, website editing, so many things. And you have no time to do them all flawlessly, so you do them all the best you can, and get hammered on the things you couldn't be perfect on. Then you get into Catch-22 scenarios as the project grows and must please conflicting audiences. Open source is really really really hard. I think ones with very focused audiences (say, like, insect biology?) may have it easier - the more general purpose you are, the greater the demands from diverse audiences. Programming languages may have it the hardest, I don't know. Given, most people will probably think I succeeded at all of those things, but it also broke me in ways that would make me reconsider doing it that way again. Maybe everybody has energy to do it some, but ... it's rough. There's so much more to it than just writing code too.
- voltagex_ 11y ago
  My ideal job would be as a GitHub janitor. Cleaning up and helping with projects that have become too unwieldy or need a little duct-tape to keep going.
  - avitzurel 11y ago
    I always want to do it and I always feel that most maintainers will not really like it.
    - voltagex_ 11y ago
      I've had both positive and negative responses. Sometimes it's easier just to fork and continue independently.
    - voltagex_ 11y ago

seiji 11y ago

Sometimes, issues are just questions that belong on StackOverflow or any other forum online. Exactly. GitHub offers no support for on boarding new issues, so a lot of well meaning misplaced questions can pile up quickly. There's no GitHub issues MOTD or "have you tried X, Y, Z first?" or even a way of saying "issue tracker is for provable bugs only — not for asking why our software doesn't compile on your 16 year old version of RedHat." We still need to figure out a reward system for open source The universal currency for exchanging units of time for units of economic productivity is money. (and not "oh, my employer gives me $5 a month to donate anywhere I want, we are so special!" but rather, $200k to $3m per year to projects that help run your company.)

x0x0 11y ago
In other news, people continue to be surprised that demand for free labor outstrips supply :D We've discussed this here before, but I bet the majority of companies are parasites. Heavy consumers of open source, with virtually 0 contributions of money or time. I think we should resolve, particularly those of us in a position to make it happen, to donate to open source projects. I do (and I stay anonymous for multiple reasons) run a small open source ML project. I ignore virtually all support requests, but if you are a heavy open source contributor, you will get a response. You should mention that in emails; I'll go out of my way to help you (and often even promptly!)
- mpdehaan2 11y ago
  +Lots to wanting to help heavy contributors first. While there are a lot of "hey free software" people who don't contribute back, I love those non-contributor companies when they pay actual money for something. My experience is those are usually very reasonable with time-table on fixes and understanding, and the business relationship adds value. Maybe this is more about the maturity level of the company you are likely to be working with, I don't know. If someone is however just a user, though, often they feel obligated to get infinite value rather than just the value they are paying :)
- avitzurel 11y ago
  I don't think it's about being a parasite. I definitely think there should be a more established system of contributing money to open source. There's also a matter of perception that Open Source means FREE, while yes, you don't HAVE to pay for it. a lot of times you SHOULD. I am working on a big open source project now in the DevOps space and right out of the box I am going to have a "Pro" version. Maybe more projects should adopt this approach.
- chrismartin 11y ago
  I would call those companies epiphytes [0], not 'parasites', which is untrue and pejorative. Adoption of FOSS is good for society whether or not adopters contribute back to the project (even though they should). [0] https://en.wikipedia.org/wiki/Epiphyte https://en.wikipedia.org/wiki/Epiphyte
- meric 11y ago
  Well, they provide software engineers with a living so these same software engineers can build open source software in their free time, so that software engineers can use the open software at work. Just like doctors who, without fees and in their own time, devise new ways to perform life-saving surgery and trying it out on willing patients.
- pedrocr 11y ago
  > I ignore virtually all support requests, but if you are a heavy open source contributor, you will get a response. You should mention that in emails; I'll go out of my way to help you (and often even promptly!) Seems like a very sensible policy but will people really volunteer that in emails with no notice? Or do you state that somewhere in the project documentation? I'm a reasonably active open-source contributor but it wouldn't occur to me to mention it when sending an email to a project in an unrelated space.
avitzurel 11y ago
> The universal currency for exchanging units of time for units of economic productivity is money. (and not "oh, my employer gives me $5 a month to donate anywhere I want, we are so special!" but rather, $200k to $3m per year to projects that help run your company.) This! I would love to see this happening.
daxelrod 11y ago
> There's no GitHub issues MOTD If you put a CONTRIBUTING or CONTRIBUTING.md file in the root of your repo, a link to it will appear on the top of the page when people create issues or pull requests. https://github.com/blog/1184-contributing-guidelines https://github.com/blog/1184-contributing-guidelines
- Lukasa 11y ago
  Yeah, so this is an interesting feature because in my experience it doesn't work. [We added one](https://github.com/kennethreitz/requests/blob/master/CONTRIBUTING.md https://github.com/kennethreitz/requests/blob/master/CONTRIB...) for the Requests module a little while ago because we kept getting bug reports that contained incomplete tracebacks or vague problem statements, or questions that were better suited to Stack Overflow. However, we still get plenty of issues opened that suggest that the user hasn't read the CONTRIBUTING.md. We still get questions on the tracker, we still get people not telling us what version they're using or what platform they're running on. What I want to know is: is this our fault? Is our text bad? Or does GitHub's UI not accentuate the need to read this document firmly enough?
  - kelnos 11y ago
    People don't read. That's pretty much it. Maybe, maybe, if there was some in-line text above the issue form submission, and it was very short (like one or two sentences), people would read that. But any long-form prose is going to be skipped, and likely something that requires clicking a link to read an external CONTRIBUTING document isn't going to be read either. I ran into this a lot in pre-GitHub (and pre-git) days when maintaining OSS. It got to the point where I would reply to emails with a simple one liner "Addressed here: [link]" or, "Bug report requirements: [link]". I felt horribly rude doing so sometimes, but I realized that people were not respecting my time by failing to take a minute or two to read through the bug report guidelines, and so I wasn't going to waste my time being polite. There's unfortunately a lot of entitlement among open source users, and it gets tiring after a while.
  - mpdehaan2 11y ago
    Yeah contributing.md doesn't get read much, or it gets skimmed over. Issue templates seem to MOSTLY fix the problem, so we wrote a bot that sticks in some canned questions when it looks like your bug didn't follow the template. People recoiled to the bot for months but new users were totally fine with it. I really wish GitHub had some sort of optional facility for a stock template for the "bug" field, as it would save collective years of people's combined lives. It would just need to populate some text in the issue box by default. Call this ISSUE_TEMPLATE.md if you want, etc. Various third party attempts to do this - like use this bug page instead of github's new issue form, don't really work as the one NICE thing about github is that everyone knows how every project sort of works. Sort of. Which is also the one nice thing as they don't join the lists or really understand how various projects really really work :)

mpdehaan2 11y ago

Amen... I totally got the second job feeling. I mean I love all the contributors - I do, but a few nights a week is fun, all of them is bad, when it starts to eat your Saturday, that's a steamroller. There's reward, yes, but mostly there's a lot of people who (queue up the Sixth Sense voice) that WANT THINGS. I mean, everybody totally means well, they do... but so many people wanting so many things. You could spent all your time just helping people who didn't read the docs, helping misunderstandings, restating the obvious, code review, website editing, so many things. And you have no time to do them all flawlessly, so you do them all the best you can, and get hammered on the things you couldn't be perfect on. Then you get into Catch-22 scenarios as the project grows and must please conflicting audiences. Open source is really really really hard. I think ones with very focused audiences (say, like, insect biology?) may have it easier - the more general purpose you are, the greater the demands from diverse audiences. Programming languages may have it the hardest, I don't know. Given, most people will probably think I succeeded at all of those things, but it also broke me in ways that would make me reconsider doing it that way again. Maybe everybody has energy to do it some, but ... it's rough. There's so much more to it than just writing code too.

voltagex_ 11y ago
My ideal job would be as a GitHub janitor. Cleaning up and helping with projects that have become too unwieldy or need a little duct-tape to keep going.
- avitzurel 11y ago
  I always want to do it and I always feel that most maintainers will not really like it.
  - voltagex_ 11y ago
    I've had both positive and negative responses. Sometimes it's easier just to fork and continue independently.
  - voltagex_ 11y ago