Slides

The nature of digital goods allows the source of the product (its building blocks) to be distributed with the product itself (binary product). Before software became a commercially viable market, this was the tradional means of development and distribution, with hackers building off each others’ works. This has recently manifested in the free
software movement, that has subsequently renamed itself (or at least a faction of the movement) to the open source software movement.

Open Source Isn’t Just For Developers Anymore: Once a developer’s hobby, a new
survey finds open source is increasingly being driven by business managers.

Life cycle:

  • Introductory: Free Software movement (geeks and nerds)
  • Growth: Linux, which spawned Android. Separately Mozilla which spawned Firefox. Hadoop etc.
  • Maturity: business strategy

Example success stories to date:

Open Source … A Revolution?

Before reading this, please review Cathedral and the Bazaar

The following looks at the development of the Open
Source Initiative. Open Source, as defined by the Open Source Definition is
software that is:

  • distributed with its source code.
  • includes a license that allows users to modify the code to fit own needs, or make improvements to the code. These improvements (bug fixes etc.) must be returned to the project for possible inclusion in additional releases.
  • has a version available at no charge (although they can charge for an additional version, this may include customer support etc.) There must be no discrimination in terms of who the free version is targeted.

  • The license remains with any modified versions, and versions are free for anyone to distribute.

Given these unusual requirements, especially:

  • the economics behind making something that is available for download for free

  • relying on external developers to voluntarily develop the code

it is worth understanding the principles that allow this to happen, the business models that may make open source an alternative, and reasons why a company might choose open source software for its software versus proprietary alternatives. Before we do this, a brief history can
establish context.

History Behind the Open Source Revolution

The following is a brief timeline of major events in the evolution of Open Source:

  1. UNIX Hacker culture, from the 1960s
  2. The GNU Project, announced in 1983
  3. The Free Software Foundation FSF, established in 1985
  4. Linux development, established in 1991
  5. Cathedral and Bazaar Paper, 1997
  6. Netscape’s Mozilla Project, 1997
  7. Firefox launched 2003, now about 25% of web browsers
  8. WordPress launched in 2003, now most popular blogging platform
  9. Hadoop created in 2005

  10. Android, unveiled in 2007, about 80% marketshare of smart phone market
    (2013)

Briefly, the UNIX hacker culture, as described in A Brief History of Hackerdom was the birth ground for the movement that was later to become known as the Open Source movement. Hackers enjoyed the pure creativity of developing software, and sharing that code with fellow hackers, in order to expand the overall knowledge-base of the hacker community (collective invention). This is therefore a very cooperative environment. The evolution, at this time, was somewhat limited with respect to the available platforms to work with, and the
ability for the community to communicate with each other. Typically small communities would evolve around specific proprietary technologies (i.e. Digital’s PDP 10 series). Eventually the technology would be discontinued and new knowledge development was required. In 1985, Richard
Stallman, tiring of this state of affairs, determined he wanted to develop a set of software tools, and an operating system, that were freely available for anyone to use, based on open standards.
He established the Free Software Foundation which supported the GNU Project (GNUs Not Unix — a recursive acronym, typical of the community!) This project is still thriving today, and the GPL license (known as
copyleft)
was developed for software developed for the GNU project.

The GPL license stipulates:

  • The source code must be freely available
  • The product must be made available for free (or at least a version, that anyone could use)
  • Any changes made to the source had to be submitted to the project leader
  • The license remains with any derivative works
  • The product can be freely distributed by anyone

The GNU project has been very successful in most respects, but it had not been able to develop a working operating system. The UNIX operating systems had fragmented (forked) and were not a viable proposition for the developing PC market. The PC market was
becoming increasingly controlled by Microsoft and the Windows Operating System. This was a very frustrating situation for the hacker community, which did not
appreciate the dominating position of the market leader (they used to have disdain for IBM for the same reason).

Some factions of the culture actually believed that software should fundamentally be free for all, and it was morally wrong to charge for it. (Stallman GNUs philosophy, hence the term “Free
Software.”) This was not the case for the entire community however. (Eric Raymond’s paper The
Magic Cauldron establishes viable business models, and hence the Open Source movement.) The fundamental issue was the correct use of the term “free.” While people assume it is
used due to the cost structure of the software, it is actually used to highlight the “freedom of use” issue. Thus the user is free to use the software as he/she desires, by accessing the
source code and making any necessary changes. The user would then share these changes with anyone who wanted to adopt them. This type of sharing and developing would lead to rapid development cycles for products.
(Sometimes daily in the case of the early days of Linux!)

