Slashdot Mirror
The Success of Open Source
Weber is an academic and makes no apologies for it. He is not presenting an exciting new business plan, advocating a particular method of software development, or calling hackers to revolution. He is simply describing his findings after extensive research of the Open Source development process and drawing conclusions from them. As such, this book may not appeal to everyone in the Open Source community. However, Weber's ideas are timely and informative for anyone who wants to explain or advocate Open Source. He likens his work to The Machine that Changed the World, the story of Toyota's production method (224):
That book made two simple and profound points: The Toyota "system" was not a car, and it was not uniquely Japanese. The parallels are obvious. Open source is not a piece of software, and it is not unique to a group of hackers.
The first part of The Success of Open Source is a historical case study that examines the origins and social development of the Open Source community. It begins with Unix and hacker culture. For those who have read Steven Levy's Hackers: Heroes of the Computer Revolution and Peter Salus' A Quarter Century of UNIX, there is little new material here, but Weber offers a new and interesting perspective on the events. For example, he offers the insight that "hacker culture" existed before widespread network connectivity, drawing into question whether cheap bandwidth is really essential.
From there, he covers the development of the BSDs, Apache, and Linux, focusing again on social structures. He describes diverse events such as the messy expulsion of Theo de Raadt from the NetBSD core, the creation of Apache by an informal group of interested developers, and the establishment of Alan Cox as de facto Linux networking lieutenant. Weber draws from an impressive array of firsthand accounts, including mailing lists, websites, conference speeches, and personal interviews.
I get some interesting trivia out of this, such as Larry McVoy's original Unix is dying troll (98). Unfortunately, since Weber's narrative is mainly topical, it is occasionally redundant in telling one story from multiple social angles. Other claims are close to flamebait, such as suggesting that Richard Stallman is an example of a "failed leader." (168)
For the second half of the book, Weber moves on to Explaining Open Source in the terms of his discipline, political economy. He sees two broad categories of principles to the Open Source process: Microfoundations, including individual motivations and the economic logic of the collective good; and Macro-Organization, solving the problems of coordination and complexity. (133) While I doubt each reader will catch every academic nuance in these chapters, Weber is thankfully sparing in his use of specialized vocabulary and writes his overall argument in clear, easy-to-follow logic.
This section also contains the most insightful observations in The Success of Open Source. While there are too many to list here, one is the concept of Open Source Software as antirival. As more copies are made and put into use, value increases as a result of a larger market and the small percentage of users that contribute bug reports and possibly patches. This turns the traditional "free rider" problem into an advantage.
Though Weber does not mention this in the text, one can see part of this principle in proprietary vendors' providing free downloads or turning their backs on rampant piracy. It also does not take a great leap of logic to see application of the antirival model to other fields such as music or academic research.
As is customary in social science literature, Weber uses his conclusion to both recap his argument and to raise questions for future direction of research. What is the best organization method for property distribution, as opposed to the current methods based on exclusion? How can the Open Source production process be used effectively to improve prospects for the developing world? What is the best way for closed, hierarchical systems to interact with open, network-based ones? While some of the issues involved are offtopic for this book, hopefully future work will examine these questions in depth.
Though Open Source has been mentioned in many recent works, The Success of Open Source is the first academic book that focuses on the Open Source community as its object of study. It gives a readable, thought-provoking, and occasionally funny account of what Open Source is and means, making it an extremely valuable resource for those who want to engage and discuss these issues on an intellectual level. As Weber states, his positive, constructive outlook "may not be fully satisfying, but it's not a bad place to start." (272)
Joshua Daniel Franklin is a graduate student at the University of Washington's Information School. This review may be redistributed under the Creative Commons Attribution License. You can read the table of contents, preface, and an excerpt of the first chapter of The Success of Open Source at the Harvard University Press website. The reviewer's website has an list of errata. You can purchase the The Success of Open Source from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.
> while I'll use Oracle for its
> scalability, performance, and corporate support.
There's probably a size/performance metric floating around here too. For database under a terabyte, PostgreSQL is probably fine.
The question then becomes - how much data will I be packing into this database? If it's only a few hundred GB or so... PostgreSQL may be sufficient. And the customer will save a lot of money... good times.
The Army reading list
I find your example of Oracle/Apache quite funny, being Oracle comes with two Apache products, httpd and tomcat.
It actually makes my point more than anything. The fact that Oracle supports and ships these open source products along with their commercial products shows that the two can and should work together. Take the best from both worlds instead of fighting to have one community with all the power.
Javascript + Nintendo DSi = DSiCade
There is no deadline so there is plenty of time to focus on usability.
It took Mozilla five years to reach a usable product. Opera did it in two. There is a certain advantage to customer facing commercial software. At the very least it plugs a market demand until the software becomes a commodity. It also blazes a trail so that commodity software like Open Source can do it right.
Sadly I don't see many closed source projects that have very good usability so that reasoning evidently doesn't work out very well.
Adobe Acrobat, Photoshop, RealPlayerOne, MSAccess, Quicktime (Sorenson), and iTunes are all examples of commercial products that people pay money for, and would like to have ported to Linux. While Open Source alternatives exist for some of them, they are either comparatively immature or have certain legal encumbrances that prevent them from being introduced into a commercial distro.
I get much quicker times on support from most opensource.
How long did GNOME 2.0 go without a way to add or remove menu items via the GUI? 2.0-2.4, that's how long. Open Source addresses things faster if it's in their interest or meets their ideals. That's not a criticism, but a fact of how it works. Money talks, and the potential loss of a support contract will often make software houses bust their butts to solve problems and add features that would normally be considered "boring".
Javascript + Nintendo DSi = DSiCade
Besides MS CO - is there another example of a proprietary software company being "at the throats" of OpenSource?
Then, even Microsoft has opened an OpenSource project. Perhaps they actually do work together more often than not?
Kinetic stupidity has a new brand leader: Allen Zadr.
Perhaps if companies paid 'contract wages' based on the perceived value of a project, but allowed employees to work on any project. Employees with a current excess of funds could work on enjoyable 'low pay' projects, while employees at short ends would work on the less fun 'high pay' projects.
I can see many potential issues with this, such as the hassle of time tracking and the likelyhood of abuse, but think of the morale issues... rather than being stuck endlessly in a project you detest, you can 'take a break' and work on a low paying fun project (or fun for you). People who enjoy less fun tasks, like documentation, would get paid for their interest in valuable, but not glamorous, tasks.
It's kinda like auctioning off 'work'. The more employees who want to do a certain task, the more you pay for it (in lower wages).
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
> just how much more productive is somebody working on Open Source
Well, this is impossible to mesure. As programming is mainly a creative activity, you cannot mesure productivity per hour.
A programmer doesnt only work while typing in a text editor, but also in the bus/his car, while thinking about how to resolve a bug. And this "off-the-keyboard" activity is impossible to track accurately. Especially as a motivated programmer will probably have more "off-the-keyboard" activity then a payed drone who doesnt identify with his programm.
So to compare productivity, the best you can do is compare people who work full-time and compare productivity per day. As people who work full-time on an open source project are most likely paid to do so, a true comparision between the occasional volunteer and a payed employee is impossible.
However, a comparision between employeea who choose their project freely and normal employees who were ordered to do one would be interesting.
> a business which allows its employees to work on whichever projects they choose.
Google allows (and encourages) it's employees to work part of their time (10% IIRC) on whatever they want.
Almost everything Google offers (beside standard search) actually started as such a "pet project".
I have discovered a truly remarkable proof for my post which this sig is too small to contain.
Opera became a usable product faster than Mozilla did but it wasn't nearly as ambitious and IMO isn't nearly as usable as Mozilla now. Both Firefox and Thunderbird are excellent. Opera isn't horrible but it could be better, especially since, as you said, it was out ahead.
Adobe Acrobat, Photoshop, RealPlayerOne, MSAccess, Quicktime (Sorenson), and iTunes are all examples of commercial products that people pay money for, and would like to have ported to Linux. While Open Source alternatives exist for some of them, they are either comparatively immature or have certain legal encumbrances that prevent them from being introduced into a commercial distro.
But do any of these programs have good usability? Not in my experience. I haven't used iTunes so maybe it's the exception. RealPlayer and MS Access rank, IMO, among the worst user interfaces ever forced on the public.
I'll agree that Gnome 2 had (has?) some problems but a lot of them stemmed from the commercial interests involved in it. A lot of arrogance has gone on that wasn't a problem for Gnome 1. How many users have any chance at getting their desired features added to the current version of a commercial software product they are using? Sure money talks but you'll find it a lot easier to hire someone to add a feature to an opensource product of your choice than to add the same feature to most commercial products.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
The hard cost to developer's is equipment and bandwidth (but they'd likely purchase that stuff anyway...).
The soft cost to developer's is the time that they spend. Time isn't free. If you spend time developing OSS, then you don't have it for anything else. This is call an opportunity cost.
What can be worse for developers in general, is having managers get the idea that development doesn't have a cost. If that idea becomes common among managers, then salaries among working developers will take a BIG hit. (ie, you can't keep giving away something for free and still expect people to think it has great value... Also, when judging value, people almost always look at the up front cost, and not the expenses after that.)
PostgreSQL has been known to support well over a terabyte recently. We're looking at PostgresSQL 7.5 now, which may have PITR, two-phase commit (the foundation of replication and other features), Win32 compatibility, and several other things.
I'll admit it doesn't have the replication, PITR, clustering and other features that Oracle has that enterprise users need, and even if we do get them in 7.5, it won't nearly be the quality that Oracle has, but it can handle as much data as you can fit on a disk effortlessly.
Give it a few more years, and PostgreSQL will have everything Oracle will have (the useful bits at least), plus it will be just as or more reliable. PostgreSQL is looking at dominating the database market eventually. If Linux is any example of what is possible, expect some serious action in PostgreSQL.
I think this year you are going to see more serious enterprise features being developed by interested 3rd party corporations for PostgreSQL. It has a strong foundation, and it is quite easy to build on. I know. I've studied the source. Expect serious replication as the killer feature this year.
The radical sect of Islam would either see you dead or "reverted" to Islam.
``You're equating software development with patents.''
Ok, perhaps I tried too hard to make my arguments seem broadly applicable. The case runs mostly against patents (not copyright, which I see as a Good Thing). However, some of it could also apply to other cases. One of those is software development: if many parties build on a shared base, they all benefit from improvements to it, as do their customers. I think that pooling funds for such projects (GNU could be an example) makes sense. That said, software development is often done as a hobby, meaning that no funding is strictly necessary.
Shipping sources to customers gives these customers additional benefits, such as the security that the code can be supported even if the original supplier ceases to do so, and the ability to flexibly adapt and improve the code. This adds value to a product, and I would think it reasonable if companies could charge more for an otherwise comparable product if it comes with source.
As for your statement about communism; yes, my idea shares certain characteristics with it. However, the main reasons that (so-called) communist systems have failed is that they tried to make things work without rewards, and power was concentrated in the hands of few, with no real checks in place.
In my suggestion, there is an incentive for people to contribute. Those who do research (development, etc.) get paid. Those who pay get better products.
The system I have in mind does not prohibit checks and does not necessarily concentrate the power in the hands of few. Different interest groups can run different funds, so that if one group fails, the rest still work. Group members can be represantatives of various parties, they can be democratically elected, you name it.
Academic research, yes, that's a Good Thing. Just like you said, it's often comparitively cheap, the results are available to anyone, and a lot of interesting things have come from it - I would almost say that the major advances in computer science have come from academia. Someone said that anybody who believes that academic research can or should be replaced by corporate research deserves to live in a world where this has taken place. I find that a very good saying.
Please correct me if I got my facts wrong.
As for your statement about communism; yes, my idea shares certain characteristics with it. However, the main reasons that (so-called) communist systems have failed is that they tried to make things work without rewards, and power was concentrated in the hands of few, with no real checks in place.
Actually, I should use the more correct term. What you propose is "socialism". A dash here and there isn't necessarily a bad thing, but funds like Social Security show how badly a government manages these things. The real problem is that such concepts are very idealistic and tend to fail when hit with the real world. For example, your suggestion raises the following questions:
1. Who decides what projects get money?
2. How do they decide how much money to give?
3. How do they prevent pie in the sky projects (e.g. a "real soon now" warp drive) from eating up the budget, year after year?
In the market, you have to show a return on money spent, so the first is solved. The second is decided based on the return formula. The third is handled by cost overruns. If a project gets too expensive with little chance of success, it gets killed.
Academia handles pie in the sky stuff more elegantly because a project can continue as long as it can find relatively small amounts of funding. And if other scientists/engineers believe the project to be a dud, it will live and die by the team originally assigned to it. That's not to say that there isn't tons of wonderful stuff that "should have been" or "could be", but there are times when things should be left alone and revisited with more knowledge and experience.
P.S. Why is parent marked as Troll?
Javascript + Nintendo DSi = DSiCade
I agree... but it is faulty management logic driving bad decisions. Most management people and too many ordinary folks don't understand "for the greater good" esp. in a production and/or economic sense. Software developers do. Why? Simple, it is a *complete* waste of one's time, effort, and energy to completely at every corner have to reinvent the wheel for essentially NO OTHER REASONS than legal ones (i.e., ownership, copyright, etc.). Programmer's benefit from sharing *and* being altruistic so long as it promotes sharing.
Altruistic? Yes, absolutely, there is real cost to the programmer, but, if he/she (and therefore increasingly his/her employer, etc.) can contribute to a shared pool which costs time, effort, energy, & money, to a shared pool that saves reinventing even more and more wheels, then that is better, much better than proprietary non-sharing models. This is *why* open source esp. things like the GPL *will* be successful.
OTOH, BSD-like licenses do not force sharing to occur if you release modifications. And, over time, fewer and fewer wares will be released under BSD licenses than GNU and others.
On the commercial front, legitimate business deals are founded in fair-trade between parties. The GPL is fair-trade. BSD is one sided, hoping you'll contribute back. I respect and admire those and many other attempts at solutions.
Which ones are better depends on human nature and how we interact social more than any technical reasons that may or may not exist in the real world.
A huge challenge for all of us is to dispense with the temptations (and ultimate ills) of greed.