[woah]

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 who are willing to support them, and I'm guessing that an alternative to this project will supersede it, resulting in people not bugging the author any more.

[FooBarWidget]

> 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 despite not having paid for such a contract, then that support is an incidental gift that can go away at any time for any reason.

[saagarjha]

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

[TomasEkeli]

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

[saagarjha]

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.

[blittle]

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.

[saagarjha]

Nothing? Not at all: an open source developer gets the marketing/publicity benefit just like an ice cream parlor does. Why do you think companies open source their things? And as a solo developer, I get tons of high-quality inbound leads for job opportunities, get to interact with lots of smart people (many whom I end up forming long-lasting friendships with), and get other people to help improve and support my project with me. Plus I get the warm fuzzy feeling inside or high moral ground, or whatever you want to call it. If you’re not getting that from your open source work, why are you doing it anyways?

[passivate]

Indeed, there is a difference, but it is also quickly forgotten when your production system is down with the boss breathing down your neck.

[zaSmilingIdiot]

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

Isnt that the point? As in, it allows for the use of some (context-appropriate) open source upstream software to quickly flesh out some idea into an implementation, rather than expending time and effort writing certain code oneself (the user of the open source software). This doesn't absolve the user from the responsibility of eventually writing their own implementation, or alternatively, maintaining, that open source code/library/framework as a part of their overall codebase.

And so I seriously miss the point of where the managing or maintaining of some open source code, to satisfy some other downstream project's requirements, is the responsibility of upstream... again, when downstream uses it they do so to benefit themselves by not having to write or maintain that piece of software, but that comes with risks along with the relevant benefits. As in, its a "dependency" (in the name) for a reason.

I almost see it as bordering on a concept of entitlement to think that someone else (eg the original creator of some software) should spend time and effort fixing issues or adding functionality that benefits some user. Basically, one should always be considering that dependencies at the time of pulling them in are static and provided as is with no contract of maintenance, and that it might provide benefit currently but that there is a very real potential cost to using it in the future.

[henning]

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

That's exactly what it is, exactly how it says in the license:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

[wildmanx]

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

[ricardobeat]

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.

[wildmanx]

It's your right to as a user choose projects based on that criterion. It sounds reasonable to me.

But it's not your right to demand anything from a project, including demanding that they do basic maintenance or disclose whether they are going to do it. Maybe they don't even know, or maybe they change their mind lots of times ever year or every day. If you don't get a promise of this happening, neither assume anything nor start to demand it.

(Even if you get a promise, if it's some individual writing something on the net, it's not worth much. If they fail doing it despite the promise, they are being idiots, which they are free to be, and you are free to ignore them going forward or be angry.)

The attitude that published open source software is generally expected to be supported with basic maintenance is bad. It burns out creators who also believe in this myth and it creates an atmosphere that fosters this and in the end, less software is placed under open source licenses because people feel that that would include some obligation after. It does not. Just because you find some piece of code on the internet does not entitle you to anything.

[ricardobeat]

I’ve been publishing and contributing to open source software for 15+ years and have never experienced that attitude. Granted, none of my stuff reached huge success, but they are out there; I’ve also been close to a few mainstream projects, and from my POV this seems exaggerated. If anything, scaremongering comments like yours are what might stop people from publishing more.

It’s also pretty straightforward to disable issues in GitHub and ignore all the noise.

[wildmanx]

Then how do you explain the original article that we are discussing here? He's just imagining the problems that he is addressing in there?

Just look around this thread, you can find the described attitude even here.

[yawaramin]

It boils down to the same thing. Support can be specific for a business need or for just general maintenance and bitrot prevention.

[jjav]

> it does make it sound like unsupported software

Nearly all open source software is by definition unsupported (read the license).

If you need support you can pay for it (and in the blog the author specifically states they are open to communications regarding paid consulting work).

[kccqzy]

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

[bjt]

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 than reviewing the code, I'm more likely just to review the interface and docs. There's a continuum of possibilities in between. Different people may rationally draw the line where they'll do code reviews at different places on that continuum.

[wildmanx]

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.

[jjav]

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

It is very specifically unsupported software! Read the license, it's right there in a legal document clearly spelled out (for many licenses, anyway).

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

A good phrase is that importing an open source library is like adopting a puppy. Sure you get the initial code for free, but all the work and mess from there on it's all on you.

Yes, if you want to rely on an open source library for production you do need to understand it as if you'd written it yourself! I know this principle has been lost in more recent times, but it remains reality. If you don't, you're just gambling on the hope that it'll work out. It can, but it's a gamble.

If you need more certainty, pay for a support contract with SLAs.

[layer8]

> it does make it sound like unsupported software.

They specifically welcome requests for professional support.