This climate allowed an opportunity for someone to initiate the
development of an operating system, that would get support from the hacker community. Linus Torvold a student in Finland at
this time, decided he wanted to develop an operating system that allowed him to do more than the Minix
operating system he was working with would allow. This operating system was developed by one of his professors (Andrew
Tanenbaum), and was used in his computer science classes. He developed his first beta version of Linux, using much of the Minix code. This code was soon replaced, however, as its license was more limiting than the GPL license (of the
GNU project). Linus announced his project on a Minix discussion group (hosted at udel at the time!) in 1991.
The Linux Operating System is the outcome of that early beginning. The excellent essay: In the Beginning was the Command Line highlights the differences between the major Operating Systems.

Pre-conditions for the success of Linux include:

  • A real need for the product
  • The development of cheap communications technology (internet) promoting code sharing and communication
  • A license (GPL) that supports code sharing and development
  • Excellent leadership for the project (Linus Torvold)

As the Linux Operating system has become more popular, and the writings of Eric Raymond (a major hacker) have allowed us to understand the phenomena more clearly, other companies have paid close attention, and considered the commercial opportunities of the open source development. Netscape’s announcement of the Mozilla project was the first mainstream (previous Wall Street Darling!) company
to switch its product to open source. This allowed the movement to gain additional momentum (and subsequently manifested into the Firefox browser).

How does Open Source Work?

Successful open source projects require the following:

  • Strong leadership
  • A useful project
  • Volunteer contributions from a developer community (many of whom will be users of the project)
  • License to make this happen
  • Communications infrastructure (the internet)

Leadership and managing the project is critical to an open source success. While this may seem obvious it is critical if one wishes to get volunteer contributions of effort in developing the project, when the availability of that effort is a finite, and a scarce resource. Thus the project also needs to be very interesting and useful to the hacker community (accomplish something that is important to others, not simply the project leader), as well as provide faith that it can be successful.

Leadership involves communication to the community, and rewarding those in the community for the work they provide. Unlike traditional work, where the reward is purely economic, in the open source community it relates to ego (being recognized in the readme file), seeing work being implemented quickly (instant gratification) and being able to
take advantage of the network effects of open source development (i.e. each person and organization that contributes a little, gains from all others’ contributions).

The developer community, as a volunteer resource, is finite. This leads to markets that can only support (effectively) one open source project. We see the winner takes all phenomena in play. If there are two open source projects, the
market will tip towards one project, as a positive spiral will
take effect, the market leader will survive and become robust, others will diminish (but not die, since they are open source! Closed source projects die, open source projects lay dormant until they are picked up by someone else. This is an important distinction.)

Who Contributes?

Those that choose to contribute to an open source project are most likely those who will either use the project or benefit financially from the development of the project. The top company that contributes code to the Linux kernal is Red Hat (2013), for example. Google is also a main contributor to Linux, as it also manages the Android fork from Linux.

The Advantages of Open Source

The network effects of developing in an open source environment can be very powerful. By engaging many developers, each developer will benefit from
all other developers in the project. Thus as more developers work on a single open source project, that project will become more rewarding for each developer. The outcome of this effect is that it can lead to rapid development cycles of the
software. This development model, if implemented effectively (as in the Linux process,) is more
robust and leads to a greater evolution of the product, than in the closed
source development model. This can allow a market leader to move down the
learning curve
more rapidly, increasing its market leadership. It can also allow a
market follower to gain momentum on a closed-source market leader,
something that is very hard to accomplish for a closed source competitor
in a networked
economy!

Open source also guarantees you (if you are considering an open source
alternative) or your customers (if you are marketing an open source
solution) against lock-in. Open
source provides alternative vendor solutions, as well as the life of the
software. Thus if you purchased a close source commercial solution, that
solution is only
workable as long as the vendor that provided it remains in business, and
the vendor’s business goals remain aligned with that software solution.
An open source software solution would allow you to develop and maintain
the code yourself, or switch to another open source vendor of the code.
As a company marketing an open source solution, you can use it to your
advantage by stipulating you
are allowing your costumers freedom of choice. This issue can also be
related to the issue of being dependent on a closed source platform for your
software solution to function. If the platform was open source (Linux vs.
Windows,) software developers would have much more control of the
development of their own software!

An open source project also allows the end users’ flexibility in the
implementation of the product. This allows multiple vendors to offer the
solution, tied to their own offerings. For example, a variety of OEMs can
offer the Android solution, designed for their own particular hardware.
Proprietary software does not offer this flexibility.

