Live data from Hacker News

My boundaries as an open source developer

joeldenning.com

191–200 of 251 posts

Re: My boundaries as an open source developer

#191

So much this. I'm glad he put this out there. I'll start linking to it too. There seems to be a common misconception about open source. When I release software as open source, it does not mean I work for you for free, need to provide you with anything, even need to be nice to you. I may. Or I may not. When I release software under an open source license, then we have a very specific deal. You are entitled to do certa…

I will preface this by saying I have immense respect for anyone who open-sources their work. I think the web as we know it today would not exist without such kind and hard-working individuals. In my opinion, I think most of these issues outlined in the article are caused by lack of communication combined with unclear expectations, to be honest. The only thing I ask of open-source library authors/maintainers is this:…

You could figure out all of this by looking at the project's releases, mailing lists and the bug tracker. That's something you should do even if a author puts up a statement because it might no longer be accurate.

Re: My boundaries as an open source developer

#192

Earlier quoted context omitted.

> People repeatedly demanding help in the github issues without even providing repro steps. This is the biggest annoyance for me. There's a very clear issue template on my repos. It provides concrete, reasonable requirements (for example, post the actual config that broke!) yet people frequently expect support without filling it out. Even worse, they will make drive-by comments/demands on random PRs instead of openin…

I literally print out a mostly pre-filled github link with most repro context, all they have to do is fill the rest of it in. They still don't do it. Nowadays a non-templated bug issue is autoclosed.

I am 90% of the way to adding "You have been banned from this issue tracker for wasting maintainer time. In future, make some attempt to do your share of the work." to the autoclose.

Re: My boundaries as an open source developer

#193

A few years back I was in a role where it was my job to maintain a small but non-trivial open source project (~1500 github stars, 5 core contributors). I burned out after about two years in that role. People repeatedly demanding help in the github issues without even providing repro steps. Hate mail to the project email list from users angry we didn't implement the feature they want in the latest release. We had peop…

Sounds like OS developers would benefit from Product Managers who could shield them from the users (among other PM tasks). Do many OS projects have PMs? Are there any "standards" around non dev roles in OS projects?

Bigger project here, but over at LibreOffice, our shield is a strong quality assurance team. 20-30 active triagers. The number has stayed constant over the years and we actively recruit. How I do recruiting: https://discourse.sustainoss.org/t/how-i-recruit-and-mentor-...

Re: My boundaries as an open source developer

#194

Earlier quoted context omitted.

Sounds like OS developers would benefit from Product Managers who could shield them from the users (among other PM tasks). Do many OS projects have PMs? Are there any "standards" around non dev roles in OS projects?

Unfortunately my experience is that most PMs are not sufficiently technical. They will often add more work by injecting useless processes and try to "demonstrate value" by coming up with new ideas without actually understanding the problem domain. The best approach I have found is simply to add more automated gates/bots. If people have not done what the bot asks, there's no need to waste time/energy on them.

> Unfortunately my experience is that most PMs are not sufficiently technical.

Yeah. And I eventually came to realize: lazy.

Re: My boundaries as an open source developer

#195

Is this kind of burnout perhaps in part due to the level of mechanization provided by the defacto platform for open source projects now: GitHub? It seems like it’s more frequent, but maybe that’s just me. It’s great that GitHub exists and lowers the barrier for anyone to develop and share open source efforts. But you also become a slave to its various very well automated processes. As a creative altruistic agent, tha…

Yes, many issues are simply users deciding that it is quicker to abuse maintainer time to get and answer than find out themselves, github does facilitate that.

What causes the most teeth grinding is when it is questions about their proprietary code. I don't care if their garbage never works! It's not going to help me or anyone else either way.

Re: My boundaries as an open source developer

#196

So much this. I'm glad he put this out there. I'll start linking to it too. There seems to be a common misconception about open source. When I release software as open source, it does not mean I work for you for free, need to provide you with anything, even need to be nice to you. I may. Or I may not. When I release software under an open source license, then we have a very specific deal. You are entitled to do certa…

I will preface this by saying I have immense respect for anyone who open-sources their work. I think the web as we know it today would not exist without such kind and hard-working individuals. In my opinion, I think most of these issues outlined in the article are caused by lack of communication combined with unclear expectations, to be honest. The only thing I ask of open-source library authors/maintainers is this:…

> I will preface this by saying I have immense respect for anyone who open-sources their work. I think the web as we know it today would not exist without such kind and hard-working individuals.

That itself is part of the problem.

I do also appreciate all the great FOSS ecosystems that I'm using. Who knows where we would be without them.

But open source software is not about some kind, selfless altruist who hacks away for free for the benefit of others. It's about publishing the source code with some attached rights and obligations for programs or libraries that have been developed to scratch an itch. Be it personal need, personal interest, learning opportunity or straight up business necessity. You publish to get a community involved to make your software better, be it through bug reports, recommendations for improvement, pull requests, etc. That ultimately benefits the author, and that's the whole point.

