Open Source Economics and Why IBM Is Winning
driehle writes "In an article published in IEEE Computer magazine I recently looked at the economics of open source. I argue that large system integrators will do best and that open source startups will keep struggling. For developers, open source creates independence and new career paths as committers, while non-committers will fall on hard times. The race is on!"
I came across Dirk Riehle's excellent article: "The Economic Motivation of Open Source Software: Stakeholder Perspectives" while reading the April issue of Computer on the train this morning. Thankfully, he's also put it online.
While there's certainly some truth in the example of how loyalties are shifting - and individuals might stay loyal to a project (or set of projects) across employers, just as IT professionals have always carried skillsets, language preferences, etc. across employers - I don't think this necessarily means more movement in this direction, for a few reasons:
1. Developers get involved in multiple projects. Core open source folks might start as contributors and become committers on a single project, but that is more a reflection of their interest in being involved than it is of their interest in that specific project - if the employment environment (quick Optaros plug here?) is explicitly supportive of that engagement across projects developers might discover new loyalty.
2. If the employer can uncover enough opportunities for developers to get paid to use their favorite project - for example, keep a developer busy working on Drupal based applications - they might accept the variety of new projects as compensation for the single employer. The joys of systems integration and consulting work is that if you change client projects frequently enough that it can be like changing jobs without all the paperwork.
3. How much of the whole "employees becoming 'free agents'" thing is really voluntary to begin with, at least on the IT side? Maybe a better way to look at this is to say that Open Source increases the level of portability of the knowledge an IT worker gains over time with any single employer, or decreases the barriers to leveraging that existing knowledge in a new firm.
Regardless it's a very good read for business stakeholders who struggle to understand why anyone wants to open source an in-house project or contribute to an existing open source project.
Please mod me only (+) Underrated or (-) Troll
Substitute restaurants, or retailers, and the situation is the same ... most smaller ones fold within 5 years, some extyablish a niche, some grow, and some get bought out.
This is so pre-dot-com and so obvious that its not even funny. What next: 2+2=4?
I'm not too keen on Stallmans ongoing political agenda, but I cannot imagine an open source world without his keystone contributions.
His implementation of Lint (Splint) has reduced me to nervous wreck on more than one occasion, but it did improve my C coding skills.
About the only thing he wrote that I don't use is Emacs. I can appreciate its quality, and have taught its usage in the classroom, but I prefer Vim.
Thing is, politics aside, the guy is one awesome hacker, with few equals and fewer betters. Ok most of those achievements are in the past, but that can't be used against him unless the person making the argument has first exceeded his output.
Millions of people and businesses all buying the same software is economic insanity. It's not at all the same thing as millions of people all buying the same kind of car. A car has intrinsic value related to the cost of the components, software doesn't. Software sunk costs are incurred during development. Once complete the only ongoing costs, outside maintenance, are for distribution and the media. You don't have any intrinsic value of metal and parts in software.
Instead of paying money to buy software, a company can instead choose to pay less money to modify an open source project to meet their needs and leverage the contributions other companies have made modifying the same project to their needs. It's game theory in action. Five companies all pay a little to modify an open source project instead of all five paying a lot for some big box software solution. Collaborate with competitors in the same field for the common product they all need, then compete in pursuit of their market. Game theory.
What was needed for the theory to become disruptive to reality was a base of open source software to start with. We've had that for a while. All the pieces are there. And, as the author pointed out, it presents an opportunity for integrators.
Software really does fit the utility economic model better than a manufacturing model. Which is one of the things that really scares me about the US shipping manufacturing capability overseas and relying on a brain share economy.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
First of all, there is a lot of money spent on Open Source (distros, hardware vendors, service providers, people who would've otherwise paid for s/w, but now produce stuff with free tools, etc). We are talking about millions of $$ which would be enough to give $10k to every oss project out there.
:)
From all this money a tiny 1% actually reaches OSS developers and it is usually only for mainstream projects. The cash flow is broken. Sure, OSS people give away their work for free, but if money is made from it, it would be good if the people who've put effort on something can get a fair contribution back.
Now they tell you, "do your best and maybe you'll be hired in one of those 100K/year jobs".
But should you contribute high quality software to an industry that doesn't pay back?
You can write software that is not suitable for commercial distros, yet people can download it and use it instead of commercial alternatives.
It is a different mantra. "Fund us or we'll put you out of business"
I refuse to accept articles with bullshit arguments.
If Open Source Works, Why Don't We All Build Our Own Cars? The author poses this questions, tries to discuss economics, but never mentions the fact that the reason you don't make your own car is because you are able to make youself better off if you specialize in one thing and don't make the car (unless you are the best car maker). its called Comparative Advantage. Tell the author to look it up.
Also, where does he get his numbers from? "Failure Rate of Consortium and Non-Open-Source Collaboration" is "Perhaps 90%, unacceptably high."
Required Market Size for an Open Source Paradigm is "5 and up."
C'mon people, there are a reason why colleges require professor's to publish in peer reviewed journals.
While some of his ideas may make sense, his artciles should focus on backing up each small argument one at a time.
"While this explains some of the volunteer work, it doesn't explain why companies today employ people who contribute to open source projects on company time."
Maybe it is because the company sees the open source project as a strategic component to its product or service offerings and its in their best interest that the project succeeds and they can influence its direction?
"Il-Horn Hann and colleagues found that the salaries of Apache Software Foundation project contributors correlated positively with the contributor's rank in the Apache organization [6]. They therefore concluded that employers use a developer's rank within the foundation as a measure of productive capabilities."
For me, that is not right conclusion, or at least not the only one. It is often the case that people contributing to open source on company time only started contributing because they were told to by their employers. A developer salary at his company and their rank within the open source project are both determined by his technical skills and teamwork abilities.
Most of what you cite are simply strategic pricing by MS. Discounts for large customers help motivate buyers to remain loyal if they want to remain large customers instead of be undercut by the competition. This is differential pricing, classic monopoly maintenance. Pricing schemes for education help remove the tendency of price sensitive, but highly capable university clients to move to cheaper, open source products. None of this really relates to the models presented which are a point case revenue model.
My most common grouse is that the key is Open Standards, not Open Source. If MSOffice and OS products conform to a open standard and anyone can develop applications that cleanly interoperate with them...Umm, great, but this doesn't have anything to do with the revenue schemes of open versus closed source software development. You're confusing two issues. With open standards the market can operate freely in a traditional, capitalist manner. Open source is not needed for this. With open source, some users and developers of software can more efficiently create software and undercut the pricing of the traditional closed source models. Basically this study asserts that in a free market, open source will win because it is more efficient, just like any other more efficient process for doing the same thing. Whether or not we have a free market, or if open source development can win in a non-free market, such as the current monopoly/lock-in situation is another topic. This isn't about whether MS will be toppled. It is about whether you can make more money and pay less with open source software in general, as compared to closed source software (using the development methods and pricing schemes they commonly do today).
While I can stomach Perens in that he is not an FSF loon and at least recognizes the economic justification for proprietary software as a competitive differentiator, his assumptions seem a bit off base in order to support his theories.
Example: IBM is a hardware company.
Fact: IBM's 2006 revenues:
HW: 24.2%
Services: 53.2%
Software: 20%
Other: 2.6%
If you are primarily selling services, software that you need to provide those services is a cost. If you commoditize software, you create more opportunity to make money from services. Those fancy four-color graphs are simply restating something Joel On Software said a while back in words.