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!
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.
I have no doubt that this is your experience (for which there might be many causes - my email is in profile unlike yours ;), but there are also extremely successful examples like the ones I and others have posted. They stand out not because they succeeded, but because they're the few who tried -- and succeeded spectacularly quickly, almost accidentally.
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.
I worked for the past few years on making PyPy & satellite projects more business friendly. We've established a company (baroquesoftware.com), I went to conferences, advertised it etc. Granted, I'm not the right person to do the job - I'm generally a technically-oriented nerd. The community is welcoming for both commercial interest and newcomers and if there are hiccups, we're trying to fix them. This is not an easy project to get your hands dirty, we definitely don't need extra barriers to entry, for example it's extremely easy to get a commit bit on pypy.
There are some spectacular success stories, but even Django had a hard time raising money for someone to work full time on fixing bugs, while noone doubted usefulness of that. Now PyPy is far less successful than django, but it does save companies tons of money.
I would welcome advice/help/whatever in how we can make PyPy more commercial friendly in a way that brings revenue - I'm not interested in making businesses happy for free all that much.
Both of those developers asked the community for money. They should have asked the companies that use their projects directly. I world imagine they'd hey far better results that way.
I work at a company that uses a large amount of free software.
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.
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.
I agree with a lot of this, but it's more than asking for money. You have to offer things of value in exchange for money and ONLY in exchange for money.
- Asking to fix a bug without submitting a patch (or with a crappy patch)? Money please.
- 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.
"Pay extra"? Like you were paying for it in the first place. At the end of the day, somebody gotta pay the ramen. Besides, a certain project you might be familiar with is basically monetizing automated security patching, so throwing stones is really not a great sport.
(also, projects like requests are not desperate for users. One user paying to contribute to the well-being of the codebase is worth hundreds of users who won't even bother sending in a patch. Again, a certain project you might be familiar with is awfully aware of this state of things.)
The problem with the "pay them to fix the bugs" model is that it turns bugs into a source of revenue and creates the wrong incentive for the developer.
I'm much more inclined to agree to a "pay for additional features" model instead. Because then, by definition, you are paying for extra stuff, vs. fixing what should have been working correctly in the first place.
That's clever but wrong here: labor is what's being monetized. The people that they're asking probably require payment for their own labor and pay others w.r.t. other goods. Then, they OSS developers owe them free products and support of highest quality.
Quite a double standard. Requiring pay for fixes only incentivizes pay for labor, which is rare for OSS.
I think this applies more to companies requesting bugfixes as well as their scale and scope. For me at least, I don't mind fixing bugs in my projects if some random person is having trouble; heck that can be fun many times. On the other hand, a company using my project requesting that I drop everything and fix a bug that's only a problem for them? Seems perfectly reasonable to say "sure, it'll be 300$/hr" or whatever a reasonable rate might be.
This is of course all a hypothetical though, since I don't have any projects that more than like 5 people use and I have to hold them at gunpoint to get them to submit a bug report T_T.
Sure, and the first time someone insists that you triage a bugfix based on their priorities and not yours and they don't contribute to the project, you can let them leave as a user! Everybody is happy[1].
You are getting huge use value out of the project. And the real life blood of this OSS thing is the idea that the use value of the body of OSS software is greater than whatever got put into it in the first place.
So we all scratch that itch, and together we get the shared use value.
If people are investing very significant amounts of their time in the projects, that takes away from something they could be doing to make money, does it not?
We only have so many waking hours each day, and we all need to eat too.
So you submit the bug, and you get the answer, "thanks" and I'll put it on the list. Submitting the bug is a nice contribution. They need to be found. Creating documentation is a nice contribution. Teaching others how to use the OSS is a nice contribution too.
Lots of ways to give back, but it really only works out when we are, in fact, giving back. Or more precisely, enough of us are giving back for the ongoing improvements to make sense.
Now, you are going to think, "when will that be fixed?"
Could be never! Could be next year. Most likely, it's "when time permits" and eating might get in the way of that time too.
So you can wait it out, and hope somebody somewhere finds it worth it to scratch that itch. Or you yourself could go get it done and send a patch.
But what if you need it now? Funding that effort clearly has a value to you, and they do need to eat.
That money may well result in, "yeah, no problem. I can get this in a week."
Hmm? Their time is valuable. You are being asked to pay for their time.
If there's a broken traffic light in the city, do you expect some workers to come and spend their time fixing it just because it's broken and it's a good thing to do, or do you expect them to get paid to do it?
Now, one could argue that fixing bugs in open source software is a public good, like the traffic lights in a city. So maybe the government should pay for it? Well, I could perhaps buy that argument, but getting increased public funding for that sort of thing is likely to be hard, and it's hard to tell where that money is best spent.
But certain fixes, or new features, will help some people a lot more than others. If you would benefit from a particular bugfix, and someone else will need to do work for it, why not they ask you for money to fix it?
And the things of value are measured by the person with the money, not the person producing them. That's often a very direct conflict with the "scratch an itch" culture. Red Hat (for example) give me value (for which I pay them) by giving money to people to work on the 20% of free software (bugs, polish) that are apparently an anethma to many developers.
What you propose is sensible and funneling more of the wealth that corporations derive from using OSS projects back to the development of these projects is certainly a desirable thing.
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.
Agreed. We support gensim (a Python machine learning library) entirely through commercial projects and consulting. We never asked users for money, while keeping the lib 100% open source.
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!
There does appear to be a donate button on the Requests page. It's hidden as a "Buy Requests Pro" which is really just a donate (same code, unclear whether different license).
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) 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.
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.
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.
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].
Most software corporations are actually wary about LGPL more than BSD. There is a valid reason, at the same time, it may be interpreted as trying to screw LGPL choice.
Yeah you can use LGPL software, but with libraries and stuff that can be incorporated into the product, it's tricky.
I think it's a hard problem because you cannot really fault developers for not wanting to change the world (in a fashion similar to what RMS did). So they accept wrong moral choice for the same reason most people accept wrong moral choice, that is, the right moral choice is a lot of work (and sometimes even risk).
> 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.
I guess you're right, that's a big loophole. In any case, I actually don't like trade secrets either. If anything, they are completely against the logic of free market (free choice).
> How come the choice to keep my sauce secret is less than any other choice?
Because this "choice" restricts freedom of other people. You don't just want it to be a secret (then all you have to do is not to tell anyone), you demand that other people to respect and enforce it to be a secret (restricting other people's choices by restricting information).
If I give you three choices A/B/C, and don't tell you which is which, do you have a choice or not? I would argue that you don't. You need to understand what's behind each choice to be able to "have" a choice.
> Because this "choice" restricts freedom of other people.
It restricts the freedom of your employees to sell/give your company's private information to other people, and the freedom of competitors to use them to obtain it or take it for themselves. If you come up with the same technology through legitimate means, then the fact that someone else holds it as a trade secret doesn't matter. It's not like patents; if someone gets there on their own effort, they're not encumbered by trade secret laws.
It's also important to note that trade secret protection laws do not generally cover reverse-engineering. Protection from that (if any) comes from copyright/patent law.
Asking people to honest does restrict their economic choices, but so does asking them to not rob banks.
My guess would be that abolishing copyright would lead to every commercial program being run as SaaS with most of the code on a remote server, so changes in trade secret laws wouldn't help.
Abolishing copyright would eliminate a massive arts incentive. Whether that would be replaced with something reasonably equivalent or somehow better is a matter of speculation and faith, not an assertable fact. It's definitely not clear how many abusable corners it would have in a complicated real-world marketplace but my own faith says nonzero.
Copyright mainly funds corporate bureaucracies. It's not actually helping the vast majority of artists, except in the perverse way that destroying the public domain means less competition for new works to face.
Anyway, there's other ways to fund creative work from patronage to grants. Yeah, it's hard, yes there are challenges to address. No, Copyright is not a reasonable solution or incentive, it's primarily corrupt and working in opposition to the public interest.
Well, in arts, OK, you can make some case for it. But I don't see why the plumber should need to have copyright for his "piping design" in my house.. The same is true for programmers, you would simply be hired to fix some problem (or build a complicated pipeline).
> 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.
Isn't the BSD licence pretty close to a situation without IP?
What you propose is a free market solution - make property out of it. (And I don't think free market is actually desirable for most people but that's for another debate.)
From a practical point of view, it's complicated to dual license their code to the employer. If the employer refuses to license it, then the employee has to find the job which lets him license it (if he wishes to use it). That may be difficult.
In other words, if you have software as property, the idea "I want to work on the same code base in the future for a living" may contradict with someone else's idea "I am paying for it therefore you do what I want". In theoretical free market this should work out, but in reality there is a lot of frictions.
I was more thinking of stuff that is entirely mine that I just want to dump a copy of onto the web.
I don't think it's fair to make contributors assign copyright to me, especially if they are major.
I'd probably just keep a private fork from before their contributions, and, if for whatever reason my employer is GPL averse, that's their problem, and they can pay to reimplement anything they need from after that point.
Edit:
Perhaps a fair way to do it would be to say that contributors who agree to the CLA are also assigned rights to the whole code base, with the restriction of only being able to redistribute it wholesale as GPL. Similar to the way commercial sound and video clip libraries are licensed, you are allowed to redistribute it as part of another work in whatever license you like, but wholesale redistribution is only allowed under the GPL.
That would give the same advantages as a more permissive license, but reduce the freerider problem to some extent.
Re: your edit–that's an interesting idea. It seems like in practice it could be abused but in terms of your goal it's probably better to favor practicality over edge cases and a minority of people that would abuse it.
I think a lot of devs come to prefer BSD simply because of the importable library situation, and their dev background is just writing more and more internal libraries for their company's product.
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.
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."
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.
I wouldn't overthink this, it's mainly the psychology of the people who work in the bowels of big companies. They are used to having vendors kissing their ring, and on some level they justify it by thinking it's because BigCo is such an awesome big company. So they take that posture with "vendors" who are random open source devs on the internet.
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'.
I think Ted is onto something here. The author might want to try this approach. If he's concerned, he can do A/B testing between Give In and Fuck Off to measure their effectiveness. Haha
I think part of the problem is that there are certain organizations that just operate like this. If they don't have an immediate result the immediate answer is to threaten to burn their bridges. I am sure many can say the same for the stuff that happens even when it's a fully closed-source commercial relationship.
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.
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.
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.
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).
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.
> 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.
You can just hang out on an IRC channel for a project for weeks and get a lot of ideas about how things work. Also, if we pitch documentation bounties the same way we do bug bounties, we'd probably have a lot better documentation for software projects. And if your project moves so fast documentation falls behind often, perhaps your project needs to redefine its core features enough or at least mark what is experimental and shouldn't be relied upon too much for production code. None of this stuff really needs someone to be anything more than familiar with general coding concepts. Heck, just hire some random person out of a coding academy and they can document as a way to learn the internals of a project for a while - not a lot of harm can be done to a codebase by documenting it, right?
I would look at it sort of like a CTO/CEO relationship, but with a somewhat inverted power dynamic (if there is one at all). You have someone reliable who you can ask when a technical question comes up (so that you can determine whether someone else in the community is trying to tech-bullshit you), but you have a better grasp on how to deal with the human aspects of the community.
That said, I'm not sure where you're going to find these people. Good managers are probably getting good manager jobs, and likely don't have the time to hand-hold another community. Combine that with the fact that their power mandate will be less clear in a community, and I doubt you'll get many people that want to get involved in this way.
There's a lot that people can do without knowing how to code. QA and support are two tasks that are often horribly understaffed in OSS, and in larger projects, you don't want developers doing these tasks because other people can do them equally effective and developer time is better spent fixing things.
In general I agree, but my own experiences (mostly with FreeRADIUS) show that sometimes a very "direct" maintainer can scare away most of the nagging riff-raff that this article describes. An inclusive community is great, but it seems like some companies might see that as an opportunity to take advantage of the project.
Just to give you some perspective, requests is one of the most used packages in the python ecosystem and it has an amazing community. If you're having trouble finding funding for a project that is as good as requests, then there's most definitely something wrong.
"...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.
All of the companies I've worked for have had no problem with an engineer investing the time to fix a problem in an open source project and doing the work to feed the fix upstream---that's the fastest way to get a problem they're having resolved, correctly and permanently.
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.
> 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.
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.
> 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?
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.
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.
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.
I've never understood why being a small business is seen as an excuse. Do the circumstances of the person writing or maintaining the library change because you're a small business?
If they actually "need" those libraries, then they should be budgeting to give back.
As said giving back takes time. Especially you need to learn the internals of the library however in smaller companies you have less time than in other companies and also you probably already take care of internals of other libraries and since I'm a human I can't take care of everything.
It's not an excuse as I said I really want to have more time. It's just an explanation.
Well, to be honest, for almost all "core" pieces there are enough alternatives that for a really small businesses it doesn't make much sense to budget for paying for libraries.
And it's reasonably standard practice in commercial situations to charge more to large enterprises than small ones.
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.
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.
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.
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)
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.
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?
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.
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?
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.
He should not complain about users with asinine demands. Let them make those demands. Either ignore them, or explain the situation and ask for a reasonable fee.
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.
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"?
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.
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.
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.
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!