
Corporations and OSS Do Not Mix - MitjaBezensek
http://www.coglib.com/~icordasc/blog/2015/11/corporations-and-oss-do-not-mix.html
======
toyg
In 15 years, I've read my fair share of "open source developer's lament", and
when the projects mentioned are stuff like Requests or SQLObject I honestly
don't understand. If you step back and try to look at these problems in a
structured way, you can see that it always boil down to the following algo:

1\. Is it a money problem? Then _ask for money_ every time anyone asks for a
piece of you (i.e. bug fixing, event patronage, whatever).

2\. Is is a time problem? Then hire someone. If you can't afford it, it's a
money problem: goto 1.

3\. Is it a skills problem? Then hire someone. If you can't afford it, it's a
money problem: goto 1.

I mean, _requests_ alone is worth hundreds of thousands of dollars a year.
with all due respect to Kenneth and Ian, I find it hard to believe that it
cannot pay one developer salary, even at Californian rates, unless they simply
_cannot be bothered to ask for money_. Stuff like adding a "donate" button on
the page looks _lazy_.

There are tons of ways to get money out of big corporations. Get a rotating-
sponsorship deal where a company pays one salary for one year -- between
Amazon, Google and Twitter (all heavy requests users, I'm sure), you already
have three years of _full-time development_. They get quick bugfixes, you get
a better life, win-win. These companies make _billions_ with your code, I
cannot believe they can't cough up some spare cash. I mean, look at the
OpenBSD Foundation: they asked for some change to pay a month of server time,
and they got _Microsoft_ to dole out huge cash to port OpenSSH to Windows.
_Microsoft_ , FFS!

~~~
_Marak_
We should have Open-Source agents who can represent projects and pitch
corporations for paid sponsorship. The agent gets 10% for closing the deal.

Sounds like an opportunity for a new start-up.

I'd sign up for it.

~~~
eru
That's just a standard software consulting. Lots of clients wouldn't mind you
open sourcing what you worked on for them.

~~~
_Marak_
Not consulting.

It would be having a person pitch a business or groups of businesses to
sponsor an open-source project.

The overhead of communication, negotiation, and writing contracts is outside
the scope of what most open-source developers are willing to do in terms of
time.

Simply put, there is a disconnect between the value of the open-source
software and the availability / willingness of open-source project maintainers
to monetize a project.

~~~
eru
Best of luck!

~~~
_Marak_
Best of luck with what? I'm merely stating an idea here.

~~~
eru
Oh, I was hoping you'd try and implement it.

~~~
_Marak_
I'm in the category of open-source developers who don't have the time or
willingness to start pitching corporations for sponsorships.

------
cortesi
It's worth thinking carefully about what you expect to gain from Open Sourcing
code, before you do it. One of my projects
([https://mitmproxy.org](https://mitmproxy.org)) is pretty widely used
commercially (both as a tool for analysts, and as a back-end component). We
have a vibrant pool of contributors, many of whom use mitmproxy in their day
jobs, but the only financial contribution from a commercial user has been from
Google, and that at arm's length via a GSOC sponsorship.

I would never complain about this, though - we don't solicit financial
contributions, and I didn't start the project expecting to benefit
financially. I get a lot of direct enjoyment out of working on mitmproxy, and
I see it as a way to share something neat with like-minded people. In that
sense, it has been immensely "profitable": I've met and collaborated with many
interesting folks because of mitmproxy.

If you don't feel these indirect benefits make a project worth your while, you
might want to consider doing something else with your time. There's no likely
future in which small open source projects will be deluged with either
contributors or money.

~~~
paulmlewis
Thanks for mitmproxy, used it for the first time the other day :-)

~~~
cortesi
No problem! Hope it was useful.

------
aurelian15
I fully understand the authors frustration. However, as an hobbyist I would
always publish my source code under a strong copyleft license such as the GPL:
The companies that can't live with these conditions are most probably exactly
those you don't want to deal with in the first place. And as the source code
was created as the result of a "hobby", the size of the user base doesn't
matter anyway.

~~~
asgard1024
I upvoted you, and I agree. However, as a professional developer, it is nice
to be able to use OSS at work because you are sure it will always be
available.

Therefore developers who release things under BSD license have a very good
incentive - they want to use the thing they wrote (as a hobby) at work, yet
they want to continue to use it even if they change jobs. I think this is
actually a primary reason why BSD is favored by some developers.

I don't think there is an easy solution to this, at least as long as
"intellectual property" exists. However abolishing IP would be digital
communism and many people are for whatever reason adverse to that idea.

~~~
sitkack
What about the GPL or LGPL prevents you from using it at work? Do you use
Linux?

~~~
j_s
Perhaps your confusion is in the distinction between the literal 'using it at
work' vs. what I interpreted OP's meaning as incorporating a GPL-licensed OSS
project as a dependency of commercial software?

The 'problem' with the GPL is easy: commercial software is often distributed
to end users only as binaries because it is sold closed-source.

The LGPL may be less clear, but there are still problems: LGPL is (was?) not
allowed in iOS apps on the Apple app store, is only intended to be used when
licensing software libraries, corporate lawyers spidey sense tingles as the
license gets into the details of what is a library and linking, etc.

The commercial friendliness of the BSD license vs. [L]GPL seems to be fairly
self-evident; the FSF summarizes it as a 'lax, permissive non-copyleft free
software license'[1].

[1] [http://www.gnu.org/licenses/license-
list.html#FreeBSD](http://www.gnu.org/licenses/license-list.html#FreeBSD)

------
nkurz

      As soon as a bug affects them, they want it fixed 
      immediately. If you don't fix it in 24 hours (because maybe 
      you have a real life or a family or you're sick or any 
      number of other very valid reasons) then the threats start:
    
      "Well if you're not going to take this seriously, we'll   
      have to start using another project."
    

What's the downside to an individual at a corporation for trying to guilt the
maintainer into doing their bidding? If the bug gets fixed, they look good
within their company. If it doesn't, what do they lose?

I'd guess that companies take this approach because on net, the benefits
outweigh the downsides. If guilt can get 1/3 of your bugs fixed promptly and
for free, and if the other 2/3 of the time there are no repercussions, then
guilt is probably a good strategy.

To change this, one either needs to reduce the success rate, or penalize the
request. Judging by the prevalence of spam, you'd have to get the success rate
very, very low before it would curtail "bad" behavior. So what's the
appropriate penalty?

Has anyone tried a "black list" license? Take some standard open source
license, and add "This software may not be used by anyone employed by the
following corporations: [list]. If you are employed by an company on this
list, and use software without specific license, you will personally be held
liable for liquidated damages of $XXXXXX. If you would like have a company
removed from this list, please contact [x] to discuss how we can better align
our interests."

I'm not suggesting that this is the right solution for most (if any) projects,
but consider the "glee" of being able to respond "Great! In fact, I think you
might want to switch to a different project immediately. I've added you to the
blacklist, and while you are allowed to continue using the current version
under terms of the license distributed with it, all future releases and bug
fixes are now off limits."

~~~
x5n1
My response: that will be $10,000-$20,000 please. And no I don't care if you
go use another project.

Or you can also sign up for our enterprise support package for only $2,500/mo
with a 1 year contract minimum we can figure out a way to get that bug fixed
asap.

Ultimately it's all a question of money, if you are not getting enough to
provide the kind of service they demand. DEMAND MORE!

And don't give a shit about the manager trying to manage you. They don't pay
you, you owe them nothing.

Don't be afraid to say no. Free software is free because they should pay you
to either provide support or fix problems when they pay for them to be fixed.
You be a good little capitalist and let them get up the creek without a paddle
and then charge them an arm and a leg to get back down. If they don't like it,
they can figure out some other way to solve their problems.

~~~
p4wnc6
Or tell them to fork the project and fix it themselves. Perhaps we should
popularize something like "go fork yourself" as a valid response?

~~~
x5n1
brilliant.

------
jaggederest
I think Mike Perham does a great job of leveraging his open source project
into direct contributions.

[http://sidekiq.org/](http://sidekiq.org/)

Sometimes if you respond to 'we need feature x, y, and z.' with an upsell,
they actually will give you money.

~~~
sytse
We at GitLab love the open core business model too, it is a hard balance but
it can lead to having the money to make the open source project much better.

------
ef4
Building a healthy community doesn't just happen by accident.

Too many open source devs put almost no thought into the cultural aspects of
building a community that is (1) not full of jerks, and (2) able to attract
meaningful support from the businesses that use the code.

Those things can be done, if you try, especially if you start early in the
life of the project.

~~~
vinceguidry
Devs aren't supermen. A lot of people get into open source because that's the
way they feel they can best do something good for the world, to put their
software development talents at work.

Asking them to now go and develop a new set of skills, political savvy, that
aren't just not in the same ballpark as dev, but not even in the same sport,
they're going to just throw up their hands and walk away from OSS.

When firms have talented but politically-averse individual contributors, they
give them managers so as to best direct those talents. OSS needs to stop
expecting themselves to do everything and get some bosses to shoulder some of
the burden.

~~~
edgyswingset
What I think you're hinting at is that OSS shouldn't just be for the
developers. People who are good at curating a community but don't write a line
of code are super valuable. They should be seeking out OSS projects (and OSS
project owners should be seeking them out).

~~~
gamesbrainiac
I have to disagree with that. If you don't write a line of code, how are you
supposed to actually understand what's going on? OSS projects are not simple
Hello World applications here.

~~~
edgyswingset
> how are you supposed to actually understand what's going on?

By talking with developers of the project! All it takes is a few conversations
to get an idea about the why/what/when/ about a project and understand enough
of its internals to be able to articulate those same things to others.

Numerous other things can be done by people who don't write the actual code:

* Writing a great "Getting Started" guide

* Writing great conceptual documentation

* Acting as a community moderator and squashing vitriol

* Acting as a contact for companies needing work done on the project

* Keeping things like Github Issues fully tagged, organized, and traced back to from Pull Requests

That's just off the top of my head. There are likely many more things that an
OSS project would value which someone who isn't writing code can do.

------
probablyfiction
"...the company wanted to invest as little time in the problem as possible so
the person couldn't fix the tests, write new ones, or write a real fix. I
don't blame the engineer, I blame their manager and their company."

This is spot on. Managers of software teams (and their bosses, all the way up
to CTOs and CEOs) need to allow their engineers to contribute fixes to OSS
with the understanding that it helps the community. There's also the added
benefit of helping the business to develop a positive image in the OSS
community.

This obviously is not always possible, and in some organizations it is never
going to be possible. However, there are teams out there that do have the
freedom and flexibility to give back to the community.

If enough teams begin contributing bug fixes to projects they find helpful,
eventually this pervasive attitude the author writes about will change.

On a separate note, the author needs to stand up for himself more. A
boilerplate e-mail with his hourly rate wouldn't take long to put together. If
an issue is important enough to a company to bombard him with support
requests, it's likely worth it to them to pay for a fix.

~~~
cwyers
> Managers of software teams (and their bosses, all the way up to CTOs and
> CEOs) need to allow their engineers to contribute fixes to OSS with the
> understanding that it helps the community.

They NEED to? Or what? I _need_ to drink water. If I don't, I die. What
creates this need to allow engineers to help the community?

~~~
johncolanduoni
As with drinking water, you need to have a goal (e.g. surviving) to say need.
I suspect GP was saying that they need to do that to have a non-parasitical
relationship with open source projects they use.

~~~
cwyers
I mean, parasites get to sit around in the host and have a free lunch. You
don't cure malaria by yelling at a bunch of Plasmodium falciparum about how
they should be ashamed of themselves.

------
merb
However you forgotten something.

Not all companies are big and not all have the time (even in free time) to
help your project.

I know there are lots of companies who actually use your software and doing
nothing.

However there are also lot's of small companies who started or started within
1-5 years and employ 1-5 people. Those actually need your libraries most but
can't give too much back. Actually their time is lacking while they built
their product. (I would like to contribute to a project but can't due to my
restricted time. Currently we are 3 people and I'm teaching one, currently I
hoped that he would share more of his free time in the open source world, but
I don't believe he ever will..)

Also I know your library and I used it and I know that you've got a high
quality of standard and that's the second thing you forgotten. Younger people
don't like to take the bigger issue's, they are just not confident. As I am in
the projects I would like to fix a Bug I'm just too scary to make a bigger
contribution. It's mostly the lack of my experience. Especially when it comes
to testing. Nobody ever learned that to me, so I was and I am on my own by
dealing with it.

What I also thought and why I'm doing it is raising issue's (hopefully not
duplicating it) when a project has an issue. I'm also fixing Typo's if I find
some. I didn't thought how much work it is for a small project. I thought I
could get 'something' back which is better than nothing. However I was never
one of those guys who stopped responding.

I also tried to fix some minor things in Django however somehow I got lost and
had no time on those and our project moved away from Django which wasn't
caused by Django more caused by the fact with our Python expertise.

Btw. I started to read HN afterwards so I was a complete 'noob' at the
beginning of my career. And as I've read through your blogs I will certainly
try to offer more time at projects my company is using and I'm also willing to
share my thoughts on the company if we grow. At the moment we needing to
handle our stuff, not enough money, not enough developers, not enough time.

~~~
gaius
LOL startups can afford swanky offices and free massages and all the rest but
can't afford to pay for software? I call shenanigans.

~~~
anon1385
There is a world outside of SV you know.

------
snambi
I think all FOSS projects need a support model. State the situation explicitly
on the website of the project.

1\. How many are working on?

2\. If a patch is requested what is the SLA of that getting merged. It should
be based on the bandwidth available to the maintainers.

3\. Provide "priority" support. It can involve money, resources, anything
actually. It is better to call out, how someone can get "priority" help. In
case of money, provide hourly rate for different priorities.

4\. Offer a chance to for 3rd party developers to "charge" a company and
provide a "quality" fix for the project. The money may be shared between the
committers and 3rd party developers, based on some pre-defined contract.

There are several open source projects that have "paid" support. So, this is
not new. But it does require, thinking from the angle of money.

------
imron
> I've also never demanded this. It would be nice, but it never happens

Perhaps you should start asking then.

~~~
PhasmaFelis
Yeah, I'm baffled as to why he wouldn't.

------
unabst
Author is in a far better position than most projects, since he 1) already has
companies using his software and 2) has folks from those companies contacting
him directly for help.

Corporations are in the business of making money which also puts them in the
business of spending money. They pay for office space, things to put in the
office, people, services, insurance, and software. They pay for everything.
There are hardly any things they don't pay for!

So as long as the math makes sense and the transaction is presented properly,
they are happy to shake hands and pay for your services. In fact, they want to
pay you to make problems go away. Red Hat is worth billions for executing this
at the corporate scale. Free software is just the hook. Corporations that can
pay for software now have money to spend on other services. This realization
is what made Red Hat.

The only thing you need to know when freelancing is that if they walk away,
they were never shopping to begin with. They were just gaming you. Everyone
knows labor isn't free. So if they really need your help they'll pay. And
they'll expect market rates, so charge them market rates.

------
j_s
Thanks Ian for all your hard work!

Ian's projects are what they are today because of what he has invested in
them, without any guarantee of reward. The work that he has done will remain
even now that his willingness to maintain these projects 'for free' has waned.

It is the open source developer's responsibility to fight for their own
OSS/life balance, and it is good to see Ian taking this step to stand up for
himself. Hopefully Ian's transition away from his own self-admitted naïveté
will go smoothly -- these projects will continue even when he chooses to
ignore destructive input and/or give an outright 'no' (or 'not right now')
when necessary. Ian and other OSS maintainers do well to take a few pages from
the lean startup customer support desk handbook: creating email templates,
personal developer/contributor FAQs, etc. No doubt this blog post will serve
its part as something Ian and others can point corporate developers to as a
not-so-subtle hint in the future!

In my own very limited (and far less impressive) experience, I have found
maintaining a list of alternative projects to be very helpful. Then, when
someone brings an urgent need to my attention, I can point them to the list so
they can solve their problem without me. One such conversation went like this:

    
    
      >
      > Hi ______,
      >
      > I will not be able to resolve these issues in what it sounds 
      > like is the timeframe you need.
      >
      > My recommendation would be that you install the trial version 
      > of a tool on the list of commercial alternatives: [url]
      >
      > One that I have very limited experience with is [url]. The page
      > also lists all of the free tools that I am aware of.
      >
      > Thanks for reporting these problems; I will create issues to 
      > track the progress of resolving them.
      >
    

Edit: PS. Hopefully Ian will invest some time in sharing some of the details
of his positive experiences in OSS, perhaps even in interactions with the
corporate world. In addition to what not to do, examples of what has worked
well could make it easier for others to request more of the same! This
discussion seems to serve both sides of this coin as well.

------
lifeisstillgood
I have mulled over two "financial innovations" that are worth mentioning here.

1\. OSS Development bonds 2\. OSS draw down financing

1\. Is most practical here, being the idea that one can build a Kickstarter
like infrastructure to escrow payment to develop new features on a project.
This seems the closest to the OP's problem - he wants to get paid to work on
his projects. As they are really high usage projects then I suspect this is
doable. What most corporations miss is a culture where this is permissible.
Probably because it would effectively end their in house developer system

2\. I want to spend the next ten years writing really good OSS software that
solves and provides government services (land registry, elections etc - see
[http://oss4gov.org/manifesto](http://oss4gov.org/manifesto))

But right now most software purchased for use by the government is license
based - that is the assumption (and RFPs and timescales) screams "you have
already built this".

Seed money will help, but perhaps more helpful would be the ability to have
say the first government delartment or local authority pay, and then build a
finance product that gives the developer 10x to go build it. If another govt
wants the software it pays a development fee, and that fee is routed to the
original funder. This continues.

~~~
sitkack
Your manifesto is down

~~~
lifeisstillgood
Thanks will go fix

------
skybrian
Why is it surprising when companies contribute patches mostly to fix issues
they care about? Isn't scratching your own itch what you're supposed to do?

------
rogeryu
He can only blame himself. He should explain his situation, and ask for a
reasonable amount to fix bugs or implement requests. And reasonable is not
minimal wage, it's proper payment for the work he does. If the user doesn't
like it, then they can ask someone else to fix it.

~~~
s73v3r
Why the hell would he blame himself for users making asinine demands? Are the
users not adults? Are the users not fully capable of taking responsibility for
their actions?

~~~
nickpsecurity
He can blame himself for worrying about it and wasting time on a huge writeup.
Instead, he should offer to help for reasonable pay, have stock responses for
rejections to prevent wasted time, and otherwise dont worry about the fact
that companies are mostly selfish. That's life.

Just enjoy building and letting people use your app. Fuck the rest.

------
DonaldFisk
Corporations are run to benefit their shareholders, not open source developers
or society at large. If they can get away with using your software for free,
as per licence, contributing nothing back, and adding insult to injury by
demanding any bugs they find are fixed PDQ or else, that's what they'll do.

It would be better if new commercially useful projects are released on a
shared source licence, allowing free non-commercial use but requiring payment
for commercial use. That way, their developers get remunerated for their work,
and hobbyists still get to use the software for free.

~~~
ant6n
So like a GPL/commercial dual license?

~~~
DonaldFisk
No, because that would allow companies to use the software for free if they
choose the GPL licensing terms.

------
detaro
Sadly not surprised to read this...

Some thoughts:

Some projects that have active companies behind them clearly offer development
work/support contracts that include modifications (Maybe "support" is easier
to bill in an enterprise than external dev work?).

Is there potential for something similar for less cathedral-style projects?
like a list with "the following developers have contributed to/a lot of
experience using this project and are available for hire"?

------
jlarocco
I have zero sympathy for people in this situation, because it's their own
fault for being in it. The solution is super simple: Stop working for free
like an idiot.

If a company won't pay you to work on what they want, tell them you'll get to
it when you get to it. If they have a problem with that, tell them to pound
sand.

Further, releasing a bunch of stuff as open source, and then complaining that
nobody contributes back, or doesn't contribute enough, or only contributes
because they personally benefit, is a little ridiculous. Nobody forced you to
give away a bunch of work for free, so don't make it sound like you're some
kind of martyr.

~~~
vetinari
While your general idea is correct, the way you communicate it is needlessly
rude and contrarian.

The better way would be to answer, that yes, surely you will help, but there
doesn't seem to be a valid M&S contract in force and that you will gladly
discuss specifics with them, if they are interested.

See? That's the talk the managers understand, they don't work for free either.
So it is either an important thing they need to fix and will work with you, or
it is not and in that case you will not waste your time. The simple thing is,
that you need to recognize when they exert pressure on you and then simply
mind your own interests.

~~~
jlarocco
Re-reading what I wrote, it's pretty clear I didn't recommend being rude until
after they've declined to pay.

It seems obvious not to be rude right off the bat in such a situation, so
there didn't seem to be a point mentioning it. I think most people understand
not to be rude to potential customers.

> See? ...

There's no need to be condescending about it.

------
rch
I like the idea of having to subscribe to get the latest source, be it dev,
unstable, or whatever.

------
geggam
If everyone who used OpenSSH donated 1 dollar to OpenSSH.... well you get the
idea.

