

Open Source And Responsibility - felixge
http://felixge.de/2013/03/07/open-source-and-responsibility.html

======
rburhum
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
_something_. examples are:

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

~~~
caseysoftware
As the lead to a pair of open source projects - Web2Project and OpenVBX - I
_sincerely_ appreciate people who keep an eye on the lists/forums and respond
to the basic/101-level questions.

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

~~~
rburhum
As somebody that consumes OS like a maniac, thank you! Next time I am in TX I
will take you up on that offer :)

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

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...](https://plus.google.com/111465598045192916635/posts/CkmmbjmvebM)

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.

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

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

Corollary: are open source authors really responsible for anything? It seems
you are responsible for your usage.

~~~
ChuckMcM
Well, RMS has said that its perfectly okay to pay for the _creation_ of
software. Generally I think its fine but it gets distasteful if the person
paying doesn't want their change/code to be part of the main body of work.
That is the whole 'contribute back' issue.

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

~~~
pixl97
A company I contract for develops a commercial software package for an
industry. They allow to companies to 'buy' their priority development time for
specialized features with the caveat, any feature that is developed is
released in their mainline package. There are no forks, which over time would
become more and more expensive to maintain. As of this time, I can say the
policy has worked well for them.

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

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.

------
jmathai
This is partly why I base the open source software I use primarily on the
project's community first and the technology second.

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

~~~
salvadors
The central promise of Open Source is not that you can get workarounds for
bugs — it's that you are free to fix any bug yourself (or pay someone else
to). Lots of non-free projects have great support too, but when you fall
through those cracks there's nothing you can do about it. Open Source gives
you a much better promise instead.

~~~
jmathai
I agree. The appeal is that your options for workarounds are orders of
magnitude larger than with non open sourced software. You have a multitude of
options...

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

------
pixl97
TL:DR - No one has to fix your problem unless you represent a significant
portion of their income.

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"

~~~
felixge
> What I take from the whole article is the author severely underestimates the
> true cost of software.

I was talking about the "costs of ownership", not the "costs of development".
And I'd like to think I understand both.

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

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.

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

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

------
rwj
Demanding that users are available to provide maintenance and feature
improvement is a recipe for far fewer projects being released.