It's a misconception that open source software is (or should be) developed for the greater good, to be kind to one another. And by keeping to thank "kind hard working individuals" (which they often times are!), one perpetuates this misconception. It's great if kindness is a component in all of this. But it's not the central point and should not be expected to be. That's what causes threads like this one in the first place, where somebody has to complain about being exploited or getting annoyed with peoples expectations, or their own expectations with themselves, and then others opining about that.

> You painstakingly supported a library for years, got burned out and want to quit? At least try to pass it to another maintainer.

Are you serious? Above you just said that you have immense respect for open source authors. And now you say that somebody can't take it anymore and is burned out and THEN you STILL expect them to put MORE work in, despite being burned out, to pass things on? The source code is available, the license is clear, if there is anybody else who wants to maintain, they can just go and to it. Why do you keep demanding anything from the already-burned-out author that you respect immensely? Honestly, I find that deeply disrespectful.

Re: My boundaries as an open source developer

#197
Most of the comments here remind me of the famous Neil Gaiman quote, "George R.R. Martin is not your bitch." [1] But I don't think that's the right framing. People buy the first book because they hope there will be a second, even though they haven't paid for that second book and hence are not entitled to it. People use your open-source project because you said, hey, here's this exciting new thing, try it out, so they assume you'd also want to listen when it doesn't quite work as it should. That's not about a false sense of entitlement or callousness on the part of your users at all. It's also not about freeloading, because a lot of those pull requests and issues on Github will be coming from people who publish their own open-source software. Instead, it's about managing expectations, like the post does. Put a big "this project is not maintained" warning on top, and nobody will bother you. Although I do understand that for larger active projects, it can be hard to explain to users exactly where on the spectrum between "don't bother me" and "I'll fix your problem yesterday" you are, and the bigger a project gets, the more likely you'll be to encounter people who enjoy exploiting your free labor.

[1] https://journal.neilgaiman.com/2009/05/entitlement-issues.ht...

Re: My boundaries as an open source developer

#198
post #190

Earlier quoted context omitted.

I will preface this by saying I have immense respect for anyone who open-sources their work. I think the web as we know it today would not exist without such kind and hard-working individuals. In my opinion, I think most of these issues outlined in the article are caused by lack of communication combined with unclear expectations, to be honest. The only thing I ask of open-source library authors/maintainers is this:…

Totally agreed. One of the easiest ways to deal with misaligned expectations is to clearly state your expectations.

While that's true, it's sad that the default expectation seems to be "you provide support for me and keep maintaining this thing, and once you can't anymore, you'll find somebody else who does, so that I can keep benefiting for free from all your work".

The default expectation should be that there is nothing promised beyond what's in the license. Anything beyond it needs to be clearly stated, but in the absence of any such statement, don't assume or expect anything.

Note that this expectation is clearly stated in most FOSS licenses. Usually right at the top, IN CAPITAL LETTERS. Having to write an extra blog article that basically says "I really mean what is in the license" is redundant, and it's sad the this has do be done and is even being argued about.

Re: My boundaries as an open source developer

#199

Earlier quoted context omitted.

Would you do your current job for free for, say, six months to earn 'exposure' and 'warm fuzzy feelings'?

That’s a false dichotomy, because an ice cream parlor doesn’t stop selling ice cream when they give out free samples, any more than most open source developers quit their jobs (or stop searching for one) to work on their personal projects. Plus, you’re kind of asking the wrong person anyways, because I think I actually do significantly more work for free than I do for what I get paid for, just for those warm fuzzy fe…

Great, and the if the project you make for a bit more than six months of lots of dedication succeeds people might realize you are an expert in something and try to hire you into a job that is more than full-time and/or doesn't allow other programming with a very nice offer. I would expect you to take that job, but Internet haters will disagree.

Now the project someone chose for its high amount of free unguaranteed support goes off a cliff of no maintainer..

In my experience, I value projects with minimal maintenance over years by a large number of more selfishly invested contributors over the "excited just to be here" projects.

Re: My boundaries as an open source developer

#200

Earlier quoted context omitted.

Unfortunately my experience is that most PMs are not sufficiently technical. They will often add more work by injecting useless processes and try to "demonstrate value" by coming up with new ideas without actually understanding the problem domain. The best approach I have found is simply to add more automated gates/bots. If people have not done what the bot asks, there's no need to waste time/energy on them.

> Unfortunately my experience is that most PMs are not sufficiently technical. Yeah. And I eventually came to realize: lazy.

> > Unfortunately my experience is that most PMs are not sufficiently technical.

> Yeah. And I eventually came to realize: lazy.

Lazy is just one side of the coin. If someone's career is focused on unsexy hard work instead of halfheartedly "demonstrating value", the core problem is not that they cannot slack off. The core problem is that others can hold them hostage.

Post reply on HN