Slashdot Mirror
Innovation Happens Elsewhere
Nochiel writes "What is open source and why should businesses care? Why is innovation important and why isn't our company innovative? Why does it seem like everyone else is innovating while we aren't? How can we leverage Open Source? How can we implement an Open Source business strategy?" Read on for Nochiel's review.
Innovation Happens Elsewhere: Open Source as Business Stratgy
author
Ron Goldman and Richard P. Gabriel
pages
377
publisher
Morgan Kaufmann Publishers
rating
8
reviewer
Nicholas Ochiel
ISBN
1558608893
summary
How to introduce open source into the enterprise as a viable and valuable business strategy.
This is a book about open source in the enterprise. It seeks to answer those questions and more. Finally, the Open Source Process has been codified in a manner that gives management the business perspective they have been yearning for.
Too often, Open Source come across as a religion. Ron Goldman and Richard Gabriel, through their sober treatment of the topic, successfully detail all the pragmatic aspects that a business should consider.
This book, to paraphrase the authors: ..is for anyone interested in a better understanding of open source--its larger history, its philosophy--, and its future prospects.
It is licensed under a Creative Commons License and is available at this link.
Chapter 1 presents the problem that the modern enterprise faces, namely: how to ensure high levels of innovation and productivity.
The reader is then introduced to the "innovation happens elsewhere" problem: High productivity requires doing less in order to produce more. This, in turn, necessitates being able to leverage other individuals'/companies' efforts. A company, therefore, has to recognize that there are more innovative forces outside the company than in it. By using these forces, a company can maintain a competitive edge. Open source is then presented as a solution to the problem.
The rest of the chapter opens the readers mind to the "new" new way of doing business., illustrates why open source is a viable business strategy and introduces the most important aspect of open source: community.
Chapter 2 discusses the "innovation happens elsewhere" dilemma in even more depth. The authors have a keen understanding on the power of the Commons and how it can make a difference.
In order to illustrate how the Commons can make a difference, the authors use the history of the Web as an example. They highlight the fact that it was built as a volunteer effort with no central planning and a small set of simple protocols. The growth of the internet then came primarily from volunteer efforts.
In this chapter, the authors successfully illustrate that a modern business can succeed only by leveraging the creativity of the Commons and engaging in conversations with a broad and dynamic set of participants in the given problem space.
Chapter 3 then tackles the most important question that managers ask: What is Open Source?
This chapter details the philosophical tenets of open source, the root of the zealotism as well as the history of open source. Many readers will find it interesting that, in the past, open source was the default methodology for leading software and scientific work!
Common myths and misconceptions are also addressed. The authors also provide an interesting comparison of the open source and agile methodologies showing how open source borrows from the strengths of the latter.
The secret sauce in open source is revealed and the various sections along the open source continuum are discussed. In particular, the authors address the value of gated communities and internal open source, a valuable discussion for those managers who wish to introduce open source into their company slowly or even extract value from only a subsection of the open source value chain.
This chapter is a complete description of the open source phenomena. As such, it can easily stand on it's own if one is looking for a quick primer.
Chapter 4 concerns itself with the business reason for adopting open source, how to develop an open source business strategy and how to create a business model that supports the open source strategy. Sun's NetBeans platform is used as a case study to illustrate the various aspects of an open source business.
This section gives possible reasons why you should open source your product as well as why you should use open source. This chapter is directed at the business strategist who wishes to understand how to implement an open source strategy and measure it's success.
Chapter 5 provides a discussion of the legal aspects of open source. It details the nature of a license, the structure of copyright, patents and types of licenses. It also covers multi-licensing, contributor agreements and licenses for documentation.
Chapter 6 concerns itself with the workings of the open source development process. An open source product is not so different from a proprietary one. It has versions, minor and major releases as well as a typical product life cycle.
The differences, where they do arise, are in the new infrastructure (and management of the same) as well as the additional responsibilities that developers are expected to take as they engage the community.
The authors also discuss joining an open source project. In particular, they emphasize that it is valuable to join an existing project if that project is already targeting the niche/functionality you wish to address with your project. This is important because it generates goodwill within the community.
Finally, open source within the company is discussed with case studies from IBM, HP and Sun.
Chapter 7 makes note of the fact that open source initiatives generally begin with middle management. As a result, middle managers encounter a number of challenges: The need to convince upper level management, get approval, acquire resources and set up the infrastructure.
This chapter provides valuable advice and strategies for individuals in this situation. (I wish I had read this chapter while at my previous employment. It would have saved me a tonne of grief.)
Chapter 8 assumes that the project is up and running. The mailing lists are functional and the public repositories are bursting with bleeding edge code. How, then, do we harvest the innovation that is happening elsewhere and build momentum?
After reading this chapter, the reader understands the value of marketing and community outreach. This is particularly valuable especially because it comes from two prominent members of the Sun community. (Sun, is the king of marketing. Their marketing efforts have made Java a household name and tool.)
Chapter 9 provides a summary of the gotcha's at various stages in the open source journey. At first, this chapter seemed superfluous as it repeats much of what has been said in previous chapters.
Upon review, however, the chapter becomes useful as a reference guide for managers as they tackle the problems that arise during implementation. The section on "recovering from mistakes" is particularly useful because a proprietary closed source company is typically used to hiding it's mistakes from customers and the world at large. The authors emphasize that it is important and valuable to fail in public especially if this failure is accompanied by an effective solution.
In Summary the title of this book is deceptive. I would have been better titled: Professional Open Source: A Manger's Guide. It is a lucid and accurate treatment of the topic.
The authors' concept of the commons is very interesting. It is one composed of things whose basic value is not diminished by making a copy. This, in my mind, is amazing! Does this mean that all projects should be open sourced? After all, software increases in value proportionally to the number of people to whom it's distributed.
The book also manages to dispel the myth of first mover advantage. In fact, first mover products rarely have the required quality to dominate the market. Perhaps this explains why open source products are rapidly eroding the market share of established applications. The proprietary stuff was a first mover relative to open source. It's quality was so bad that open source now presents a mature solution that actually works! (I can't help thinking about Zimbra in that regard)
Perhaps the most important message of the book is that there are smarter people in the world and they don't work for you! To paraphrase the authors:
This book should be at the bedside of any manager who is either delving into the open source world, wishes to understand what open source has to offer or seeks to clarify why open source as a business strategy will erode the market share of proprietary companies."
This is a book about open source in the enterprise. It seeks to answer those questions and more. Finally, the Open Source Process has been codified in a manner that gives management the business perspective they have been yearning for.
Too often, Open Source come across as a religion. Ron Goldman and Richard Gabriel, through their sober treatment of the topic, successfully detail all the pragmatic aspects that a business should consider.
This book, to paraphrase the authors: ..is for anyone interested in a better understanding of open source--its larger history, its philosophy--, and its future prospects.
It is licensed under a Creative Commons License and is available at this link.
Chapter 1 presents the problem that the modern enterprise faces, namely: how to ensure high levels of innovation and productivity.
The reader is then introduced to the "innovation happens elsewhere" problem: High productivity requires doing less in order to produce more. This, in turn, necessitates being able to leverage other individuals'/companies' efforts. A company, therefore, has to recognize that there are more innovative forces outside the company than in it. By using these forces, a company can maintain a competitive edge. Open source is then presented as a solution to the problem.
The rest of the chapter opens the readers mind to the "new" new way of doing business., illustrates why open source is a viable business strategy and introduces the most important aspect of open source: community.
Chapter 2 discusses the "innovation happens elsewhere" dilemma in even more depth. The authors have a keen understanding on the power of the Commons and how it can make a difference.
In order to illustrate how the Commons can make a difference, the authors use the history of the Web as an example. They highlight the fact that it was built as a volunteer effort with no central planning and a small set of simple protocols. The growth of the internet then came primarily from volunteer efforts.
In this chapter, the authors successfully illustrate that a modern business can succeed only by leveraging the creativity of the Commons and engaging in conversations with a broad and dynamic set of participants in the given problem space.
Chapter 3 then tackles the most important question that managers ask: What is Open Source?
This chapter details the philosophical tenets of open source, the root of the zealotism as well as the history of open source. Many readers will find it interesting that, in the past, open source was the default methodology for leading software and scientific work!
Common myths and misconceptions are also addressed. The authors also provide an interesting comparison of the open source and agile methodologies showing how open source borrows from the strengths of the latter.
The secret sauce in open source is revealed and the various sections along the open source continuum are discussed. In particular, the authors address the value of gated communities and internal open source, a valuable discussion for those managers who wish to introduce open source into their company slowly or even extract value from only a subsection of the open source value chain.
This chapter is a complete description of the open source phenomena. As such, it can easily stand on it's own if one is looking for a quick primer.
Chapter 4 concerns itself with the business reason for adopting open source, how to develop an open source business strategy and how to create a business model that supports the open source strategy. Sun's NetBeans platform is used as a case study to illustrate the various aspects of an open source business.
This section gives possible reasons why you should open source your product as well as why you should use open source. This chapter is directed at the business strategist who wishes to understand how to implement an open source strategy and measure it's success.
Chapter 5 provides a discussion of the legal aspects of open source. It details the nature of a license, the structure of copyright, patents and types of licenses. It also covers multi-licensing, contributor agreements and licenses for documentation.
Chapter 6 concerns itself with the workings of the open source development process. An open source product is not so different from a proprietary one. It has versions, minor and major releases as well as a typical product life cycle.
The differences, where they do arise, are in the new infrastructure (and management of the same) as well as the additional responsibilities that developers are expected to take as they engage the community.
The authors also discuss joining an open source project. In particular, they emphasize that it is valuable to join an existing project if that project is already targeting the niche/functionality you wish to address with your project. This is important because it generates goodwill within the community.
Finally, open source within the company is discussed with case studies from IBM, HP and Sun.
Chapter 7 makes note of the fact that open source initiatives generally begin with middle management. As a result, middle managers encounter a number of challenges: The need to convince upper level management, get approval, acquire resources and set up the infrastructure.
This chapter provides valuable advice and strategies for individuals in this situation. (I wish I had read this chapter while at my previous employment. It would have saved me a tonne of grief.)
Chapter 8 assumes that the project is up and running. The mailing lists are functional and the public repositories are bursting with bleeding edge code. How, then, do we harvest the innovation that is happening elsewhere and build momentum?
After reading this chapter, the reader understands the value of marketing and community outreach. This is particularly valuable especially because it comes from two prominent members of the Sun community. (Sun, is the king of marketing. Their marketing efforts have made Java a household name and tool.)
Chapter 9 provides a summary of the gotcha's at various stages in the open source journey. At first, this chapter seemed superfluous as it repeats much of what has been said in previous chapters.
Upon review, however, the chapter becomes useful as a reference guide for managers as they tackle the problems that arise during implementation. The section on "recovering from mistakes" is particularly useful because a proprietary closed source company is typically used to hiding it's mistakes from customers and the world at large. The authors emphasize that it is important and valuable to fail in public especially if this failure is accompanied by an effective solution.
In Summary the title of this book is deceptive. I would have been better titled: Professional Open Source: A Manger's Guide. It is a lucid and accurate treatment of the topic.
The authors' concept of the commons is very interesting. It is one composed of things whose basic value is not diminished by making a copy. This, in my mind, is amazing! Does this mean that all projects should be open sourced? After all, software increases in value proportionally to the number of people to whom it's distributed.
The book also manages to dispel the myth of first mover advantage. In fact, first mover products rarely have the required quality to dominate the market. Perhaps this explains why open source products are rapidly eroding the market share of established applications. The proprietary stuff was a first mover relative to open source. It's quality was so bad that open source now presents a mature solution that actually works! (I can't help thinking about Zimbra in that regard)
Perhaps the most important message of the book is that there are smarter people in the world and they don't work for you! To paraphrase the authors:
Regardless of how smart, creative and innovative you believe your organization is, there are more smart, creative and innovative people outside your organization than inside. In addition, the majority of elsewhere doesn't particularly care to make products in your space.
This book should be at the bedside of any manager who is either delving into the open source world, wishes to understand what open source has to offer or seeks to clarify why open source as a business strategy will erode the market share of proprietary companies."
Besides just copying programs, what Open source will do a lot of times is provide the 'same' program but with more functions, a better interface, a SAFER program, or just the fact that its open source so that, if you are inclined to do so you could edit it to be just what you want.
Arguing with an engineer is like wrestling a pig in mud. Soon, you realize the pig is dirty, and he likes it.
you said it yourself ..
.. sounds like a lever to me :)
It multiplies force through a reduction in distance.
company gains doing less work
Larry Wall copied Perl from existing languages like awk, sed, and sh. Apache copied (literally) the NCSA web server. Sure, these projects did not copy commercial, closed-source software, but that does not make Perl and Apache paragons of innovation.
cpeterso
While I agree that "innovatition is not as important as a good overall product" - innovation is what has lead to most of the products we use everyday. You might not want to drive an "innovative" car, but the process for building your time-tested car has been improved greatly over the years by innovation. In fact, in order for your car to be time-tested it needed innovation to improve on safety and reliability.
I see innovation as a philosophy for constant improvement and trying new approaches. Borrowing a programming metaphor, innovation is the randomness in a Simulated Annealing process - without it you never find an optimal solution.
http://www.flurry.com
E-mail and news on y
The Internet, as a practical matter, was developed as OSS. TCP, UDP, IP, and DNS were essentially OSS efforts. The World Wide Web was as well -- in particular, most servers have been OSS since its data's been available. "Rsync" is a clever way to keep files synchronized, widely used, and is OSS. Tcl, Perl, Python, and PHP essentially created the web "scripting languages" domain, all OSS. As with any story, it's all complicated; some of the early efforts were BSD-licensed, so proprietary versions started appearing later (obscuring the OSS origins). But anyone who thinks that OSS only copies pre-existing work is ignoring the evidence.
- David A. Wheeler (see my Secure Programming HOWTO)
What I want to know is how do organizations make money in the open source world? A service model seems the most obvious, but then again development services seem best suited for areas with cheap labour (i.e. China & India).
Eventually, I could see IP and code as a sort of currently... perhaps that is where things are going. Even computer geeks need to eat and buy stuff from time to time though.
Harvesting the innovation of others via open source is hardly beneficial innovative. This does not distinguish a company from anyone else. By the very definition of open source, everyone gets to benefit from this sort of "innovation", including my competitors. Where is the value added?
The problem is not lack of innovation, but lack of innovation that is exclusive to my business. I can leverage open source. Fine. But innovation must then come from another quarter.
I read
"Why is innovation important and why isn't our company innovative? Why does it seem like everyone else is innovating while we aren't?"
Slightly off topic, but comments like these from businesses drive me nuts. This is coming as I recently had to attend an "innovation" seminar that was "voluntary" but still mandated that I attend. While there, the majority of the people saw it as a waste of time, while management saw it as "encouraging" innovation in the company. I understand that as a business, a company wants to know of possible ideas stuck somewhere within it's interior that might not normally be shown. However, I feel that trying to force innovation, or leadership, or any of those other intangibles is doing nothing more than lining the pockets of those BS business management companies and motivational speakers. Innovation isn't taught, it's cultivated. You can't send people to workshops and all of a sudden have an influx of new innovative ideas. I believe you have to run your company in an atmosphere that caters to that. It doesn't help if you're in a stagnant industry that is resistant to change, either. And I don't believe that rampant innovation can happen anywhere, in any industry.
The same goes to all the BS leadership training that is everywhere. You can't teach leadership - you either possess the skills or you don't. It's a personality thing. Trying to force morons to lead who aren't good at it winds you up with all of the PHB horror stories. Let's just face it, we can't all be great leaders in anything. Some of us are destined to only be cogs in the greater machine, and the sooner we all realize that and management stops trying to shove crap down my throat, the sooner we can go back to work and actually *do something productive*.
Heh, there's my rant for the day....
perl is a programming language, surely nobody thought of this before?
Apache when you come down to it, is a file server, yay.
ViolaWWW is a program to view something, wow, never would have guessed that.
And cooked food is just something else to eat, surely nobody thought of another kind of food before?
And a wheel is just a specially shaped lever wrapped around its fulcrum, yay.
A telescope is just a way to view something, wow, never would have guessed that.
Your bar for what is innovative is set way too high. If perl was just another programming language it would of sank in a sea of other "me-too" programming languages which had an additional advantage of being actively marketed. Filesystems are not targeted at the same sort of task a web server is. No cookies, no optional response types in the request, etc. And as for ViolaWWW, interfaces certainly can be innovative. You might have claimed that both web servers and browsers were inspired by Ted Nelson's Xanadu. But thats vaporware, so it can't really be considered open or closed source. certianly he has opened the conceptual ideas behind it.
Perhaps your definition its "Something is innovative if its a new way to make money", and since OSS does not seem like a new way to make money, it can't be innovative under that definition. Seems like it.
-- 3 events that reshaped the world in the 20th century: WW1, WW2, and WWW
If lack of innovation is what you want, the auto industry is actually a pretty poor example.
Breakfast served all day!
You know, it's kinda hard to be "innovative" when you get exactly bupkis out of it other than having your job outsourced to some country you can't even pronouce. It's also disheartening to do something that it is good for your employer only to discover that your staff gets cut so that that some honcho can get a 6 figure bonus for "saving money" by firing your guys. Worse yet, you have companies like TWA where the rank and file has not had a raise in 10 years. During that 10 year period, the employees have been asked to take 3 pay cuts. They're currently having a sick-out because they're being asked to take a 4th pay cut. To make everything really rosy, they just found out that one the executives that got let go has a $4 million dollar a year golden parachute for the next 5 years. They get pay cuts and he gets $20 million. In that kind of atmosphere, who even wants to "innovate" or do much of anything else for their employer?
2 cents,
Queen B
HDGary secures my bank
It still is the default methodology in science.
Other posters have given more than enough examples. I will add that there is a lot of imitation in software, both in the closed source world and the OSS world. This isn't always because someone is trying to play catch-up with a great innovation. It is also often related to (in the case of OSS appearing to play catch up) because there is a proprietary piece of software out there, that has become pretty critical to a business and the OSS community wants to be able to replace it for them (think exchange, who's shared calendering is often pointed to as a reason for not going OSS). Or in other situations where you have to be able to interact with the closed source world (hence the resources spent in developing Open Office, so I can read the .doc .xls that was sent to me, the NTFS drivers, Samba, etc). So yeah there is a lot of so called catch up at times, but it's mostly because we have to start from scratch to emulate or interact with a piece of software that we can't just look at the code or spec to see how it works.
"He was a wise man who invented beer." - Plato