

Ask HN RE:  Company's responsibilities to the open source community - iamelgringo

Zed's rant prompted a strong response from the HN community, but I feel the discussion really got derailed onto Zed's personality instead of the larger issues that Zed brought up.  I'd love to hear HN weigh in on those issues.<p>What are a startup's ethical responsibilities to the open source community if your startup is based on an open source stack?  I'd imagine that there's hundred's if not thousands of startups in the world that are writing great software.  I think Zed has a point:  Why aren't they open sourcing more of it?<p>Zed's also written several posts about how startups that have used his software extensively haven't reciprocated in terms of offering contract work.  Zed's persona aside, do other open source devs have this problem?<p>And another question I'd love to hear people weigh in on is this:  When a startup exits, should they contribute financially to the open source devs that helped them build that startup?
======
patio11
_What are a startup's ethical responsibilities to the open source community if
your startup is based on an open source stack?_

I'm going to go with "None whatsoever".

 _I think Zed has a point: Why aren't they open sourcing more of it?_

Isn't this "Why aren't you releasing code with a license more conducive to
meeting my needs?", just coming from the other end of the table?

 _When a startup exits, should they contribute financially to the open source
devs that helped them build that startup?_

A copy of my software costs $30. It would not be possible without the support
of: Nginx, Firefox, Firebug, YSlow, Ruby, Rails, Prawn, Java, the Apache
Commons HTTPClient library, Google Charts, the Ruby Google Chart API wrapper,
Wordpress, six wordpress Plugins, Netbeans, Eclipse, Ubuntu, the whole Linux
toolchain, launch4j, JarBuilder, the hominid gem, InnoSetup, and the guy
listed in the credits who wrote the font selection dialog whose name I can
never remember but who licensed it under the condition that I put his name in
the credits.

[Edit: In five seconds since posting this I have thought of at least six
projects omitted above. Do I need to remind people that I sell a freaking
_bingo card maker_? A full accounting would sound like I, Pencil: 2009
edition, and if I had to do it for a more technically involved project my head
would explode.]

Do you have a sane scheme for identifying a fair way to distribute $30, or $3
million, between all of the individuals and corporations who cooperated in the
release of the above? If you do, your scheme left someone out. By what basis
have you decided that their contribution is morally less important than those
of the people who you included?

If you want to get money from the people who use your software, charge the
people who use your software money.

~~~
daleharvey
I think you are mixing up ethical responsibilities with legal ones.

I dont think its plausible to tie in a bunch of red tape around open source
that makes attribution / repayment a legal obligation, but I do believe in
karma (in a practical sense, not mythical)

If I heavily benefit from open source, while I dont have any legal obligations
to do anything about it, I believe the right thing to do is to contribute back
to the community, upstream patches, new tools, promoting it etc etc.

------
cperciva
Ethical responsibilities? None.

But that doesn't mean that you shouldn't open source any of your code.
Spending time on things which are not your core functionality is bad -- this
is why services like AWS are so popular. All of those open source libraries
which you're using? They're not your core functionality -- so it's better for
you to contribute your changes/improvements back so that someone else can
maintain them rather than spending time on that yourself.

Tarsnap is built around the excellent bsdtar tar archiver and libarchive
archive-handling library written by Tim Kientzle; whenever I write code for
tarsnap which could conceivably be useful in bsdtar or libarchive (bug fixes,
SIGINFO handling, reworking of internal buffering, etc) I contribute it back
_because it reduces the amount of work I need to do merging changes when I
update to a new version of libarchive in the future_.

Of course, this argument doesn't apply if the open source code you're using
_is_ your core functionality -- but at that point, you've got bigger problems
to tackle than figuring out whether you should contribute code back.

~~~
tsally
In this post, whenever I use GPL I am using it to refer to the class of
licenses (AGPL, LGPL, and GPL proper), not the specific license.

Remember that Colin is FreeBSD's security officer, so it's probably pretty
obvious which camp of open source thinking he falls into. :-) I'll do my best
to present the other way of thinking within the open source community. I
recognize the FreeBSD school of thought and don't have a problem with it, I
just think there is a better way.

Let's use Colin's example and say you find and fix a bug in an open source
library you are using. It is at that point I believe you have an _ethical_
responsibility to contribute back. You found a bug and you should share the
fix with everyone. Hell, the library probably wouldn't even be in a usable
state if people didn't contribute patches. Patching back is what keeps the
open source ecosystem flowing, and if you can encourage it though a license
it's probably a good idea

