Open source's ardent admirers take but don't give Open source went mainstream long ago. It's a pity, then, that it's still so poorly understood by many of its most ardent admirers. For example, ask a gaggle of IT executives, as Accenture recently did, why they're heavily adopting open-source software — and adopting heavily, they are: 50 per cent of those surveyed are "fully …
It's a point well made, but that said relying on what Google is or isn't doing doesn't necessarily translate to what anybody else is doing.
That said I think all of us who have developed OSS software large and small have seen this from the communities at large in code, support and monetary terms. It's hard giving up your time to keep developing, living on noodles and water, in what becomes a full time job with often little reward but the knowledge your code is out there doing it's thing on x thousand servers. It's why I quit doing it full time and only develop OSS on my timetable for my needs - but if everybody did that some great projects just wouldn't exist.
And yes it's always tends to be the guys who are the most militant about open source who are the worst offenders.
All that said I think we all know who the worst real-world corporate offenders are for this. The company that shall remain nameless who have BSD at the centre of their OS, but aren't compatible with anything anywhere. This is the same company who will charge Open Source developers trying to give a damn and fix issues that are specific to their OS - for the privilege of talking to anybody who knows their codebase.
Even Microsoft do a better job than this nameless company, Microsoft are only too happy to talk to Open Source developers about any subject, be it their code, your code or some guys from Redmond discussing (complaining about, actually) the availability [or lack] of porn on the iPhone (no joke this actually happened to me).
Even if it is used briefly by someone who will only commit to using an open source program in a decade's time, the critical review they give it is likely to be vital information to developers if they can receive this feedback. Those who rely on open source will start to need to obtain specialist support services for it, and it will often be the specialist support business that contributes changes - in order to keep their customers happy.
You can't admire open source without advocating it which is a significant contribution, so the title of this article is incorrect. Apart from that, thanks for an excellent and well-informed article.
I do quite a bit of development and am very thankful that the users out there give useful feedback and testing that helps the project along.
While the GPL (whiich uses the copyright laws for its muscle) gives protection and acknowledgment for the code writers, there is no such protection for the huge test effort that many organisations and people put in.
Frequently organisations and people contribute patches and test results to developers via private email (not on lists etc). This input is very hard to measure, but it definitely happens.
Maybe this also goes for coders. I mean, just taking OSS in a new direction and showing off new stuff could be just the inspiration needed - new UI, new hardware support, or just plain spiffy new stuff could set off discussions and push development in new directions. I'm not saying that sending back the code to the community wouldn't be much more efficient, just that there could be benefits in seeing what others can do without having access to the raw code. After all, that's how much of the present technology got built - MS learning from Apple learning from Xerox PARC etc.
Google have just added network throughput improvements to the kernel. Android is being merged back into the tree. They have just open sourced the $100m VP8 (and ffmeg have just improved it). They spend millions each year on Summer of Code. I suspect they're about to liberate Java (a la Novell) Canonical annoy Debian by taking their code and what else?
Ubuntu have the most screwy build tools I have ever seen on a Linux distro - everything is "unbuntified" from the insertion of "ubuntu" into the names of everything, to re-using Debian command-line options to do completely different things.
They follow the same "screw it over"-rule when naming packages: Just because a package is named the same on Debian and Ubuntu it does not mean that it is the same package; oh no, THAT will teach the sad leechers trying to install anything Ubuntu on their filthy Debian system!
Now I like FreeBSD more. At least that is consistently weird, but powerful shit ;-)
According to the Gnome Census, 1% of all contributions to gnome came from Team Ubuntu. (That's 1/16 of what RedHat did, but who's counting...)
See! They give back! They're making the Linux desktop sexy again.
(Of course, they didn't make as many contributions as Nokia, Intel, Fluendo or Novell or of course RedHat.)
I was an "IT executive" needing some translation work done on a GPLed application. I told the developer (a company) that I'd be happy to pay for the work required, as that sounded likea good contribution. Not so, said the developer. You can pay, but the code we cut won't be part of the GPLed package.
I paid, and that product has now become pretty popular, though we never rolled it out to any great extent, as I wasn't sure what the developers' motives were.
Re the thrust of the article, 71% of respondents who /would/ contrinbute seems pretty gratifying to me, and who's to say that some of the remaing 29% wouldn't also do some advocacy or marketing, also useful?
"71% of respondents who /would/ contrinbute"
Exactly the point I was going to make. This isn't the first time Mr. Asay managed to write a whole article around a simple misrepresentation like that. Lies, and all that.
Having worked in an open source consultancy, all code went right back in some repository, and mostly public, though not always announced. A goodly chunk even went right into the public repository of the very public FOSS project we did a lot of work on. That's easy to do with committer status.
I think you were dealing with a company that tried dual licencing, and apparently that's not a very keen idea as it makes people wary of your motives. But then, confused business models usually aren't.
That sounds more like an Open Source project rather than a Free Software one. The difference is often not that big and its more around the drivers of the people rather than anything tangible. What you're seeing there is the difference. It doesn't mean all OS projects would do the same, but any FS developers probably would do that.
Contributions, as a lot of others have said, are often difficult to track. Who says there isn't more contributions that whoever they asked didn't know their company did? It wouldn't be the first time management isn't fully up on what their techs are doing.
I read these companies' profiles as being manufacturing, services and finance. From that, I'd guess they are as likely to have code changes to contribute back, now, as they did previously. AIX users don't hack their kernels. If they replace their AIX with Linux or BSD, they're still not going to hack their kernels.
If you are moving FROM a closed source model TO an open source model, where is your culture of making core changes to the core of the code going to suddenly spring from, in the first place?
Large companies are liable to have a support agreement with someone like Red Hat, these cost a lot of money (so contribution goes back to the FOSS community) but the flip side of this is that, if my experience is anything to go by, your support is not valid if you modify the code.
To hackers, open source is pretty much prerequisite otherwise you might as well write the thing yourself.
To techies, the open source buffet means less hassle with procuring, and, often enough, better software, and for some it has the added benefit of being easily able to fix things. Cool.
To managers, it's actually not that great unless they're rooted in tech-dom themselves because it's much harder to quantify. Where does this code come from? Who do I blame? How do I cover my ass against this? Where's the sales guy to buy me lunch?
To executives, the only thing that matters is whether the darned things deliver on the promises made to the executives. How? Psah. Delivery and cost is all they care about.
So, red hat sells a product with support combo, and that's exactly what the executives want. That red hat contributes back to the larger community is not important except as a tool to rouse the rabble, gain some favourable PR, what have you. It's a throw-in. That the reason they get this price is because the underlying thing draws from open source might be useful but isn't really important. So to them, a ban on local modification in exchange for support? They didn't expect their people to do modifications in the first place.
Red Hat are paid to participate in the community by customers who need software merging upstream but don't have the time or knowledge to do this themselves. If you don't have your code changes to something merged upstream then you will have to recreate your code changes repeatedly, as often as the mainstream version you want to ship downstream with your changes is significantly improved. When you do get your changes merged upstream you'll still have to maintain these, but this is going to be much cheaper as part of the mainstream version than it will be maintaining these changes as a fork.
The idea that Red Hat and similar companies employ so many engineers doing this work full time out of altruism for community relations purposes rather than to make an honest profit by doing something cost effective for their paying customers is ill informed.
If you make an amendment to an open source project and it is not included into the source (and not contributing is a sure way to make that happen) then you are tied to the version you originally amended. You cannot guarantee that future version will be compatible with your changes. Indeed if your changes are worthwhile you can be pretty sure someone else's code will go in to do the same thing ensuring incompatibly. Any significant changes in the main project made after that point will have to be either ignored or re-written by you. The support burden gets ever larger as time goes on.
I can see a problem in a few years time where free loading companies will be stuck in a kind of 'IE6 lock-in' of their own making: New technology is changing the market but they can't implement it because of a 'special sauce' hack they did years ago to differentiate them in the market.
A few years ago, Open source was all "hobby projects" that would never be seen in the corporate or business world.
Now.. Open source is an ecosystem for reducing software development time and cost, and is a valued part of corporate/manufacturing etc. Big multinational companies, government institutions, small business.. All use open source now. Many do so openly. And some of the biggest names in the computer industry are contributing back. 100% contribution is not likely, and of questionable worth.. Realistically.. Does any open source project really need 100companies submitting the same change every day?
Now modifying and keeping the code under wraps is a holdover from the "everything is a trade secret" days. Too much hassle, too much liability and other well worn excuses.
Soon, it will be easier and cheaper to allocate a couple of people to keep up with open source submissions and keep everything ticking along. Then the adoption will surge. Companies will list the open projects they contribute to as a PR bullet point. Money/developers/changes.. All good.
The simple reality that companies like IBM, Google, Sony, Samsung, Apple, Amazon, Ebay, NYSE. LSE and many others have found is that the software is useful. The adoption figures alone prove that beyond doubt.
It will however take time for them to get used to the whole open sharing concept as a means of saving money. But when they do.. Look out closed source world.
and repackage it?
Some companies continue to be caught doing this. The price/penalties must be higher to keep companies from making binaries and getting patents on non-original code. Patent-issuing countries need to be taught how to access code repositories and to efficiently sleuth out fraudster companies.
The trick corporations use is calling the work Open Source, but only that. The license is the important part.
Free software and open source are not synonymous, but a lot of people make the assumption that if the source code is exposed, that it's free of charge. Microsoft is starting to figure that out with it's Microsoft Research and Connect projects. Despite that these projects are technically Open Source, it's not free software: MS still has an EULA on most non-GPL projects stating that any contributions belong to Microsoft and if they choose to close the source and sell the product, you get no say, no credit, and nothing out of it. Caveat emptor.
As long as that perception exists, more and more businesses will keep doing this.
We use open source as the basis for almost all of our applications, and quite frequently we find useful libraries to which we either cannot contribute, due to the maintainers being extremely inactive, or are discouraged from contributing to due to committer policy of the project.
For instance, for the last 5 years I've been maintaining our own branch of xmlwrapp, because the original author disappeared from the interwebs (and dropped all of his, excellent, software), and someone sandbagged the project on sourceforge (although going back now, looks like it has had some improvements, hmm, might have to merge them in).
Worse than the disappearing maintainer is when your aims, and the aims of the project maintainers differ to the extent that the maintainer flat out refuses to entertain the idea of your change.
In those cases, we have three choices:
we can choose to abandon that library, which is hard to do once you have a body of code using it already
we can choose to fork it publicly, which is a pain to do, you have to then actually support users, respond to bugs - try getting resource for that...
or we can choose to fork it internally, track new releases and integrate our modifications with them as they are released.
Of all these options, the third is typically the cheapest in terms of time and money, so guess which one we do?
Spot on. There is also the case where Donna Developer would love to contribute her hacks, but MeanOle Mangement says no. The case for OSS to management though is actually stronger than some previous posters have suggested: when you build on a commercial product which is abandoned (bankruptcy, not making enough money; whatever) you're high and dry. With OSS, you can in the very worst case go it alone. It's like software escrow at no additional cost.
But honestly, I agree with the point that most OSS users do not make changes, certainly none worth committing. I've been using OSS for about 16 years, and have been involved in dozens if not hundreds of projects involving some or all OSS components. Many times I'd expected to have to make modifications to one of those components I'd chosen as a"starting point". Number of times I've had to hack the source of one of those tools in any kind of significant way: once.
Once you've identified a need in an active Apache project say, the likelihood that someone else has identified the same need and come up with a fix or a workaround is very high.
As told to me many years ago by Paul Everitt, then CEO of Zope Corporation:
"Software is a liability, not an asset".
(unless of course your sole business is actually developing software, but that is only a small minority of companies)
It amazed me working in a high street bank, just how much software they had written in house for general admin stuff (I'm not talking trading here, I'm talking general business process stuff). Most of it the orignal author had left and no-one knew how it worked. Yet at the same time they were vary wary of Open Source, as they thought it a risk... HELLO??!!
I managed to get them to at least switch to an Open Source content management system for their Intranet (Plone) but they still very much had the culture of keeping things under their belt. It wasn't the developers as such, but more the management. If anything was to be released outside the bank then they'd need to get their legal department to take a look at it (which invariable didn't know code from a cucumber) and so the process would just stall.
They in the end ended up with an internal fork and a lot more maintenance than they would have done had they been able to commit their work back to the main community and not have to maintain it all themselves.
-Matt
Application shareware, like packages, only works if you can make your processes easily fit the systems. As a rule, the fewer users a company has, the more it makes sense to go "off the shelf" but as soon as you move up to middle to large sized operations, custom kit makes money sense.
Consider a shop with 500 people all using the same set of "off the shelf" applications. Each worker has a 2-inch thick 3-ring binder with all the manual procedures needed to fudge the systems to fit the process, and calculators to perform the math the system doesn't have the basic functions to handle. (Yes, really.)
Provide them with custom applications to fit their actual jobs, and you only need 200 of those people, which at an averaged burdened cost per position of $100k is an annual recurring savings of 30 million bucks. So if it costs you $5mm to develp, and $1mm per year to maintain, it's still a tidy bit you saved?
When I worked for Ericsson, the procedure was to release patches and fixes through SUSE, where they licensed the Linux we worked on, mainly because Ericsson did not want any imagined liability (lawyers are experts in dreaming up problems) from releasing anything without the usual disclaimers and dis-owners.
SUSE would then upstream as appropriate - sometimes the SUSE guys would be working on a better solution that we would then adopt instead.
I've worked at several places which have incoporated open source C libraries into products. They all contributed bug fixes back, for exactly the reason in the article - helping the library helps them.
In return the OS communities involved tended to be very responsive, and it was undoubtedly the best way to work.
That said, C being C, we did need to make various changes to the libraries (mainly to do with memory management issues) which needed to be reapplied to each new version. It would have been easy to fall into the trap of forking the sources.
"...29 per cent are unwilling to contribute back their code modifications to the relevant communities"
Which implies 71 per cent are willing to contribute back their code modifications to the relevant communities. Which is consistent with the perceptions of improved code quality (76 per cent), better reliability (71 per cent), and lower software maintenance costs (71 per cent).
Uh, I know this is basic Open Source stuff, but I don't get it.
Say you're Amazon or someone, and you've just developed some top notch code on top Linux and it gives you competitive advantage - your systems are now better, shinier and more productive than the competition - why would you want to give that back? So you have to maintain the code, but your product is now demonstrably better than the competition and it's that what's keeping you ahead of the game. Why would you give it all away?
I'm not trolling by the way, so please don't flame me, I just don't understand.
If there are licensing conditions then so be it, you have to publish the derived work or whatever the license requires, but there's no obligation to 'give back' beyond that ( except perhaps a moral one and that's highly debatable ).
Businesses choose software for a number of reasons, whether proprietary or open source, and why should they want to treat the later any different to the first? You take, you use it, and that's it.
If anyone wants to give back then go ahead, do so, and it seems a considerable majority are willing to do so. Does it make those who don't somehow wrong? Not really.
It's ultimately an issue of 'businesses exploit open source' and that should come as no surprise to anyone; that's what businesses do, leverage things to their advantage, open source or not. If it's there for the taking with no obligations which haven't been met then there's no real problem. Situation normal.
It's also 'businesses should be open source' - and that's just agenda setting and doesn't fit with the reality we have.
Also; isn't it said that the pleasure is in giving, not receiving?
Hence Paris - I'd give her one and not expect anything in return.
That's a fair question. Open source works best when people collaborate on things of mutual interest; by that, I mean things that should just work. We all need text editors, compilers, hardware support, file systems, etc. Any of those things could trip up competitors, but there are better places to find a competitive advantage, and there is value in having future releases built on a solid foundation. The closer a technology gets to uniquely powering one's own niche, the less sense it makes to give it away.
that doesn't contribute any source code back to the "community". Evil free rider?
Red Hat makes its profits from _somewhere_! Red Hat is the biggest contributor to Linux development, and many ostensible free riders are actually funding it.
There are many stories, don't be too quick to judge.
I'd just like to make a few points (good article, BTW):
1) Google has tried to merge their changes into the kernel. But, the kernel peoples have rejected them. And, based on what I've seen, rightly so -- Google made up their own kernel lock type, made up their own new video system (instead of adding drivers to the existing video infrastructure), and so on. Google and the kernel guys are working on making these patches kind of mesh in better with the mainline kernel. At a casual glance this seems petty, but if the kernel guys weren't strict the kernel would be a real unholy mess, with much less code reuse than there is now (for instance, there used to be like 4 or 5 different wireless stacks, the IDE/SATA/etc. code is cleaner now, and so on.)
2) Some of these cos that won't contribute back, probably no big loss -- some small patch to customize a code base to work better for a specific use is just not that useful in the general code base. They shouldn't commit now that they won't contribute back, but *shrug*.
3) I won't be surprised if Canonical's contributions aren't underreported. Since Ubuntu is almost stock Debian, I just wonder if a lot of their contributions don't go into Debian first, and then upstream to gnome, the kernel guys, etc. Maybe the 1% *does* include that though, I really don't know.
In my company, we post bugs and occasionally engage in development chats. If everyone does a little bit, the software improves rapidly.
I can't see us ever getting sufficiently low-level to start hacking on the projects we use, nor can I see us open-sourcing our own app code.
We are looking at replacing a core product on the Server sides with an OpenSource one.
There are a few around so we got a quote for the same level of support we currently enjoy from the Original but Proprietary supplier.
We almost fell off our chairs when the Exec from the FOSS Company gave us the number.
Zero up front cost. Tick.
Support cost THREE yes THREE times what we are currently paying. Fail.
No Support contract Discount for DEV or Test Servers. Fail.
We showed them the door pretty quick.
This is not a one off by the way. The other major FOSS Alternative in this area quotes broadly similar costs.
Add to this the major re-training of staff and the lack of anyone with these products on their CV (Apart from two which already work for us) means that we won't be stopping using the commercial product.
This was a very salutory lesson in the true costs of FOSS.
We are moving to RHEL though. The cost model for this does work in our favour.
So it is not all bad news.
I deliberately didn't mention the current product or supplier as we are in the middle of a support contract renewal process. You never know who reads this forum do we?
It seems obvious that the problem with OSS is the economic model. Microsoft may produce awful software, but you have to admit that their economic model works quite well. Microsoft used to push the rules of the game to their limits, and maybe even stuck a few toes over the line, but they never received more than a wrist slap for it. You may think over $1 billion is a hefty fine, but it's chump change to the economic model Microsoft has used so well.
My suggestion is that OSS needs a better model, and I happen to have just the baby on my blog. It's basically an open accounting model for charitable projects. In this situation, you get the users to agree to pay for the features they want with an incentive to recruit more users. Each user would only pay something like $10 toward each feature, but the programmers wouldn't actually start work until the funding was secure. Other advantages: Donors could assess the track record of the programmers before supporting them, and the project budgets could include funded testing to prevent the kind of quality slump that is ruining Ubuntu.
http://eco-epistemology.blogspot.com/2009/11/economics-of-small-donors-reverse.html
Where's the icon for money? Anyway, I'll use the Web 2.0 icon on the theory that fixing the OSS financial model would be really helpful for buying more and better badger paws.
This just sounds like abuse of statistics to me. Percentages in the 70s are held up as a good thing at the top of the article then '29% are unwilling to contribute code modifications' as a bad thing. Surely that means that 71% are willing to contribute which sounds good to me. Don't forget also that many companies have no developers would could contribute even if they wanted to.
I have used Linux for many years at our small company.
There are many ways to contribute to the commonwealth of Linux.
I make donations and help people use it... make a few new users a year.
Also whenever possible when I note something or think I know how to help someone on a forum - I respond.
I have been using sidux (very advanced Debian sid Distro for about two years, before that it was pure Debian for an additional 5 years.) This is out in the frontier of Linux land and I see many changes every day. I was at the Linux con 2009 and see that this is a very active community of company’s and users. I think that in time everybody will see that it helps everyone’s edge in the market to hang together... even if it takes a swift kick in the pants from time to time. The growth of Linux is astounding.
Join up now or get left in the dust... I believe it.
Back in the day when *everyone* either wrote their own system (normally to interface to their accounts package. Very few seemed to want to roll their own one of those) package suppliers would supply the source to allow company specific tweaks.
And individual companies would start modding it.
Sometimes *so* much they could could not take the updated version and run the mods against it (to gain their in house developed benefits).
However typically there was *no* mechanism for passing their changes/improvements back up the chain to the developers, which FOSS attempts to address.
While a company may not get *every* change it would like included back into the core the ones it does get shift the burden of support from one company to the whole community. Improving the way *every* one uses the package in the process.
It will not be a quick or easy process to change corporates into giving back something for nothing (as they will perceive it).
Only the resulting successes of those that do over those that don't will change minds.
the fact 71% are prepared to even *consider* sending changes up the tree is pretty encouraging.
Time will tell if they actually *do* it.
The big point with OSS is that you only *need* to release changes back if you distribute the resulting product. Even the ultra-strict RMS was savvy enough to realise that plenty of modified code either can't ever be released outside (perhaps it's not secure or robust enough, or contains trade secrets) or can't practicably be released (no budget for servers, perhaps). And the BSD license explicitly allows people to take the baseline code and distribute binaries from their in-house branch.
So not really surprising 29% take the OSS baseline and don't release their forked changes, then.
As an aside, I was amused recently to look up ESR's Wikipedia entry and scan an interview he did back in '98. Direct quote: "Netscape doing this creates a window of opportunity for us to get our message into corporate boardrooms. The flip side of that is that if Netscape tanks, no one is going to listen to us for another decade."
Which is precisely what happened. Aided and abetted by anti-competitive behaviour from MS, sure, but the simple fact is that Netscape forgot they were supposed to be making something that worked. The CompSci theorists took over and insisted on layers upon layers of virtual machines and indirection so that it could be massively customised by the OSS fraternity. As a result the new stuff was flakey as hell and dog-slow. Mozilla is still slower to do anything than IE, and is only useable by virtue of massively-increased processor speeds.
Because what's most likely to happen is that you contribute feature X, and the filthy hippies that maintain the mainline will 'improve' it and add broken feature Y to the next version, which will conflict with your local X patch.
You want to get other peoples' fixes. Your own fixes, you don't want anyone fiddling with.
It is with deep gratitude and relief that I received the news that Ubuntu "gives back" nearly nothing to the Community. Thank you Canonical! Wish you actually gave even less.
As to turning a profit - if Canonical treats enterprise customers with cash in hand as they do the vast Ubuntu herd, there will be no profits. And, with a 1% contribution to Gnome, it occurs to me that currently Gnome seemingly has adopted the Ubuntu view that users are too stupid to use indoor plumbing.
And, we give the obligatory salute to the now less than 1% out there that fly Linux on the desktop. Certainly wouldn't miss that bandwagon for anything.
Posted with the assistance of Geronticus eremita.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
