Live data from Hacker News

My boundaries as an open source developer

joeldenning.com

171–180 of 251 posts

Re: My boundaries as an open source developer

#171

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

So your solution to open source authors getting too many demands for doing things is to demand they should do more?

Seriously, this feels almost a bit like victim blaming. Why would an OSS maintainer need to write that something is a hobby project. It really doesn't matter, if as a company you want to rely on it, pay for it. Why should your expectations change because of what the maintainer says?

Re: My boundaries as an open source developer

#172

Always good to see an open source dev standing up for themselves, if only a little, against all the entitled freeloaders and techbros who are all too happy to exploit them and to encourage them to continue exploiting themselves If you build a product that uses open source libraries and you make money off that product, you should pay the people who created the open source libraries, even if they don't expect it or ask…

you should pay the people who created the open source libraries, even if they don't expect it or ask for it. Period.

As an author of open source projects with thousands of users: no. You should abide by the terms of the license, which I voluntarily chose and which does not have a secret passive-aggressive clause of "you're a piece of shit if you don't pay".

(Separately, the tipping model is awful and something we should be moving away from rather than expanding).

Re: My boundaries as an open source developer

#173
post #159
post #148

Earlier quoted context omitted.

Where is this muddying happening? The only place I've noticed it is on HN, where others always correct the poster by pointing at the Open Source Definition. Maybe it is time to ditch both "open source" and "free software" and go with something that has a clear meaning that isn't possible to muddy, like "libre software", prefixed with "always" for copyleft licenses and "currently" for permissive ones.

Those who sit on the Open Source side of things constantly muddy the waters and claim they are one in the same. Those who sit on the Free Software side of things are adamant that they are related but different. https://www.gnu.org/philosophy/open-source-misses-the-point.... The important bit is here: > “Free” and “open” are rivals for mindshare. Free software and open source are different ideas but, in most people's…

I meant to ask who is muddying the waters by claiming that "open source" == "source available" rather than the Open Source Definition published by OSI?

Re: My boundaries as an open source developer

#175

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…

Cultural norms around Slack / Discord (compared to the IRC of old) are also to blame. With email, people understand that there is a reply and that process takes time. Discord and Slack encourage people to keep the apps running, continually sapping time and energy.

The best thing a project can do to address burnout is to eliminate any sort of messaging option. Keep all discussions to the issue tracker and email.

Re: My boundaries as an open source developer

#176

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

> be upfront and clear about the nature of your library, and your level of commitment

The clear statement on this is in the license of the project. You need to read the license, which grants you certain rights to the software to see what you're being granted and what you're not getting.

In nearly every license, very specifically says that it's not supported and you're entirely on your own if you decide to use it.

If you need a higher level of assurance, you need to pay for support. Either from the author(s) if they are interested, or from third party companies who provide support for that library, if any exist.

Re: My boundaries as an open source developer

#177

Open Source licenses are not about entitlement to contributions, engagement with the maintainers, or even community building. Open Source license is exclusively about the software. But the "Open Source Movement" is blending over, and that's what is burning out so many people on both sides: maintainers and contributors. GitHub's Pull Request feature creates an expectation that the maintainers will read a contributor's…

> GitHub's Pull Request feature creates an expectation that the maintainers will read a contributor's code

> Back in the days of SourceForge...

Strongly agree. The github PR is a somewhat toxic misfeature. The last thing I want in my open source projects is some rando sending some huge diff that does who knows what. Now I'm supposed to read and understand this code and figure out all the unintended side effects? And even if the code is ok it's probably missing test coverage, doc updates, etc. So filling the gaps would generate more work for me.

However, I do like and accept tiny PRs that fix very targeted things.

I wish I could put a size limit on PR diffs in github. Something like if the PR changes more than 10 lines of code, block it. File a ticket instead of discuss the proposal, don't blast me with code I don't have time to read.

Re: My boundaries as an open source developer

#178

I think there should be term like suffering from open-source fatigue. Being an active open source dev myself I can relate to this but at the same time I also have been on the other side of the fence when my oss projects didn't get a lot of traction and any mention from anyone, even if it was an issue, got me really excited and it also kinda validated my efforts. It's like being a mini celebrity feeling happy when som…

This! Open source can make your career, just as much as the Op says; it can break your back.

From the outset i would say that most people releasing OSS stuff wants it to be used in production. thats until you get the hungry corps looking for free support. IMO at that stage an OSS maintainer needs to start a consulting company and funnel everything into it to avoid the burn. if this guy was making 6 figures consulting for those same companies, i think the conversation was different.

Unfortunately knowing how to write software is not always compatible with self-marketing and has a keen business acumen.

Re: My boundaries as an open source developer

#179

If an author can publish code with a take-it-or-leave-it attitude, why can't people make requests with the same attitude? If the author is under no obligations at all, a request is no problem, right? Well, the problem is that it's not so absolute. Publishing something normally invites feedback and it's awkward to completely ignore it. Just like it's awkward when you report a bug and get silence. I'm not suggesting a…

> I'm not suggesting a real obligation, but there is... something?

The only something there is, is what the license specifies.

Licenses vary, but generally the gist of it is that you get to use that code for free (with various limitations depending on license) and that's all you get. There isn't any something beyond that.

You're always free to negotiate and pay for a support contract if you prefer more than what the open source license grants you.

Re: My boundaries as an open source developer

#180
post #38

Earlier quoted context omitted.

It's not about honesty or fame. The author does not and can not know if the code is going to be good for your use case. Only you can know that. Evaluate it yourself and see if it works for you. If it doesn't, don't use it. It's really that simple.

If they can not know their software is good or bad just please choose another profession.

Why are you assuming this is their profession?
Post reply on HN