I have a nitpick on that take. If maintainer was actively building community and advocating use of his project (for whatever reasons but usually to gain audience - money is not the only value exchange that there is) they still do owe users bug fixes or reviewing bug fixes made by community. Especially if there were other community contributions, cash on hand is too specific.
If someone doesn't want to owe users anything, don't make project open source or make it clear "don't use this or fork for yourself, please" in read-me or something.
But also one should not pull dependencies willy-nilly especially if one is building business on top of that.
Did maintainers make any promise? Even so they can break promises made for some reasons (especially sickness, accidents, etc.). Whatever type of contributions (money, work, feedbacks, etc.) doesn't make maintainers owe any work to contributors unless previously mutually agreed upon.
Be prepared to DIY (PR, fork, other forms) if you are willing to but you don't owe anything to other people unless you choose to and express that explicitly, and that's the same for maintainers.
I put my software in the open with a license which I think is fair, because I hope someone might find it useful, with a completely neutral stance. On the other hand, I set my expectations with the license I assign to my codebase. If nobody cares about what I do, I'm also fine with it. At the end of the day, I wrote that thing for myself in the first place.
If somebody decides to contribute something back, my primary responsibility is to act as decently as other party allows me. They can report a bug, send in a fix, or ask something.
If the proposed change is favorable to both of us (i.e. it also fits into the design/role I have in my mind for that codebase, or doesn't disturb it), why not work together and make something better?
If the change makes the software unfit for me, but fit for the other party, they're free to fork and maintain their fork as they fit, as long as they honor the license. This is why is this thing is in the open.
But, if the requester wants me to implement their changes to make the software fit for themselves, while making it unfit for me, and want to pass the burden of maintenance on me, then sorry, we can't cooperate.
Plus, who decides which codebase I open to the world, and in what way?
I wrote that if you build community you have responsibility. If you don't want to build a community be clear about it.
My beef is with people who build community for "fame" and for "money somewhere along the road" - that are getting burned out because money are not there. Where we have loads of libraries by genuine people.
Can you give out some examples of projects that function(ed) on this principle?
That's where I believe you misunderstand open source, and that's the point of the article.
Because I make my project open source does not imply anything other than the terms of the licence. Of course it's okay to report a bug (it's even nice) or to open a PR. But asking "is this maintained?" as part of the decision process before depending on a project just shows some misunderstanding about how open source works, IMHO.
Having the standard website/readme with a bunch of claims about how awesome your software is as a way to entice other developers to get excited by it, start using it, and even (gasp) depend on it absolutely implies something more than the mere terms of the license.
Put elsewise: if you don't want the expectation of feeding people, haven't put any thought into how you will actually make that happen, and are just going to get defensive when people are annoyed at how you don't own a grill, you have no business inviting everyone to a BBQ.
https://imgur.com/a/chris-pratt-barbecue-gDL2O
https://www.reddit.com/r/funny/comments/3v8svx/barbecue_at_c...
Because it's irrelevant to my point. My point being that if you don't sign a contract with me where I commit to do something for you, then I don't owe you anything.
If you misunderstand open source and have wrong expectations because of it, then you will get frustrated. My point is that it is important for you to understand that open source just means that the author shares something for free, no strings attached. Maybe the maintainer is super responsive today, and that's great. But you have to know that they may stop responding tomorrow. And you should be ready to handle that if you depend on their project for something important.
> But also one should not pull dependencies willy-nilly especially if one is building business on top of that.
If you're building a business, you want to avoid all such dependencies as much as possible, open source or not. The big advantage to using open source code, though, is that you don't have to rely on someone else -- not even the maintainer -- to keep things going for you. You can maintain it in-house and eliminate that external dependency.
Most free-beer software state "Provided as-is with no warranty expressed or implied." somewhere in their readme or licensing terms.
Of course, fucking noone reads readmes or licenses.
If the software isn't being sold, it presumably won't be legally required to be fit for purpose in any sense. The no warranty provided text is just stating this explicitly. (Usual disclaimer: I'm not a lawyer, this is not legal advice, etc.)
A worker's time is worth their wage. If you're paying nothing, nothing is owed. If you pay nothing for a creation, the creator owes you nothing. That's the contact.
And property and grocery goods aren't even the same category as IP - You can't consume the same cabbage repeatedly.
> That's the contact.
I think you mean contract, but you are ignoring the social contract here. A "worker" isn't going around advocating their own project(s).
My code is open source, at a minimum it’s there for your own perusal to be copy-pasted. I don’t owe you anything.
or allowing community members the power to do these things, without having to fork.
Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up.
One of the worse offenders I have seen was adding whole Pandas and the kitchen sink for a simple table lookup. I have seen other programs which adds almost hundred libraries for something which can be implemented in a relatively simple way.
Then people whine about dependency hell.
Well that's where modern bundler steps in - who cares if you throw the unnecessary cruft away during build process?
Except in Python where a dependency might uninstall your desktop GUI and switch the init system, perhaps.
The problem is inclusion of that much libraries creates a dependency hell, because a higher level library pulls in approximately 5 more libraries which are generally shared amongst other libraries you potentially pull.
Library A updates its' dependency to library C to a new, more recent minimum, but library B depends on C's behavior which is recently changed. Hence A requires C > v3, but B requires C==v2. Then the fun begins.
Bonus points for having a serious CVE/RCE as a reason for updating C to v3 in the first place.
You fix the bug, and the behavior changes, because your design was wrong in the first place. Now there is at least one library which depends on that behavior so bad, so they can't change their dependency chain in two days.
You can say you'd prefer a bunch of smaller more focused libraries, but criticizing that big one is wrong, especially if you got it for free including the source and a license to distribute and modify it. And this has nothing to do with how you should or should not code, there's no definite way how everyone should code; some prefer batteries-included frameworks and some prefer small focused pieces - it's an opinion more than a fact that small library is better. But even if not, people are free to share their bad work and you are free to pass on it, provide suggestions or patches - but criticizing it is entitled.
BTW it's funny to argue that you should be able to criticize a big library for being too big right under a discussion about dependency version requirement hell. One big library that includes everything would alleviate that pain - perhaps that's what the authors were looking to fix. As I said, this is an opinion, not fact.
Well then which one is it? There’s no middle ground, unless at some point you decide it’s now worth using a big library and start replacing your own code.
If you decide to write everything from scratch, good luck to your users, they’re not getting a better product.
When I add these libraries, I use most parts of them at the end of the day.
However for other one-off things like internal state handling or stuff which I can prop up using the standard library, I refuse to use external libraries.
I kindly disagree on the part of they're not getting a better product. On the contrary. They require to manage less dependencies, most critical parts are well cooked/tested, and other parts are built using the standard library which is built to build these things.
When rolling things forward, I need to juggle less dependencies, too. So things can move forward easier.
It's not like I'm banging the keyboard and shouting done when it prints something meaningful to screen.
unless using a language that supports tree-shaking.
Also, you could also use the same interface (fn-signature etc), or even add a flag for if the lib is installed (in python, try-except over import, with "dummy" module as fallback).
Developers should understand what it actually means to depend on a project. If one needs a fix or a change down the line, it could be that nobody will be there to do it for free, or at all. Therefore one should be ready to either pay or take over the maintenance. And this should be carefully put in balance every time: "Should I add this dependency, or should I write it myself?".
Modern language package managers like cargo amplify this problem by making it almost too easy to add tons of dependencies (and then be pissed at the maintainers who don't want to maintain for free or at all).