In my experience, I rely heavily on what I consider "Open Source Karma". There are a handful of projects that I use very frequently and my entire (geospatial) industry relies on. For every single one of those, I contribute <i>something</i>. examples are:<p>- I maintain an open window to the IRC channel, lurk, and help when possible ( I can go weeks without doing this, too)<p>- Contribute a single line patch to fix something minor<p>- Contribute a 1000+ lines of new functionality when I understand the internals.<p>- Subscribe to the mailing list and spend 3 <i>seconds</i> everyday scanning through that daily digest titles to see if there is something I can comment on that may be helpful.<p>- Do a presentation about that technology in conferences/meet ups/hackathons/whatever.<p>- Sometimes even volunteer to spend a few hours helping with a booth of that project in a local conference.<p>- Watch the Github repo and comment/help with bug reports submissions<p>- Submit bug reports<p>What do I get in return?<p>Putting aside the amazing conversations I have with people far smarter than I and the unusual/rewarding friendships/connections I have made, my Open Source Karma there is off the hook. I get a level of support that cannot be bought. It is the difference between intrinsic/extrinsic motivators.<p>In the past, I have run into issues that I have been trying to solve myself for days. Then I just went over to IRC to ask for help and in less than 10 minutes I had a patch with a fix/workaround from one of the core maintainers who personally debugged my problem and fixed it. There is no typical commercial paid support package that will get you that.<p>This is exactly why the project health of an open source component is measured in community size/involvement. If you do something minor to give back, you will get your bug fixed because there are real people behind those projects. Meanwhile, the douchebag that demands his bug gets fixed because there is some "implied responsibility to support your package because you are the father of that project" will get ignored.
People who feel entitled to have features implemented for them are wrong (and I agree with the OP about being a "responsible consumer"), but I can't agree with the OP when he says that Tom Dale (the guy who said "open source is a responsibility") is wrong.<p>The context of Tom Dale's quote is a bug in an open source project that rm -rf'd users' files:<p><a href="https://plus.google.com/111465598045192916635/posts/CkmmbjmvebM" rel="nofollow">https://plus.google.com/111465598045192916635/posts/Ckmmbjmv...</a><p>Does the OP really think open source maintainers don't have a responsibility to try to prevent that? He talks about the warranty clause in open source licenses, but the warranty clause is legalese and it's a far cry from how open source really works. In reality, <i>most</i> open source maintainers take pride in their work and try to avoid causing harm even though the warranty clause would technically let them get away with it.<p>I like the wording of the GPL copyright notice:<p>"This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."<p>I think that captures the spirit of open source much better: legally we have no responsibility, but we're still going to try to make it useful.
Question for the community: How do people feel about open source projects asking for payment for features? It seems to me that is could be a reasonable request. It seems presumptuous to ask a random person on the internet to do work for you and entirely reasonable to request to paid for that work.<p>Corollary: are open source authors really responsible for anything? It seems you are responsible for your usage.
Relying on software is always a bit iffy. Be that open source or proprietary software. At best one can off load some on contractual agreements, be that social ones like Debian stable or an paper contracts written and paid with a support company.<p>However, smart consumers can improve for themselves by choosing more or less future proof software, and this by looking at the project and the project group. Things like community driven, historical stable, and a continuous flow of updates is to me shinning traits of a long term project that one can depend on.<p>As a side note, I would like to add that people seems more prone to demand features and bug fixes from open source projects than they would out of proprietary software. This is almost exclusive psychological reasons, as people who spend money (initial investment) on something get motivated to not see any fault in the product. Other problems is anchoring that free of charge introduce.
This is partly why I base the open source software I use primarily on the project's community first and the technology second.<p>jQuery and PHP are good examples of software which might not be the "best", technically. However their community is rock solid and you can get support or find workarounds to bugs (which might not be fixed soon) pretty easily.<p>Please don't downvote me for saying something positive about PHP....:)
TL:DR - No one has to fix your problem unless you represent a significant portion of their income.<p>What I take from the whole article is the author severely underestimates the true cost of software.<p>FTA: "And while it's not pleasant, this approach has led me to realize, that in some cases, I simply couldn't afford certain software, even so it was offered to me at no charge."<p>This is all software, open source or not, unless you are paying for the direct development of it. There is plenty of closed source programs that I've seen companies tied up in that the manufacture quit supporting or wouldn't fix that cost tens of thousands of dollars in migration fees. The one benefit of open vs closed is that with open you have the option of posting<p>"I will pay the first person $1000 to fix X and release the code"
Assuming that a "proper" Open Source project is one with an active community and commitments to long term development and growth etc., is detrimental to simply getting code out there that people can use. There's often an assumption that even if you're releasing code under a Free/Open license you must want to almost run it like a startup, paying close attention to the needs of your "customers" etc.<p>But there's a whole other side, where you simply take code you're probably never going to do anything more with ever again, but rather than just letting it die, you set it free for other people to do something with it if they like.<p>One of the core Freedoms is the freedom to adapt existing code in whatever way you like. If something I've written can have some of its innards repurposed into something someone else needs, and save them a day or two of development in the meantime, then that's every bit as valid as if I create a black-box library that tens of thousands of people use (and expect new features from on an ongoing basis).<p>IME there is woefully insufficient attention paid to the first of these approaches.
I probably fall in the category of those that think that authors of open source projects do have a responsibility for the code they share and its maintenance.<p>The main reason I'm saying this is that I feel that the open source world is not an infinite dump area where everyone just throws out code of any quality (in many cases just for having something to add on the 2nd page of a résumé).<p>This is not to say that authors are required to implement additional features or support a piece of code forever. But trying to deliver as much as the original "promise" of the project and making it clear what's the status of the project is the responsibility of the author. Browse GitHub and tell me how many projects are marked as "defunct" or "abandoned" or "unmaintained". (maybe Github should automatically do this...)