Corporations and OSS Do Not Mix
coglib.com
coglib.com
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.
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.
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.
Better results? Both efforts were funded almost immediately and well in excess of what was being asked for.
I think these two cases are great examples of how this could 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 ...
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.
- 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.
(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.)
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.
Quite a double standard. Requiring pay for fixes only incentivizes pay for labor, which is rare for OSS.
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.
1) Nobody is actually happy.
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."
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?
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!
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 ...
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.
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].
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).
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.
All trade secret laws do is if you make efforts to keep secret and some one steals it, you can punish them.
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.
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.
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.
Isn't the BSD licence pretty close to a situation without IP?
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 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.
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.
This has been key for me!
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'.
Sometimes if you respond to 'we need feature x, y, and z.' with an upsell, they actually will give you money.
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.
http://dangerouslyawesome.com/2014/04/community-management-t...
The TL;DR: encourage participation even above solving other people's problems for them - lead them toward helping themselves and others.
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.
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.
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?
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.
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.
Perhaps you should start asking then.
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.
>
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.
Just enjoy building and letting people use your app. Fuck the rest.
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 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"?
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.