Building a business is hard work, but it is even harder when the business starts with a faulty premise. This presentation will walk the audience through models for thinking about open source software economics, and business modelling to help understand what business ideas will likely work in a world enabled by open source software. The talk looks at:
- The underlying economics of open source software development from both the production and consumption perspectives.
- The basics of business modelling that will help folks understand the risks and strengths of open source licensed software.
- The pitfalls and dangers of getting the model wrong.
- Several case studies in successes and failures in the space.
- A way to think about the use and abuse of open source software foundations.
SCaLE Desc: https://www.socallinuxexpo.org/scale/17x/presentations/there-no-open-source-software-business-model
Further Reading:
They're backed up with the following writing:
https://medium.com/@stephenrwalli/there-is-no-open-source-business-model-cdc4cc20238
https://medium.com/open-source-communities/ask-not-what-your-community-can-do-for-you-b26546197a35
https://medium.com/@stephenrwalli/there-is-still-no-open-source-business-model-8748738faa43
https://medium.com/@stephenrwalli/sustaining-open-source-software-4a62a4b6d0f3
7. 1950 1960 1970 200019901980 2010
Code sharing
At Princeton
IAS in late
1940s
IBM “SHARE”
Conf & Library
Begins 1953
DECUS
Conf & Library
Begins 1962
MIT Project
Athena Begins
1983
1BSD Released
1977
AT&T Shares
First UNIX tapes
early-70s
Free Software
Foundation
Launches 1985
2nd DoJ vs IBM begins
“Software Bundling
is Anti-competitive”
1969
IBM response is to
unbundle HW, SW, &
services pricing
1st DoJ vs IBM
Consent Decree
“Hardware Bundling
is Anti-competitive”
1956
Open Source
Definition 1998
USENIX Begins
1975
Linus Releases
Linux 1991
Apache httpd
Released 1995
Apache Software
Foundation 1999
OSDL Forms
2000
OSDL Re-forms as
Linux Foundation
2007
U.S. Congress
Adds Computer
Software to
Copyright Law
1980
GCC
1987
emacs
1975
We’ve collaborated on software since we’ve written software
Writing good software is hard work
8. 1950 1960 1970 200019901980 2010
Code sharing
At Princeton
IAS in late
1940s
IBM “SHARE”
Conf & Library
Begins 1953
DECUS
Conf & Library
Begins 1962
MIT Project
Athena Begins
1983
1BSD Released
1977
AT&T Shares
First UNIX tapes
early-70s
Free Software
Foundation
Launches 1985
2nd DoJ vs IBM begins
“Software Bundling
is Anti-competitive”
1969
IBM response is to
unbundle HW, SW, &
services pricing
1st DoJ vs IBM
Consent Decree
“Hardware Bundling
is Anti-competitive”
1956
Open Source
Definition 1998
USENIX Begins
1975
Linus Releases
Linux 1991
Apache httpd
Released 1995
Apache Software
Foundation 1999
OSDL Forms
2000
OSDL Re-forms as
Linux Foundation
2007
U.S. Congress
Adds Computer
Software to
Copyright Law
1980
GCC
1987
emacs
1975
Copyright Law forced almost 20 years of license
experiments to allow us to keep sharing
DEC Ultrix
1984
SunOS
1983
OSF/1
1992
Red Hat
1993
9.
10. Choosing a License is a Social Contract
License reciprocity is not about software freedom; it’s a community decision.
23. If your core
competency is
delivering
software,
then the
software is:
• Core value proposition to customers
• Complement value add to the core value
proposition
• Context (i.e. non-core competency)
24.
25. New market
Disruption
• Is there a large group of people who
historically have not had the money,
equipment or skill to do this thing for
themselves?
– OR –
• To use the product or service, do
customers need to go to an
inconvenient, centralized location?
Low-end market
Disruption
• Are there customers who would be happy to
purchase a product with less (but good
enough) performance?
– AND –
• Can we create a business model that enables
us to earn attractive profits at the discounted
prices?
• Is the innovation disruptive to ALL of the significant incumbent firms in the industry?
• If it appears to be a sustaining innovation to one or more significant players in an industry, then
the odds are stacked in that firm's favour, and the new entrant unlikely to win.
Then
The Innovator’s Solution, Clayton Christensen
26. If your core
competency is
delivering
software,
then the
software is:
• Core value proposition to customers
• Complement value add to the core value
proposition
• Context (i.e. non-core competency)
27. Building a
project
community in
context
spaces:
• Validates the approach to a problem
• Demonstrates expertise that can be used in
recruitment
• Demonstrates committed values to
collaboration amongst developers that further
recruitment goals
28. Building a
project
community in
complement
value-add
spaces:
• Creates stickiness/inertia for the core value.
• Creates experts, advocates, and evangelists
around the technology
• Hardens the complements with new
configurations and contributions
• Captures direct value to the complements
(indirectly to the core)
• Is possibly disruptive to competitors
29. But –
publishing your
core value
proposition
under an open
source license:
• Makes potential partners into competitors
• Allows savvy IT consumers to avoid becoming
customers
• Creates confusion for the sales and marketing
team
30. If you invest in building community around the
project that sits on your core value proposition:
• You create tension when competitors and partners and advanced IT users
contribute value they want in your core value proposition.
• The power of innovation capture in community around a complement becomes
the problem of innovation dilution in your core value proposition.
• You accelerate the creation of a community of early adopting users that aren’t
interested in paying for your software, instead of creating early
adopting customers that understood your product solution sufficiently to give you
money.
33. Projects are interesting buckets of technology
developed collaboratively by like-minded engineers
34. Projects are interesting buckets of technology
developed collaboratively by like-minded engineers
Products solve customer problems and money is
exchanged for perceived value
37. • Will contribute time to solve
their problems
• Look to community and project
for solutions
• Community wants transparency,
meritocracy, and agency
• Need guidance and tool support
• Become technology advocates
• Become knowledgeable experts
• Make your solution sticky
• They want to buy something
• Look to the product to solve
their problems
• Customers have expectations
based on a cost
• Community/project is a test for
product
• May participate in community
Community Customer
vs
38. Community vs Partner
• Will contribute time to solve
their problems
• Look to community and project
for solutions
• Need guidance and tool support
• Become technology evangelists
• Become knowledgeable experts
• Make your solution sticky
• They want to co-market
products
• Look to the product to cross-sell
• Partners have contracts defining
business relationships around
products/services
• Community/project is a test for
product
• May participate in community
40. In the World of Atoms:
You choose your
neighborhood for very
personal reasons
41. Three Sorts of Neighbours in Your Community
The people that simply want
to live there ….
42. Three Sorts of Neighbours in Your Community
The people that simply want
to live there ….
The people that report
potholes and trash, etc. ….
43. Three Sorts of Neighbours in Your Community
The people that simply want
to live there ….
The people that report
potholes and trash, etc. ….
The people that organize
the block party, pick up
trash, etc. ….
44. Three Sorts of People in Your Project Community
The people that simply want
to use the software
The people that report bugs,
offer ideas for features, etc.
The people that
contribute code,
documentation, use cases,
etc.
45. Rules of Thumb and Orders of Magnitude
For every 1000 users, …
… a 100 will file a bug, …
… out of which 10 give you
a patch, …
46. Rules of Thumb and Orders of Magnitude
For every 1000 users, …
… a 100 will file a bug, …
… out of which 10 give you
a patch, …
… out of which 1 actually read
your contribution guidelines.
47. Three On
Ramps for
Community
Building
• How do you encourage people to use your project?
(Because that’s where you’ll find your developers)
• How do you encourage developers to experiment?
(Because these are your future contributors)
• How do you encourage developers to share their
work?
(This is the growth & success of your software)
48. “The customer didn’t want a quarter inch drill. What they wanted was a
quarter inch hole.”
Theodore Levitt
49. Parking your identity brand on any open source project you own, instead of
the product/solution your customers buy, creates confusion for your
messaging to customers.
50. Open Source Software is about
Engineering Economics
There is NO Open Source Software
Business Model
52. Customers versus Community
(Money vs. Time; Expectations are different; Conversations are different)
Partners versus Community
(Don’t mix business with community)
53. Customers versus Community
(Money vs. Time; Expectations are different; Conversations are different)
Partners versus Community
(Don’t mix business with community)
Products versus Projects
(Success metrics are different; OKRs and KPIs are different)
56. Last Quick
Examples …
Kubernetes is a project; AKS and GKE are products
OpenStack is a collection of projects; Helion and
RDO are products
Linux is a project; Fedora is a distro project; RHEL
is a product