Now, people of the FreeBSD camp believe that people will usually contribute
patches on their own accord. This might be true for open source hackers, but I
can tell you that it is not true at large companies (not sure about the
startup scene). The GPL camp believes it is better to have stronger language
to encourage people to contribute back.

Even with the GPL, if you are modifiying code for your own use, you can do
whatever you want. It is only when you use GPLed code to run a service or to
provide a product that you have to make your patches availible under the GPL.
It's simple really. If you attempt to profit or use the code in any way other
than for personal reasons, the GPL kicks in.

Let's examin a running theory in the OpenBSD community. Theo thinks that the
GPL is a poor choice because companies are scared of it. They are afraid to
get involved with the GPL because it is a viral license, and thus will not
contribute code back. He contends that to achieve their main goal of security,
they need a more permissive license so companies will patch back. Theo may be
right, but it is my personal belief that in practice this theory does not
hold. I contend that any company with a useful patch will want to hold on to
it, no matter what. Useful patches for OpenSSH represent a competitive
advantage that other companies do not have. If I ran a company purely for
profit, I would keep all my patches under wraps, regardless of license. It is
for that reason that I believe the GPL style licenses are a better choice.

~~~
cperciva
_Useful patches for OpenSSH represent a competitive advantage that other
companies do not have._

True. However, they also result in additional costs -- you may have to rewrite
your patches when new versions of OpenSSH are released, you will have
additional system administration costs (you won't be able to use precompiled
OpenSSH binaries), and you may have additional training costs (it's easy to
find a sysadmin who knows how to use OpenSSH; not so easy to find someone who
knows how to use OpenSSH-plus-your-local-patches).

Even worse, there's a risk -- and I've seen this happen to many companies --
that whoever wrote your patches originally will leave the company, and you'll
be stuck wanting to update to a newer OpenSSH but without the expertise needed
to merge your patches.

I'm not saying that it's _always_ to your advantage to contribute patches back
-- but I think in most cases the costs of keeping your own patches outweigh
any competitive advantage they may give you.

~~~
tsally
Good point, I had never thought about it quite that in depth before. However,
I am still willing to contend that large companies who can afford the staff do
(or should) have large internal patch sets for OpenSSH, FreeBSD, etc. You can
be sure the NSA does. ;-)

~~~
cperciva
_I am still willing to contend that large companies who can afford the staff
do (or should) have large internal patch sets for OpenSSH, FreeBSD, etc._

This absolutely happens -- I know of lots of companies which do this, for a
wide variety of reasons.

Some companies have local patches which aren't contributed back because they
simply aren't relevant to the community at large; for example, I know of one
large FreeBSD-using company which at one point had if (strcmp(fname, "mysql"))
{ /* Handle mysql processes specially */ ... } blocks in their kernel.

Other companies have local patches simply because they're not sure exactly how
to go about contributing changes back -- either due to a lack of knowledge
about open source in general, or because they started with a source tree and
started hacking, and aren't sure exactly what they've changed. I've seen job
postings with "get the changes we've been making locally for the past five
years into the FreeBSD tree" high on the list of job responsibilities.

And then, of course, you're right that there are some companies which have
changes which they could contribute back, but choose not to. But based on the
companies I've talked to (which, admittedly, is a biassed sample), this
doesn't seem to be a very common scenario.

------
davidw
Great question. Don't have much time for an answer, but I think a lot depends
on how critical the software is to the company in question. Another user of
Apache? Probably don't need to do much, just put a "thanks" link somewhere on
your site. Took some BSD licensed code, closed it up, added something to it,
and based your business on it? Morally, I think you owe something, even if you
don't, legally.

What really bugs me as an open source guy is when people don't even attempt to
participate in the community in even minimal ways. I can understand if you
don't want to hang out answering questions on the mailing list, but if you
find a bug and don't even bother to tell me so that I can fix it (for free,
for #####'s sake!), that's just lame.

But that's a really quick treatment of a very interesting question - I look
forward to seeing other responses.

~~~
mechanical_fish
* if you find a bug and don't even bother to tell me so that I can fix it (for free, for #####'s sake!), that's just lame.*

