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!
You clearly haven't tried raising money for an Open Source project. It's really really difficult and the amounts of money you get range a lot. Usually you also want to underpromise and overdeliver, so it's about raising 10-20k USD to deliver a project that will take three to six months of full time work to deliver, ADDITIONALLY to fixing bugs, maintaining infrastructure and doing things for which you can't possible raise money at any rate. Contact me privately I can share more of the details, but it sounds like you're quite detached from the open source reality.
PS. We work on PyPy and cffi
Working in the enterprise/financial world, I can tell you that boatloads of cash get wasted on the most absurd items, so there must be ways to funnel some of this to the right places. Even VC-backed "lean" startups would/should rate publicity "in the right places" more than a lot of other things, let alone direct benefits from actual productivity gains. For example, I often don't know whom awesome_oss_developer works for; if I did, I would be inclined to rate their products and services way higher, and would probably want to work for them more. Every single OSS release from major projects should carry a sponsor highlighted in README and release notes. Advertising somehow pays for billion-dollar companies in the real world, but the same companies don't rate it enough to sustain their own infrastructure?
I'm not doubting that reality is dire, what I'm doubting is the effort placed on changing it. There are many elements of the engineering culture dominant in OSS that are just not right from a commercial perspective and could/should be fixed with brutal honesty.
And then there's Andrew Godwin raising £17,952 to work on Schema Migrations in Django https://www.kickstarter.com/projects/andrewgodwin/schema-mig...
Asking for money for open source software does work.
For much of it, if we find a bug, we either fix it ourselves locally, or go through the normal process of submitting a bug report, possibly submitting our own patch, and waiting for a fix from upstream, while finding some way to work around it or the like.
For some of the software that is central to our business, we have a contract with a company that provides support and development services. If we have a bug that we need fixed right now, we get in touch with them and pay an agreed upon rate to do so.
We don't do this for everything we use, because most of it works off the shelf, or we just replace it or work around it, or the open development process works well enough. But for those things that are absolutely key to our business, and for which there's a consulting company that employs several of the core developers on the project, it's definitely worth it to pay for the support that we need.
Not only that, but from my own experience, relatively few people (as a percentage of total users) will ever donate.
Explicitly asking money for things of value has much better results.
Sounds like an opportunity for a new start-up.
I'd sign up for it.
With all the disintermediation that the internet has supposedly done, there must be also room for some new-fangled intermediation ...
- Asking to fix a bug NAO NAO NAOOO? More money please.
- Want to move some_lib to python 3? Money please.
- Want to backport some_fix to unmantained_old_crap_runtime? Money please.
- Want to discuss a particular choice in our roadmap? HUGE money please.
- Want to support device_x before device_y? Money please, and testing equipment if you could be so kind.
- Want me to help you with the conference you're paid to organize? Money, please.
I'm sure that people can be quite creative if they really put their mind to it. We think nothing of paying hundreds of $cash_units for things like tyres and fuel and double-glazed windows, there is no shame in asking for some of that back to build the software that will actually make those companies run.
But there are other problems discussed in the post and I'm afraid some of them cannot be solved with money alone.
Suppose you are overwhelmed with a thousand meaningless pull requests. Whom you are going to ask for money?
Suppose you are called a douchebag for rejecting an ill-thought out pull request. How is money going to mitigate the vitriol?
Suppose you are called a douchebag for asking money to fix bugs. Same thing.
Attitudes need to change too. There needs to be growing recognition of the respective contributions of users, developers and maintainers of OSS projects and their value.
BUT you have to realize a lot of OS development is subsidized. This takes the form of "free" work by students, undergrads, graduates, government grants etc. A lot of the suggestions people throw around are simply not feasible for hobby OS projects, which don't have access to free students or free government money. It's a race to the bottom if you want to state this as a business problem.
It also confounds the moral issue somewhat, as corporations (and individuals) then rightly feel they are entitled to development & support -- after all, the subsidies have come through their taxes!
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.
Perhaps, because it would just mean even less money would go into code that wasn't held as a trade secret? And instead of companies only being able to (without risk) be bad citizens of permissively licensed projects, they could just rip off everything GPL licensed as well.
Isn't the BSD licence pretty close to a situation without IP?
The GPL works well with the unix philosophy of having many small programs that do small things. There's no problem with taking some of those programs and using them in your proprietary project since you're just running them independently, and come distribution time you just ask (or release an open script that does it as part of your program's install process) the user to install system dependencies if bundling them yourself would constitute a derivative work. The problems with the GPL come when you try to use or bundle the programs a little too closely. It becomes important for libraries/modules to not be GPL so that you can still import foo and not be required to release your whole program under foo's license. Hence GCC has the Runtime Library Exception, and most third party modules for languages have similar exceptions (typically by being under a BSD-style license).
In the background of many corporate workers, the only approved way to write code or use third party code is as an importable library to use in their company's product (which may be a multi-million line behemoth). Writing little self-contained programs isn't very common for them, nor is using other programs as spawned subprocesses. (The exception where that may be more common is the case of web applications where the used programs aren't AGPL'd...) And so since importing any GPL library introduces a semi-uncertain (uncertain in whether a court would convict) hazard about whether the company's whole multi-million line behemoth is now a 'derivative work' for including a mere multi-thousand line bit of FOSS, devs will avoid GPL libraries entirely. The motivation for BSD-like licenses for using (or writing, then using) bits of code then is simply a matter of using them at all due to the library issue, and I agree that having at least the base code available later is icing on the cake that makes the decision even more easy. But I think if a dev's corporate background is in a culture that follows unix philosophy more with lots of different programs, they won't necessarily reach for BSD-style licenses on instinct even for things beyond libraries.
In one sense proponents of the GPL are opposed to the idea of abolishing IP since copyright law gives the license its teeth, while BSD guys would probably be fine if they were forced to make everything public domain (but still might ask for credit as a kindness even if not legally required to do so). But there's a bit in Stallman's free software song that I think shows the GPL guys could have the same perspective someday: "When we have enough free software/At our call, hackers, at our call,/We'll kick out those dirty licenses/Ever more, hackers, ever more." That was written in in 1991, there wasn't much free software then. I think at this point in 2015 we have so much source available, that if we're not there, we're at least very close to the point where we don't really need the viral nature of the GPL to force companies to release the source. Many companies produce entirely new works that are under a BSD license, there's nothing that compels them to do that but a dev culture where Open (if not necessarily Free) has real benefits even to the money guys and has won. GPL code now hinders many pragmatic devs who just want to include a tiny useful bit of some Program (i.e. one of its internal libraries) rather than work out how to use that useful bit indirectly by just running the program, and instead of having code reuse we're constantly reimplementing things. I can't just reach into git's source code and pluck a few useful functions I like for my own project like I can with the Python standard library. (I'm glad to know that if I ever need an approximate fraction function in JavaScript for a proprietary work, I can use the one I made based off of https://hg.python.org/cpython/file/822c7c0d27d1/Lib/fraction...)
I get sick of seeing entitled programmers whining that some library is LGPL or GPL, and saying they aren't going to use it as a consequence. Don't expect the author to be somehow sympathetic that you aren't going to be able make money off their work without offering anything in return, whether it's code or money.
Hobby projects get licensed as GPL.
Professional work, it is whatever the customer decides to do.
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."
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."
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.
But these people are usually the most cynical bastards you can imagine, and they really know it's all about the money. So, I'll echo the other suggestions, and recommend you send them a professionally-worded proposal. If they know can spend $X to get Y, (and Y kissing their booty) they'll drop the pretense and 'do business'.
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.
If they actually "need" those libraries, then they should be budgeting to give back.
It's not an excuse as I said I really want to have more time. It's just an explanation.
And it's reasonably standard practice in commercial situations to charge more to large enterprises than small ones.
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.
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.
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.
On the other hand, many of the engineers themselves haven't had the interest in doing the work to contribute the fix. They fix the problem apparent to them and go on, repeatedly fixing the same problem when they are forced to upgrade (they don't upgrade willingly, either).
And then there's the projects that make contributing as difficult as possible. You not only have to diagnose and fix the problem, you have to update the tests and docs and build system (which I'm perfectly fine with, personally, in the name of quality if I know how to do so, which I may not since I don't have time to track everything) and you have to do so in such a way as to satisfy the whims of the project's real developers, which you as a mere user manifestly are not.
I was speaking with a free software developer about a position at her former employer. She warned me that while she enthusiastically recommended most aspects of the job, the worst, most frustrating, and generally unpleasant part of it was dealing with the upstream communities your managers would insist you get patches mainlined into.
The problems are not isolated to greedy employers.
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?
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.
Seems that Travis Oliphant has set up an attractive solution for funding: https://www.continuum.io/content/anaconda-subscriptions
I hope it's very successful. It does involve paid support ...
Just enjoy building and letting people use your app. Fuck the rest.
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)
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.
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.
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.
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.
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.
Sometimes if you respond to 'we need feature x, y, and z.' with an upsell, they actually will give you money.
Perhaps you should start asking then.
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.
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.
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.
>
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"?