Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My boundaries as an open source developer

joeldenning.com

Post reply on HN
Print view View original

111–120 of 251 posts

Re: My boundaries as an open source developer

#111

Post by TomasEkeli »

saagarjha wrote: post #102
FooBarWidget wrote: post #49

Earlier quoted context omitted.

> but it does make it sound like unsupported software Pretty much every open source license contains a section along the lines of "there is absolutely no warranty". Older projects make this crystal clear in their readme. Newer, hipper projects don't, but that's only because they don't state it as explicitly. Open source software is unsupported software unless you paid for a support contract. If you still get support…

There’s a difference between “please don’t ask for support” and “I’m happy to support you even though legally you can’t force me to support this”.

i think those two actually collapse to the exact same thing: "no guaranteed support"

Re: My boundaries as an open source developer

#112

Post by wildmanx »

woah wrote: post #34

I totally get where they are coming from but it does make it sound like unsupported software. After reading that, I would not use it without completely understanding the code as if I had written it myself (and maybe that's what you should do for every dependency anyway). I would probably look for another open source project to use instead. There seems to be a constant supply of people starting open source projects wh…

> I totally get where they are coming from but it does make it sound like unsupported software.

All software is "unsupported software" unless explicitly stated otherwise. Just because some software has its software published under an open source license does not make it magically "supported". Not more than any proprietary software.

If you want support, pay for it. You can already be glad that somebody published the source code under a somewhat permissive license (i.e. not just an illegal leak). They have their reasons. Don't just assume a "support for free model", since that assumption is most certainly incorrect.

The reason that people support their open source projects _anyway_, and _for free_ is a mix of (1) self-interest, since I want my software to not have bugs, so of course I fix reported bugs, otherwise I may run into them myself, (2) fun, since it's just fun to tinker with things, (3) business interest, since showing support makes me look good to potential customers and (4) misconceptions on the author's side, thinking they have an obligation, fueled by threads like these.

Reasons (1)-(3) are fine. Reason (4) is terrible and I wish it would stop.

Re: My boundaries as an open source developer

#113

Post by wildmanx »

bjt wrote: post #83
kccqzy wrote: post #57

Earlier quoted context omitted.

> maybe that's what you should do for every dependency anyway Exactly. When your colleague wants to write new code in your repo you do a code review. When a stranger writes a large amount of code shouldn't you also do a code review?

Sometimes. Depends on the boundaries between your code and theirs. I write Go apps and deploy them in the cloud. I haven't done a code review of Linux, Docker, Kubernetes, or the Go standard library. When an independent person puts out a library that I'm going to depend on, yes I'll review its code first. When I'm building on something that's backed by a big company (Google) or solid foundation (the PSF) then rather…

Sure, you can blindly trust your dependencies. And most people do. But don't expect them to help you for free if you have a problem. They might. But likely they won't.

Try sending an email to Linus Torvalds if something with the Linux kernel is not to your liking and you'd like him to change something. Brace for impact. Well, at least with the "old" Linus. He calmed down a little recently.

Re: My boundaries as an open source developer

#114

Post by cweagans »

GoToRO wrote: post #38
cweagans wrote: post #37

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.

Software is not inherently good nor bad. It either solves a problem you have or it doesn't. Linux, for instance, is not a great fix for my specific uses on the desktop. That doesn't make Linux bad. It's just not the right solution for my particular set of problems.

Re: My boundaries as an open source developer

#117

Post by saagarjha »

TomasEkeli wrote: post #111
saagarjha wrote: post #102

Earlier quoted context omitted.

There’s a difference between “please don’t ask for support” and “I’m happy to support you even though legally you can’t force me to support this”.

i think those two actually collapse to the exact same thing: "no guaranteed support"

Collapsing them misses the nuance that I am specifically talking about. It’s kind of like when the ice cream parlor down the street gives our free samples and you decide to go “well, actually, they don’t have to give you any samples because they can refuse service to anyone so in fact there is no difference in them providing free samples and not providing free samples” and it turns out that people can offer things in good faith without having to promise them in a legal contract. You definitely shouldn’t prepare a lawsuit based on the free samples but it’s totally reasonable to visit every week to try their latest flavor.

Re: My boundaries as an open source developer

#118

Post by ricardobeat »

wildmanx wrote: post #112
woah wrote: post #34

I totally get where they are coming from but it does make it sound like unsupported software. After reading that, I would not use it without completely understanding the code as if I had written it myself (and maybe that's what you should do for every dependency anyway). I would probably look for another open source project to use instead. There seems to be a constant supply of people starting open source projects wh…

> I totally get where they are coming from but it does make it sound like unsupported software. All software is "unsupported software" unless explicitly stated otherwise. Just because some software has its software published under an open source license does not make it magically "supported". Not more than any proprietary software. If you want support, pay for it. You can already be glad that somebody published the s…

By “unsupported software” I don’t think he means any kind of support for his particular use of the software, but simply the pace of development - keeping up with system API evolution, dependencies, fixing bugs in the original code.

Software rots, and you generally don’t want to adopt a project that is not having basic maintenance being done.

Re: My boundaries as an open source developer

#119

Post by blittle »

saagarjha wrote: post #117
TomasEkeli wrote: post #111

Earlier quoted context omitted.

i think those two actually collapse to the exact same thing: "no guaranteed support"

Collapsing them misses the nuance that I am specifically talking about. It’s kind of like when the ice cream parlor down the street gives our free samples and you decide to go “well, actually, they don’t have to give you any samples because they can refuse service to anyone so in fact there is no difference in them providing free samples and not providing free samples” and it turns out that people can offer things in…

That's a poor analogy. An ice cream parlor offers free icecream purely to market thier product and drive business. An OSS dev gets nothing.

Re: My boundaries as an open source developer

#120

Post by brunoborges »

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 code, whether they had discussed about it or not.

Back in the days of SourceForge, open source software would be simply put for download. Anyone willing to collaborate, often times would first engage in the mailing lists or forums. That is not what GH Pull Requests do though, but quite the opposite. It builds on the idea that it is easier to discuss by showing code than by exchanging words. But that's just not how it works for anything beyond trivial/typo fixes. And that just frustrates everyone.

This is the flow I'd like to see GitHub allowing maintainers to choose, in addition to leaving today's flow as default:

- Allow maintainer to disable Pull Requests just like they can disable Issues/Discussions

- Allow maintainer to "Open Issue for Pull Requests"

This basically means that Pull Requests are on a per-issue basis, not per-repo. And only if the maintainers open said issue for accepting Pull Requests. This would push the contributors to first dialogue and discuss the enhancements/bugs before wasting any time writing code thay may never be accepted.

This flow would be much better for setting the right expectations, in my opinion.

Post reply on HN