You need to read Cialdini's _Influence: The Psychology of Persuasion_ :

<http://en.wikipedia.org/wiki/Robert_Cialdini>

That will get you in the mindset to understand what is going on here.

People are shy about reporting bugs in your free software because they --
perhaps correctly -- sense that to ask you to fix a bug is to subtly demand a
favor from you. And they don't want to demand favors from you. Perhaps because
they got your work for free, and it feels like being a jerk to take someone's
free work and then demand more. Or perhaps just because asking you to do a
favor for them will make them feel socially obligated to reciprocate, but they
don't know how that's going to work. They can't just give you money, because
you aren't asking for it. What are you going to ask for? Are you going to ask
for something they don't have -- like time -- or something they don't want to
give you, like a signature on a petition that they don't agree with, or the
license to some software that they really wanted to hang on to? Perhaps you
will ask them to buy some Amway products, or some life insurance, or a
timeshare, or an entire box of candy bars for your kid's fund drive. Don't
think that this sort of thing doesn't happen.

When people offer me free stuff as I walk down the street I usually decline.
I've learned better. I believe it was Cialdini who described the classic Hari
Krishna trick of starting conversations on the street by giving people tiny
flowers. Once you've been given a tiny gift the part of your brain that
calculates social debt starts ticking, whether you want it to or not, and
you'll find yourself feeling guilty if you just walk away. A lot of terrible
products have been sold this way.

Indeed, even if you tell people over and over that providing a bug report is
_doing you a favor_ , they will _still_ think of it as a demand on you.
Because if I walk up to you and do you a favor I am creating a subtle
expectation that you will reciprocate.

This is why charging money for your software -- even a dollar -- creates a
magical change in your customer relations. Suddenly customers understand the
rules: You do things for them, they reciprocate with money, and it's all
square! Suddenly customers will start calling you up and reporting bugs --
they _paid_ for your bug-fixing efforts! They'll report a _thousand_ bugs --
hey, look at the value they're getting for their dollar! Of course, the
terrible flip side is that, once they've paid you a dollar and then cheerfully
reported a thousand bugs, your _own_ reciprocity calculator might start to
ping, whether you want it to or not. You may begin to resent those bug reports
-- the very ones that you are currently begging for -- because you were only
paid a lousy _dollar_ for the work of accepting them all. Watch it happen.

~~~
davidw
Dan Ariely comes to a similar conclusion in "Predictably Irrational":

"“FREE!” has a striking effect on people, causing them to make irrational
decisions."

> This is why charging money for your software -- even a dollar -- creates a
> magical change in your customer relations.

Sure, but that changes things in other ways too... we were talking about open
source software and how to be a good citizen in that community.

------
ErrantX
> When a startup exits, should they contribute financially to the open source
> devs that helped them build that startup?

I dont think there is an argument for Open Source licenses to include a caveat
like that. But I do think it should be considered as "good form".

Perhaps not money - but as I commented on the Zed Shaw thread something saying
"we used X, it's awesome check it out". Because the whole point is if it was
useful to them it is useful to others!

I think more serious recognition is nice too (look at Google hiring Python's
BDFL. Or Facebook open sourcing portions of it's "support structure" code
base) but shouldnt be required.

------
figital
\---"I wrote Mongrel and then gave it away, on the hopes that it would help a
bunch of other people, and that giving it away would come back to me in some
way. Maybe a job, or some respect, or hell maybe my own company doing more
software like it."---

I'd agree with "none whatsoever" ... I'm sure he has plenty of respect ... but
to take advantage of that respect you still have to go out and market/network
yourself to take advantage (or have someone help you do so if that's not your
thing). I'm sure it looks great on a resume.

------
Edinburger
It's hard to answer this without first answering the more general question of
what we believe about business ethics
([http://en.wikipedia.org/wiki/Business_ethics#Ethical_issues_...](http://en.wikipedia.org/wiki/Business_ethics#Ethical_issues_and_approaches))
which would probably make an interesting conversation thread in itself.

------
phugoid
Companies are persons of law, not moral persons.

------
access_denied
You don't do a morning prayer to the holy Edison just because your alarm clock
woke you up. Clearly I don't think there is a requirement to give back. It is
just utterly stupid not to give back. If you don't nuture the community that
feeds you, you just show short-sightedness (and that's bad for you).

