Author: JT Smith
I recently read the book “Good to Great: Why Some Companies Make the Leap … and Others Don’t” by Jim Collins. I’m always interested in building better software organizations, and I often say that technology is a fallout of the organization.
Collins’ book is about a five-year research project on “great companies which have a cumulative stock return that beat the general stock market by an average of seven times
in fifteen years, better than twice the results delivered by a composite
index of the world’s greatest companies, including Coco-Cola, Intel, General
Electric, and Merck.”
Collins shows what makes these organizations so successful and how it can
be applied to other organizations, hence my interest in applying it to software
development organizations.
While reading the book it became clear to me that he was describing nearly
all Open Source software
development processes. I will try to correlate his general research
findings to the software development process. This should apply to Open Source
as well as proprietary software. Open Source clearly has the edge, but I
will come back to this later.
The book outlines seven steps necessary to have a great organization with
great results. Results can be anything, like a project finished on time
and within budget, or a stable reliable operating system environment built
by a group of volunteers.
First Collins divides leadership into five categories, with Level 5 leaders being the highest and best leaders. Here is where the properties of these
leaders really caught my eye. Level 5 leaders are fanatically driven, infected with an incurable need to produce sustained results. They are resolved to do whatever it takes to make a company great, no matter how big or hard the decision. Level 5 leaders display a workmanlike diligence — more plow horse than show horse.
I could go through the entire list of Level 5 leader characteristics and, at any point, would describe the personalities of most of the leaders of
successful Open Source projects. This is, of course, in contrast to the more celebrity,
hype-speaking closed software project leaders, whose products are spectacularly
unreliable. Collins argues that many board of directors prefer the celebrity
leaders, most likely because of their visibility. From my experience,
many software organizations fall into this same trap of preferring the celebrity.
Open Source projects do not encounter this problem because the leaders grow into
their leading positions not because of hype, but of real contribution.
This seems to suggest that “free wheeling” organizations enable better
leadership.
Let’s start the second section on how to build great software organizations
with the big bang from Collins’ research: The old adage,
“people are your most import asset,” is wrong. He says people are
not your most important asset; the right people are.
His research team found that the great companies first put the right people into the right positions and the figured out a way to make the company great.
Eric Raymond’s book on Open Source programming, “The
Cathedral and the Bazaar,” summarizes the same point as
follows: “That being the case, it’s doubly important that open-source hackers organize themselves for maximum productivity by self-selection — and the social milieu selects ruthlessly for competence. My friend, familiar with both the open-source world and large closed projects, believes that open source has been successful partly because its culture only accepts the most talented 5% or so of the programming population. She spends most of her time organizing the deployment of the other 95%, and has thus observed first-hand the well-known variance of a factor of one hundred in productivity between the most able programmers and the merely competent.”
In “normal” software projects, with a given set of people and budget in
addition to a time-line constraint, this seems impossible. Just try to explain to the CEO that you are going to hire the right people first, then go and figure out what to do with them. From my experience, if you are not in one of those companies aiming to be great, you still have to deliver a project on time and in budget. Before you fall for a silver
bullet, and you can take your pick here, my advice is to just try to put
the existing people in the right spot. Make sure none of those spots are
career limiting. You will get better results than you ever imagined were
possible with your team.
If we look at successful Open Source projects again, there seems to be a natural
process that keeps the right people in the right positions. Here’s a quote from Collins’ research again with the companion statement from the
Cathedral and the Bazaar. “Good-to-Great management teams consist of people who debate vigorously in search of the best answers, yet who unify behind decisions, regardless of parochial interest.”
Cathedral and the Bazaar: “Linus Torvalds’ style of development — release early and often, delegate everything you can, be open to the point of promiscuity — came as a surprise. No quiet, reverent cathedral-building here — rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches (aptly symbolized by the Linux archive sites, who’d take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles.”
Again, here Open Source seems to do what the great companies do, which suggest
that those projects will be around from some time to come. I will come back
to this section from the Cathedral and the Bazaar, because
there is another important point captured here.
I will try to summarize the next three sections of the book, because these have to be defined on a case-by-case basis and can not be generalized.
First, you have to face the brutal facts but never loose faith. For Open Source
projects, this could be that there are always commercial closed source
projects competing with the Open Source projects, but nobody seems to loose faith
that Open Source will have a better product in the long run.
The book’s “Hedgehog” principle is a section of three intercepting circles: what are you passionate about, what can you do best and what drives your economic engine. This easy to pinpoint for Open Source project developers. They are passionate about software and are the best at building software. My guess is that they just need this piece of software they are working on and want to share it with others to make it even better. That’s their economic engine.
The third section of the book is about a culture of discipline.
The single most important form of discipline for sustained results is fanatical
adherence to the Hedgehog concept and the willingness to shun opportunities that fall outside the three circles.
The discipline shown by the kernel developers not to build a Windowing
system into the kernel, in either Linux or BSD, astonished some people
in the early to mid-’90s.
In contrast, one of the most common problems with software development for
internal use in companies is feature creep — and then not making and holding
developers and the business responsible for the project’s outcome.
The book’s next section is about technology accelerators and it is important
to note that “while the great companies in the research project used technology
to accelerate their momentum they didn’t use technology to create it.
Even though some of these companies pioneered new technology.” But the
most important finding here is:
“You could have taken the exact same leading-edge technologies pioneered at the
good-to-great companies and handed them to their direct comparisons for free, and
the comparisons still would have failed to produce anywhere near the same results.”
This just suggests that all the fear about Open Source in business projects is
in most cases certainly not based on facts. In other words, if you
have a mediocre organization you will just be that, no matter how many
great proprietary business applications you deploy. On the other hand,
if you are a great organization, you can even develop your leading edge
applications in the open, your mediocre competition will not benefit from
it. You might benefit if you get some great application from another
great company. This is also reflected in another quote from Good to Great:
“How a company reacts to technology change is a good indicator of its inner drive for
greatness versus mediocrity. Great companies respond with thoughtfulness and
creativity, driven by a compulsion to turn unrealized potential into results; mediocre
companies react and lurch about, motivated by fear of being left behind.”
From a technology standpoint what’s a better way of realizing the potential of an application than looking at the code?
The last section important to software development in the book is about the so-called “Flywheel” concept of constant motion, used in business to build momentum. Software development is no stranger to this concept, best characterized by Linus Torvalds as “release early and often.” This is also used by object oriented methodology with an iterative development process.
Here’s what I I took away from all of this: Some Open Source projects are built on the same management styles and principals, knowingly or not, as some of the most successful companies on the U.S. stock market.
This means there is more to Open Source than meets the eye. One observation about
management style and organizations (in Cathedral) and an independent research
study (Good to Great) come to the same conclusion on how to run a successful
organization. With so many software projects failing with many different
technologies, it suggests that the problem is not with a particular technology
but with the management. It is just a matter of time until great companies
will realize they can share the code to some of their applications without
fear of helping the competition, because the use or integration into the
organization is more important than the actual code base. Integration
is not as easy to replicate as a code base.
The next big thing will not be Web services but will instead be the ability to make software application architectures part of the organization
instead of just supporting components of the organization. Why do companies need this kind of advice? For example, how to deploy customer relationship management.
If several departments have both non-integrated data stores and non-integrated
processes, a CRM application will not achieve its goals without a thorough
understanding –or potentially massive breakage — of business processes.
Appoint one CRM project owner with complete accountability and responsibility. A
leaderless Open Source-discipline CRM deployment team will waste months and potentially millions of dollars on stalemates.
Wouldn’t the most computer illiterate CEO have known that if he creates a
new CRM organization, there will be an influence on other organization’s
business processes? That this should be handled and managed up front? That
if the impact is great enough, there has to be an executive leader in place?
I believe the new organization should have a budget that would be controlled
by the new executive and he/she should be held accountable for it.
This does not mean that Web services will not be used for applications that are part of the organization. One of the promises of Web services is a very flexible way of communication, which is certainly very important for any successful organization.
Building system architectures out of building blocks or components implies
building system architectures modeled after a physical world, which
might be the wrong idea. Don’t forget that the stronger you build, the
harder it is to change. It might take some real demolition to adjust
your architecture to new business opportunities. Instead, build your
system architecture like an organization. This implies a more flexible
structure. Make sure you build the visibility into that organization to
see what has to change over time to support new business opportunities.
“Commentary” articles are contributed by Linux.com and NewsForge.com readers. The opinions they contain are strictly those held by their authors, and may not be the same as those held by OSDN management. We welcome “Commentary” contributions from anyone who deals with Linux and Open Source at any level, whether as a corporate officer; as a programmer or sysadmin; or as a home/office desktop user. If you would like to write one, please email editors@newsforge.com with “Commentary” in the subject line.
Category:
- Open Source
