Is It Good For Business To Subsidize OSS Developers? 124
ruphus13 writes "A lot of developers for open source software have full-time day jobs too. As economist Milton Friedman said, 'The business of business is business.' So, does it make sense for companies to encourage their developers to contribute to the open source community? OStatic discusses a blog post by Alfresco exec Matt Asay, who makes the case for why they should. '"Companies like IBM, Intel, SGI, MIPS, Freescale, HP, etc. are all working to ensure that Linux runs well on their hardware. That, in turn, makes their offerings more attractive to Linux users, resulting in increased sales." While I don't think we'll ever see companies everywhere subsidizing employee development of open source tools, many tech and non-tech companies alike could benefit from subsidizing open source development from employees with talent. If more companies woke up to this idea, we'd see more purpose-driven, mission-critical open source software shared by firms in the same industries. That, ultimately, would benefit the companies providing the subsidies.' Should your employer pay you for time spent on open source development?"
snydeq points out an Infoworld story suggesting that there's something to learn from the way French companies are promoting open-source development.
Define "Good" (Score:5, Insightful)
Is it "good" to maintain and expand the upstream rain forest that provides your raw materials?
It's not good for this week's balance sheet, but it's good if you think about it for five minutes.
Yes. (Score:4, Insightful)
Re:Why (Score:4, Insightful)
Collective action problem (Score:5, Insightful)
Why would a business pay for software that benefits everybody else? Why not just wait for someone else to do it?
There are answers to this question - e.g. IBM or Google is big enough and uses Linux enough that it needs to make the fixes just for its own benefit; pushing them upstream is not much extra work. Or, companies in long-term relationships - e.g. in the Silicon Valley ecosystem - can encourage each other to contribute to public goods like OSS via a "reputation mechanism" - contributors get respect and this translates into better relationships.
But the CAP is the fundamental issue.
evidence free (Score:4, Insightful)
Wow, that article on the French is an evidence-free zone. The only actual French OSS project they mention is some middleware doodah that I've never even heard of. Trying to think of some myself... um:
1. Mandrake ...er ... ... that's it.
2.
3.
I'm sure there are others but none springs to mind.
Re:Collective action problem (Score:5, Insightful)
This attitude that business is being charitable to open source when they push changes upstream is just, well, ignorant.
They push their changes upstream because they don't want to have to keep merging them in every time a new version comes out. If they didn't push them upstream they'd either have to weigh down their development team with annoying merging duties or they'd have to stick with outdated versions of the software.
The fact that they can push stuff that possibly is completely useless to everyone else upstream and have it accepted as part of the build is one of the wonders of open source.. and, if anything, it's the upstream developers who are being charitable.
lost opportunity (Score:1, Insightful)
The path that budding developers take is infinitely more accessible (and far less expensive) via open source. If you lose the foresight of funding that community you risk intellectual hoarding and corporate driven (read "heavily manipulated") R&D that is self serving and beleaguered with protection, IP, DRM, and general monetary ballast that ultimately imprisons creativity.
Because reinventing the wheel is really expensive. (Score:5, Insightful)
F/OSS means that you don't have to buy or write an operating system just to run a single program on a single device, or write an OS for a new piece of equipment from scratch. It means you don't have to come up with a proprietary database when you're not sure the bigger project will pan out. It means that you can support standards and undermine format monopolies, allowing you to bring your product to market despite an 800lb gorilla.
"The business of business is business" doesn't mean that short-term gain trumps long-term. It means that business, in a market economy, seeks advantages where it can find them. Having a large base of reliable free software is a big enough advantage for some companies that they happily underwrite its development.
Yes, but ... GPL (Score:2, Insightful)
The company I work for would love to subsidize open source development. We'd all love to use and extend existing projects instead of writing code from scratch. But recently I spent a couple of weeks writing a proprietary communications package when there's already perfectly good code on SourceForge.
Why? The OSS project uses the GPL. This means if the company donates two weeks of my time to subsidize this OSS project, it ends up losing ownership of the rest or our application. That would cost the company *a lot* more than wasting time rewriting existing code.
Whenever I start a new project I always look for existing solutions for my company to subsidize. LGPL, Apache, and the rest are fine, and that's why there's so much commercial support for those projects. It's just to damn bad there's so much GPL. Let's get the religion out of software development.
More work, more practice (Score:2, Insightful)
I'm surprised nobody has yet pointed out that contributing to OSS is likely to lead to a direct increase in developer skillset.
Comment removed (Score:3, Insightful)
Re:Yes. (Score:4, Insightful)
Free Software has the convenient side effect for these businesses that it makes software not just a commodity, but a very cheap commodity. For businesses in the first category, that means people have more money to spend on their products. For businesses in the second category it means that they reduce their operating costs.
This is exactly why Microsoft has tried to encourage something like a Free Software ecosystem around their products. MS Office is not Free Software, but it has a set of developer tools that allow your company to hire someone else to extend it in ways specific to your business needs. You then aren't locked in to a single supplier for these modifications (assuming you are sensible, and use a work-for-hire contract so you own the rights to them). You can do it in-house, or contract it out to one of a great many small companies. Free Software just broadens this idea. The more of your stack is Free Software, the less you rely on a single source, and the safer your business is.
Re:Why (Score:5, Insightful)
OSS developers get funding because companies think their free software benefit them
I may be overly cynical, but I would suspect that the only time a company contributes to an OSS project is when it wants some form of control over it: benevolence doesn't really come into it, nor does a subscription to Free Software ideals.
Take Apple: as closed and proprietary as Microsoft, if not more so, yet they contribute to OSS. In fact, take Microsoft, who now sponsor the Apache Software Foundation [arstechnica.com].
I suppose my point is that perhaps instead of asking whether companies should subsidise OSS, we should be asking whether OSS should want companies to subsidise it.
No surprises (Score:2, Insightful)
A company whose livelihood is open source proposes that other businesses should subsidize open source... That's kinda like asking the RIAA and MPAA to sponsor a study on piracy.
Re:Collective action problem (Score:4, Insightful)
Well, yes and no. Simple bugfixes are obviously best to push upstream, the bigger question is added/customized functionality which really adds value. At some point the value of having exclusive functionality exceeds the merge costs, depending on a boatload of factors ranging from interface complexity and stability, business value, use by competitors, specificness of the issue solved and so on. Very many companies are afraid to give away anything of value or just don't rationally calculate what it costs them to maintain it themselves, so they'd rather keep it inhouse instead even if they rationally should have open source it. But it's too drastic to go to the other extreme and say that open sourcing code isn't being charitable.
Re:Why (Score:4, Insightful)
"The Open Road" article annoys me because it incorrectly implies that free/open source software has some sort of problem and needs subsidizing. Honestly, it's quite insulting to the free/open source software movement. IMHO, the author has hugely underestimated the strength of the free/open source software movement. It's not free/open source software that's in trouble - it's companies that rely on selling proprietary software that are in trouble.
Government is just a big user, LL IS big in France (Score:5, Insightful)
Open source is really about users taken responsibility and control for mission critical applications. Government is just a big user, like a big bank, an insurance company, or film production company. They have internal needs. All organizations need to look at their internal needs and skills and contribute effectively, where it is of direct benefit to them. When the benefit is big enough, they pay someone to work on a project directly, if not, they don't. Sometimes it is only part time, and the level of expertise is only for QA, patches, and the like. That's fine!
The major Apache contributors at the outset were all firms whose survival depended on having an effective web server. The business case for working on apache was compelling for all involved. Other contributions should be similarly compelling.
The flip side of yesterday's story on Quebec sole sourcing (avoiding all responsibility of any kind, and just following 'the market'), is national funding of software distributions (taking total responsibility to the point of re-inventing the wheel) Neither approach is going to work best in the long run. Large organizations funding what they need, is just the corporate analogy of individuals scratching their itch.
blog post about that: http://csptrn.blogspot.com/2007/03/national-use-of-open-source.html [blogspot.com]
Logiciel Libre is Big in France.
In France, that's what they do, on a massive scale. Example: the French Fisc (like the US. Internal Revenue Service) replaced their almost all Oracle all the time solutions by making an RFP (Request for Proposal) with specific performance tests for a J2EE platform. All the biggies were invited (Oracle, IBM, BEA, etc...) but the fastest implementation was by a small local firm using open source tools.
reference:
http://www.cllap.qc.ca/2006/modules/wfdownloads/singlefile.php?lid=48 [cllap.qc.ca] duh... it's in French...
They don't care if you can't read it, their in it for their own good.
The fisc saved a ton of money by doing a competitive procurement. The winning company is local, and developing expertise among people who pay taxes, and drive the economy.
Another useful initiative in France with OSS is
http://adullact.org/ [adullact.org] where people from a bunch of different local governments work together and fund and adopt common integrations of OSS technologies for specific vertical uses. Each local government reduces their costs by partially funding the common solution. Each gets a say in requirements and functionality delivered. None is stuck shouldering the whole burden.
It is not about creating new software projects. There are thousands of those, and almost all needs can be met by integration/consultation of existing software, because, frankly, not a lot of government needs are that complicated. People just have to have a mind set that they are responsible for the technological choices they make, and get educated about long term implications.
On a given government procurement, the traditional decision is 'buy vs. build' that is an obsolete decision, it is more like 'buy vs. assemble' or 'buy vs. contribute' or 'buy vs. cultivate (local talent)' today. The costs are looked at on over the duration of a procurement, not on a life cycle basis.
For example, if you take open office, and you say it will cost 4 years to make the transition, that's true. the requirement for the functionality is not going away, so in five years, assuming the transition was taken care of, when you have to renew your MS license, ooo is going to cost close to zilch. That's when they pay back starts.
Government needs to look at things rationally over the long term. the only thing on the side of the traditional vendors is perceived level of risk and market share. As the number of adopters increases, both of those aspects are declining.
Re:Yes, but ... GPL (Score:3, Insightful)
Free Software isn't a religion, but it's not a charity either.
Re:Yes, but ... GPL (Score:5, Insightful)
Why? The OSS project uses the GPL. This means if the company donates two weeks of my time to subsidize this OSS project, it ends up losing ownership of the rest or our application. That would cost the company *a lot* more than wasting time rewriting existing code.
First, you still own your application. It's copyrighted to you. You own it. Second, is the app one your plan on distributing? If not, then the GPL is moot.
It's just to damn bad there's so much GPL. Let's get the religion out of software development.
The GPL keeps you from taking my code and locking it up in some proprietary application where I won't get to use it. You seem to be under the unsupported belief that I should let you.
Re:Yes. (Score:1, Insightful)
Paying an OSS developer to fix a bug or add a feature seems like it would be simple, but unfortunately it's not.
First, most OSS projects work on a charity model. "You give us money, we work on whatever we feel like." You can ask for whatever feature or bugfix you want, but the devs won't work on it unless they want to. There's nothing wrong with that -- as I implied, most charities work in exactly this way -- but it means that there is literally no way, other than hiring the dev into your company directly, to get a specific feature or bugfix added to most OSS projects.
There are, of course, companies which form around OSS software specifically to do work-for-hire. The problem there is that the work they do for you typically ends up back in the OSS project. Logical enough: that is the way OSS is supposed to work, after all. But it removes any competitive advantage you have, and it's contrary to the way software contracting has traditionally worked (where the company to whom the programmers are contracted will usually have the rights for the software).
The way some OSS companies get around this is with a dual license. As long as all the copyright holders for your OSS product are on board with the idea, then great. But the Linux kernel, for example, can never be dual-licensed (for the same reason it will never be anything but GPLv2). Most popular OSS software is actually in the same situation as the Linux kernel. So it's tough.
Unfortunately, the best way to support OSS is by hiring outright the developers who are worth anything. This will largely rob them from the OSS community (because the only reason to hire them is to compel them to close any future code they write for you), but...
Re:Why (Score:3, Insightful)
I may be overly cynical, but I would suspect that the only time a company contributes to an OSS project is when it wants some form of control over it: benevolence doesn't really come into it, nor does a subscription to Free Software ideals.
I don't think you are over cynical, but I do think you are missing something. Companies contribute to OSS projects when it gives them a return on their investment. Sometime that's control. Most of the time, though, they realize that they can benefit from cooperation if the software is not part of the core service/business that they are selling.
To really understand how free and open source software works in this circumstance, you merely have to look at consortiums. These were popular with businesses long before free software came around. It's a bunch of businesses that agree to cooperate on something that is not what they are selling in order to reduce cost (or sometimes they cooperate on something that they *are* selling in order to make a standard -- take DVD technology for instance). Free software just lowers the barrier to that consortium so that *many* organizations can contribute and benefit.
A really good example of this is the OpenNETCF project. It's an implementation of the .Net framework libraries with a MIT style (I think -- it's been a while since I used it) license. Back when I was doing mobile work with .Net it was indispensable. Microsoft's own implementation just plain didn't work and my company needed code that would operate the same on both desktop and mobile platforms. So we used OpenNETCF. And we fixed bugs in a few places and submitted patches.
The key here isn't control. Hell, on Microsoft platforms (and especially in .NET) Microsoft has control. You aren't going to change that. But we needed working development libraries and MS was a bit slow to deliver (it was not a high priority for them at the time). Many, many others were in the same boat, which is why OpenNETCF got started and flourished. It just doesn't make sense to horde your improvements -- the people who you are working with aren't your competition. You can only benefit from sharing.
So while I'm sure there are still lots of companies (maybe even most companies) out there that will not share no matter what, there are enough companies out there who will share to make it viable. They understand that shared benefit is still benefit.
Having said that, I agree that most companies do not adhere to free software ideals. It is fortunate that such ideals are not necessary for free software ideas to be useful. That's what "open source" is all about -- pragmatic use of free software methods without regard to ideals. IMHO keeping the ideals in mind is also good for business (what's good for your customers can be good for you -- and free software ideals are about protecting the customer), but it's an argument that I don't think needs to be had in this context. It's enough to say that free and open source software development is completely pragmatic in many places in business. To avoid it is to cut off your nose to spite your face.
Re:Collective action problem (Score:3, Insightful)
In at least one case I can think of, no one else will do it. My soon-to-be-former hardware-based employer is a great example (I got a better offer, and went for it). The folks I'm about to leave behind uses Linux very, very heavily. Their entire software backend to the product is written with (and for) Linux.
Linux made perfect sense for them since they're selling hardware, Linux/FOSS means it won't cost a mint to license out, and it means a HUGE amount of flexibility for the programmers.
Better Question (Score:2, Insightful)
Easy call in my mind.
Why I hire OSS devlopers (Score:5, Insightful)
On a number of occasions I have hired people who actively participate in OSS projects. Here's why:
And they get bonus points if they have done the work in some area that relates to the work I'm paying them to do, even if we don't use their package. Why? Because it means they've been thinking very hard about the problem.
Re:Collective action problem (Score:3, Insightful)
> Why would a business pay for software that benefits everybody else?
If they do that, they will
a) They will look better in the eyes of open source community. And trust me, you want this, because we are usually those who tell others what they should buy.
b) They become more attractive employer to those who are most talented. Like me ;) . I would love to work for an open source project and I'm not alone.
c) They usually benefit from it directly also. For example if it is a text editor they decide to support, they can use that software themselves and they get to call the shots or at least make the fixes that are important to them. Quite many companies have their own internal tools, but if the project would be open source, they might get testing support and bug reports from the outside and even patches.
d) They might even join forces with their competitors, so that they would share the costs but also share the benefits. This would mean that both parties would benefit from it equally so they would not give advantage to the other, but on the other hand they could cut their development costs.
Re:Sounds like 'la la land' (Score:5, Insightful)
Let's say I'm running Company A, and I compete with Companies B and C. If I subsidize an OSS project (rather than paying external or internal devs for a private custom solution that might give me a competitive advantage), what's to stop Companies B and C from using the OSS code that I funded, for free?
Maybe they don't know about it, maybe they're not set up properly to use it effectively, maybe they've already bought in to a competing solution.
Or the reverse: If Companies B and/or C are willing to subsidize an OSS project, why should I subsidize when I can mooch that code for free myself? I'd be more than happy to let my competitors fund code that I then can use for free.
Maybe you want faster development, or maybe you want slightly different features than what your competitors are going for.
As time goes on, more and more companies would wise up and realize that funding OSS code let's their competitors mooch that code for free, and more and more companies will stop subsidizing since they're being played as suckers.
You're not automatically a "sucker" just because you happen to be creating positive externalities. I doubt that a lumber mill would much care who else used benefited from the software they helped fund for their HR department to use, unless the wider use actually benefited them by, say, getting bugs found/fixed quicker.
When's that last time OSS folk actually invented something? IBM or Google tweaking Linux or Apache and giving those tweaks back to the community is baby shit. Let's see Google release their search algorithm code so that Yahoo, MS, Ask, etc can use it for free, then I'll be convinced that subisdizing OSS is worthwhile.
A lot of the work on distributed/decentralized source control (Darcs patch theory, (deterministic) mark-merge, etc). FastCGI. Anything described in the RFCs. Plan 9 and Inferno. Package management. etc...
Re:Yes. (Score:2, Insightful)
A desktop+Vista+Office is going to last for about 3 years. So over 3 years, you save, say, $1,000 with Linux (this amount is preposterous). Over those same 3 years, if you are lucky, you will have paid the professional office worker about $150,000 in salary (with at least another $50,000 in overhead directly related to employing that person, and probably another $50,000 of overhead that is less directly related).
So the computer costs, maybe, $2,000 over 3 years, and the person costs at least $250,000 over 3 years. The software+computer is a cheap commodity compared to the person. It can still make sense to save money on the software+computer, but the person better not lose even 1% of their productivity.
Re:Collective action problem (Score:3, Insightful)
One thing you left out (or, at least, under-emphasized): if you push your changes back upstream, then you're no longer the sole maintainer of your fork, and others likely (almost certainly) can and will help maintain and enhance and fix the bugs. That's always a big win.
The flip side of this (something I've actually encountered) is when your add-ons are so specific to your particular company that upstream isn't interested in accepting your patches.
I've gotten paid, here-and-there, to send patches upstream to various free/libre/open-source projects since the mid eighties. No company I've worked for has ever regretted such actions, but one, as I mentioned above, once regretted their inability to perform such an action.