One of the often cited disadvantages of open source is the notion of the
free-rider
effect. This argument has been put forth along with the essay Tragedy of the Commons. Clearly
however, in the case of open source development, the code-base is not a
finite resource that diminishes in quality with additional users, whether
they are users that contribute to the evolution of the code, or users that
simply use the product for free without contributing any resources
(economic or developmental). The latter, the free-riders, do not have a
negative effect on the resource, assuming they are not a burdon to the
community (asking questions etc.) In fact, it is likely that this group
will adopt a commercial version of an open source product, thus paying for
the customer service and after sales support and helping broaden the
market for the open source solution. Those that use the product for free,
that don’t contribute to the development effort, are going to be more
expert in the knowledge of the product, and are potential contributors to
the knowledge-base at some point in the future when additional needs for
the product arise. This group are therefore likely to get locked-in to the
product at the initial stages, and perhaps become contributors at a later
stage.

Open vs. Closed: An Economic Perspective

Open Source software is available for free, commercial versions of the
same open source software may also available at a price. These versions
include customers service, packaging, detailed instructions and free
upgrades. (Red Hat’s
version of Linux and Cloudera’s
version of Hadoop are examples.) The question is, does this
pricing structure make economic
sense. Should software be sold on a per unit basis to recover development
costs, or sold on the basis for charging for ongoing support.

The factory, industrial age, model would suggest charging on a per unit
basis for the intellectual
property of the code (closed source). While
this makes clear sense for automobiles and houses, that include
significant variable
costs per unit, software, and other digital products
tend to have very small variable costs (zero marginal costs).
The costs associated
with these products is fixed and sunk (development
costs). Thus costs associated with sales of additional units
typically are those for product support after the sale. This support is
important for the product to be effective for the users in the medium- to
long-term. Thus by charging on a per unit basis, to try to recover
sunk costs, creates an incentive for developing software that is purchased
but not used (no need for customer support). While the customer support
center is considered a cost center, the after sales support will be
limiting, which in turn will lead to under-served customers. A product
that is given away for free, but has a paid alternative that supports the
customer service infrastructure (a free alternative is required for the
Open Source license for those offering commercial versions)
makes perfect economic sense. This is the strategy adopted by Red Hat and this actually
extends the market
for the software beyond its traditional base of hackers. This argument
therefore supports the economic issues related to
pricing open source software, but it can also be applied to ALL types
of software.

Life Cycle of Open Source Process

It is important to consider the product life cycle, when considering
when to “open source” a project.

Some context has to be established, such that external developers
are going to be interested enough to contribute their finite resources to
the project.
Thus an alpha
version of the product needs to be complete. This was the case before
Linus announced the Linux Operating System to the Minix
news group. On the other hand, the project does not want to be so mature,
that it is no longer interesting for external developers (their ability to
contribute becomes marginal with a higher degree of complexity). Since
they were not part of the
evolutionary process of earlier development, it is hard to engage them at
later stages.

An argument can be made for offering a product open source, at a later
stage in the life cycle, to extend the product’s life while shifting
internal development resources to new development efforts. This will help
guarantee the life of the product for the current installed base until
they switch to the new product. Mozilla’s Firefox is an example of
this, although it took considerable time to get this project moving
forward because it began in the late stage of the browser’s
development.

Workable Business Models for Open Source

to add: Why
There Will Never Be Another RedHat: The Economics Of Open Source

As highlighted in the The
Magic Cauldron, there are a number of business models
that rationalize the open source
motive. The major models are highlighted below, refer to The Magic
Cauldron for others.

Cost Sharing Approach: As companies share common needs with
respect to technology, it can make sense to
share resources in order to develop common technologies that help each
business. Clearly this should be done in areas that do not offer
competitive advantages to single businesses, but many business processes
would fall into this category.
The Apache server
is a very good example of this. The Apache web server is the
leading server in terms of market share according to the Netcraft
survey of web servers.
Clearly a web server is important to the running of a business (critical)
and the options available to those implementing a server are:

  • Choose a proprietary server (and be locked-in to the vendor’s future
    decisions)

  • Write own server

  • Join the Apache
    Group

While choosing an open source alternative may appear foolhardy, the market
suggests this is what many are doing, and it does make sense. The code
was initially developed by the NCSA team that developed the
Mosaic browser.
As many of the team left to join Netscape, the code was
not maintained, and those using the server were not getting any support.
They decided to collaborate and continue developing the product, using the
open source model. They have proven very successful. Each contributing
participant is helping improve the code-base, thus the product is clearly
able to take
advantage of network
effects as each participant benefits from others’ participation.
Since
the Apache server includes the source code, each user is able to modify
the code to their specific needs, and the life-time of the server is
guaranteed to live beyond any one development team.

The Apache Software Foundation provides
support for the Apache community of open source software projects.

