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

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.

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

Sure. But money isn't the only currency. "Thanks!" is a really good start. It makes my day when someone says thanks for something I've done. Beyond that, actually contributing a little bit here or there, where possible, is really appreciated too.

> In five seconds since posting this I have thought of at least six projects omitted above.

I think your misconstruing the point. Indeed most of the projects you listed can hardly be considered crucial or core technologies :)

I think the main point here is if you take a core code base, say Lamson (seeing as Zed is the source of this whole debate :D) and built a popular enterprise mail server/client (say something like Kerio Mail Server) out of it. Is it not "good form" to perhaps put some obvious credit "built with the cool lamson". Or perhaps offer Zed a bit of cash to iron some bugs you found. Or farm back bug fixes into the Lamson source. 90% of companies probaboly wont bother - and they should, right? :)

I also think you assuming the idea is distribute cash according ot some scheme or other. As I see it the point is that it would be "nice" if more companies considered it good form to show appreciation for the core technologies that make their businesses tick :) (in whatever form they can afford / deem appropriate).

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.

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.

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.

You sum up two points of view:

* Make them share stuff (GPL)

* Be permissive, and aim for a bigger community - companies can participate and still use the stuff for proprietary code of their own. (BSD/Apache).

> it is my personal belief that in practice this theory does not hold.

Do you have any evidence either way? Both are valid points and have been show to 'work' in some way. Apache has lots of companies that participate, which is a counterpoint to your theory. On the other hand, maybe individuals are less likely to participate in efforts seen to benefit Big Companies?

I suspect there are no certain answers.

You're right, there are no certain answers. In fact, sometimes it seems that community and company participation is kind of arbitrary. It is because of that uncertainty that I believe in the GPL. The GPL licsenses provide legal incentive and wont stop any altruistic individuals from contributing as well. As for companies, you'll see from my example below that license may not actually matter at all.

If you look at some of the more prominant examples, getting companies to contribute actually doesn't have anything to do with the license, and everything to do with popularity. nVidia provides both 32 bit and 64 bit blobs for Linux, but only a 32 bit blob for FreeBSD. This is only because Linux is widespread, and the blobs are neither GPLed or under a BSD license.

I'm talking more about "library" style code. BSD means companies can integrate it, and potentially contribute back. And this does happen. GPL may mean they simply do not use it, and thus the project loses out on potential contributions.

Despite BSD's large head start, Linux has received substantially more contributed work. This is evidence that "this is useful, let's follow the license" tends to outweigh "this is scary, let's avoid the project".

Linux is not, by and large, used as a library that people link to. It is, outside of embedded work, more or less a "stand alone" application. You can base proprietary stuff all you want without getting mixed up in the GPL - it's only if you compile it in that you have problems, and that's only the embedded market that cares about that.

I'm not a zealot either way, I'm simply saying that if you have a library that people cannot use in their stuff that is proprietary, then they won't use it, and will never contribute anything back.

Once again: the key point is "library", not Linux vs BSD kernels, where you're right that people are happily using Linux despite the more restrictive license.

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.

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

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.

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.

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

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.

I wish I could upvote you 100 times for mentioning that book. Probably one of the most informative books I've ever read, and it's only ~200 pages.

Seriously folks, get a copy and read it. It'll make a huge impact on your perspective of other people.

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

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

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_...) which would probably make an interesting conversation thread in itself.

Companies are persons of law, not moral persons.

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