Comment by avitzurel | Hacker News Reader

Comment by avitzurel | Hacker News Reader

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.

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.

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.

I always want to do it and I always feel that most maintainers will not really like it.

I've had both positive and negative responses. Sometimes it's easier just to fork and continue independently.

A good way to start is to check up on your open issues across all projects: https://github.com/issues

Many of the responses I get are like https://github.com/bruderstein/nppPluginManager/issues/1

The most negative one I got was being told that "time doesn't fix issues, work does" - which is pretty fair.

The most helpful response is something like https://github.com/asb/raspi-config/issues/57. Yes, I could be more tactful but it was never my strong point.

I think the worst is when some people show a sense of entitlement and default to throwing a tantrum when a response doesn't go the way they want, even if it is the logical outcome of what has happened.

For example, one time I had closed an issue after asking for a clearly worded explanation to a claimed bug in implementation and/or a reproduction, and I got a broken reproduction with more unclear response. After closing the issue, I got some rapid fire responses in the issue from the person with all sorts of accusations.

After the person fixed the reproduction, it turned out the person was right, but unclear explanation and a supposed reproduction that did not show a bug caused a lot of wasted time because the person was too hasty, and the tantrum only added stress for all parties.

These are the types of interactions that make me want to not do open source work - people not taking the care to do the necessary investigation to avoid wasting time and generally respecting other people. It's as if those people don't realize that open source maintainers are there precisely to help if they can.

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

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

+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 :)

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.

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

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.

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

I actually do mention I'll make an extra effort for you if you contribute to OS. I added it after recognizing the name of someone who emailed me, realizing I'd been using software he wrote for years, and feeling like I owed him an effort.

That said, I think it never hurts when asking an OS contributor for a favor to point out you do the same, even to a completely unrelated project.

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

> 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

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/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?

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.

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

Reply on news.ycombinator.com