Market-Positioning Approach: This is the strategy Netscape adopted
with the Mozilla Project. Netscape was losing significant market share in
the client-side
browser market. They were in jeopardy of losing their client-side
franchise altogether. While this did not have much impact on revenue
(since most of their browsers were given away) it was important to have a
stake in the client-side to guarantee their server-side market. If
Microsoft could own the client-side market, they could start dictating
specifications that force the Microsoft server-side products to become proprietary industry
standards. This is clearly not a good situation for Netscape, or the
market as a whole. By open sourcing the client-side, they are
guaranteeing the future of the browser, without regard for any revenue
generation (since it was not generating revenue anyway)!

Market-share approach: Google open sourced Android in order to help
establish a position in the mobile operating system marketplace. By
allowing OEMs to adopt Android, and tailor it to their specific needs,
this helped Android gain wide marketshare, versus Apple’s iOS. Google is
then able to monetize this market position through its other services to
which Android creates access. Users using google maps for example on
their smartphone, from the Android interface. This also ensured Apple
would not gain a greater position in the marketplace, in which to serve up
its own propreitary applications.

Basically two features of open source enable a market share grab:

  1. the
    software is free ($s) negating the internal development cost of a new
    entrant in the marketplace

  2. the software is free (freedom), the new
    entrant can tailor the software to its own design.

Caution: Can Android’s flexibility have unintended consequences?

Free Product, Pay for Service: This is a strategy adopted by Red Hat with the Linux
Operating System and Cloudera with Hadoop.

Red Hat sells its operating system on a CD, with customer support,
instructions and upgrade options. It also offers the source code for the
product for free on its website (a requirement to comply with the open
source definition). Thus the cost for the
product is associated with the additional support that Red Hat offers.
Services such as Red Hat’s essentially broadens the market for the Linux
Operating System by
making it available to people beyond the hacker community.

The Ecology of an Open Source Marketplace

Looking at the Linux market is instructive in understanding how an open
source marketplace can work. The Linux operating system is available at
no cost, for all to download, from the internet (check freshmeat and linux.com). Many hackers have freely
contributed to the initial code developed by Linus Torvold in 1991. They
have essentially built an operating system that is more stable and robust
than any commercial competitor (Windows, Mac) in a much shorter timeframe.
Unfortunately it is only available, under these conditions, to fellow
hackers, as the complexity involved in using the system as available for
free, is too much for the average PC user. (Author included!)

This creates a market space for commercial Linux providers (like Red Hat) who can charge for
a commercial
grade version of the software that targets more typical PC users, helping
broaden the Linux franchise (since it competes with Microsoft, this is a
good thing for the hacker community).
Since the software license for Linux (GPL) allows anyone to charge for
the product, hackers do not feel this behavior is descriminating against
them (since they could also do the same). The license also requires each
commercial provider to provide a version at no cost, they do, without the
support.

The commercial providers, on top of providing customer support, upgrades
and packaging, can also target additional resources to work on parts of
the Linux system that are not as appealing to the hacker community.
Clearly one area that needs work on at this point is the development of an
effective Graphic User
Interface (GUI.) Since this is particularly
important to the commercial market (and not as important to the hacker
community) then resources can be supplemented by the
commercial providers. The GNOME project
and KDE project are focused on some of
these issues.
Commercial providers also hire some of the hacker community and therefore
provide economic incentive to develop the technology.

An Ideal Marketplace?

In an networked
markeplace we know that large
enterprises can take advantage of network effects,
reduce their average
costs and increase their
progression down the learning curve. All
these issues
point to the larger the market share, the more efficient
a company can operate. The company with the largest
marketshare is able to offer better (more useful)
products at lower costs. In fact, if the market was a
monopoly,
the monopolist would be able to maximize these
advantages. This is unlike traditional markets (auto
industry etc.) which do not scale as well, where at some
point size creates inefficiencies (decreasing returns to scale,
a function of problems with communications etc.) The problem with a
monopolist marketplace is, who can control the behavior
of the monopolist.

One can then consider that an “ideal” market, for a
networked marketplace is where the technology innovation
takes full advantage of network effects, learning curves
etc. …but the marketplace for the consumer product is
competitive. Thus we would have an open source
development model, where all development effort is
focused on developing one code-base (clearly if all
energy is focused on one solution, we would have a
better product than if there were multiple simultaneous
and fragmented efforts that are proprietary) with commercial
competition
between the vendors (like redhat linux market) who develop
commercial distributions of the product.

Crowdsourcing

Ecosystems

Wikipedia:
Ecosystems

Examples:

Intellectual Property