Open Source And Responsibility
felixge.de
felixge.de
- I maintain an open window to the IRC channel, lurk, and help when possible ( I can go weeks without doing this, too)
- Contribute a single line patch to fix something minor
- Contribute a 1000+ lines of new functionality when I understand the internals.
- Subscribe to the mailing list and spend 3 seconds everyday scanning through that daily digest titles to see if there is something I can comment on that may be helpful.
- Do a presentation about that technology in conferences/meet ups/hackathons/whatever.
- Sometimes even volunteer to spend a few hours helping with a booth of that project in a local conference.
- Watch the Github repo and comment/help with bug reports submissions
- Submit bug reports
What do I get in return?
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.
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.
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.
Because of efforts like that, I can focus on the deeper or higher level problems or questions that come up.
If you ever find yourself in Austin, TX or at a Twilio event, let me know. I'll happily buy you a tasty beverage as gratitude. :)
The context of Tom Dale's quote is a bug in an open source project that rm -rf'd users' files:
https://plus.google.com/111465598045192916635/posts/Ckmmbjmv...
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, most 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.
I like the wording of the GPL copyright notice:
"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."
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.
Fully agreed. And I actually think that was TJ's intention when he decided to merge a pull request without review, since he was no longer interested in the particular project.
However, Tom is saying: It's better to do nothing than to risk damage. While that would clearly have been better in this case, I disagree with it. If I have a project I can no longer maintain, and somebody cares to submit a pull request, I'll also merge it. Generally speaking it will do more good than harm.
Corollary: are open source authors really responsible for anything? It seems you are responsible for your usage.
I agree that it's presumptuous for people to expect features to be implemented for free just because they want it.
It's pretty scary how toxic some open source communities are in that regard, though, with people going as far as flaming because their feature is not implemented yet.
These days I also ask for money to implement specific features in my projects. Of course, the spirit of open source is still to do it yourself and submit a patch/pull request scratch your own itch) but not everyone can do that.
In my experience with open source I've seen two classes of users:
- people that join the community as developer, show interest in the code, just implement a feature/fix and push the patch
- people that demand a certain feature.
It's the second group I ask money from, obviously not the first. But indeed the first group is worth much more to the project.
It can be particularly touchy around the whole "person Y pays people X to add features you want, send the features upstream in a pull, maintainer declines, customers of Y's product argue that Y is violating the GPL because their features aren't in the product, Y says 'hey they don't want them', then customers start yelling at maintainer to take them, and then maintainer feels bushwhacked."
The implied "problem", that Y's customers are now essentially running on a private fork, not on the maintainers mainline, is no cause to force the maintainer to incorporate the changes. Forking is one of the freedoms in free software.
One problem with maintaining open source projects is that you often don't know how difficult it will become to maintain. I have one project that's reached a level of maturity where there are very few issues with it and no new features I want to add. Another is still in beta, and needs a lot of work before it's ready for a final release. And then there's the hell project, which breaks with every new release of Xcode and takes weeks or even months to fix.
As an open source developer, I do want people to use my stuff and have it fulfill their needs. However, I am only one man, with all the failings that entails.
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.
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.
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.
Please don't downvote me for saying something positive about PHP....:)
- Workarounds are still important and easier since the software is more transparent - The communities are larger so paying someone else is easier - Forks exist for a reason - You could fix it yourself
What I take from the whole article is the author severely underestimates the true cost of software.
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."
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
"I will pay the first person $1000 to fix X and release the code"
I was talking about the "costs of ownership", not the "costs of development". And I'd like to think I understand both.
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.
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).
IME there is woefully insufficient attention paid to the first of these approaches.
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é).
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...)