Slides from my latest talk at the Linux Foundation Open Source Summit in Lyon (October 2019). https://osseu19.sched.com/event/TLLb/sustaining-open-source-software-stephen-walli-microsoft

2. ‘Open Source’ is unsustainable

3. We know this because … everyone is struggling
• Commercial collaborations struggle to find significant projects
• Individual developers struggle to support their own projects
• End users struggle with insecure projects
• Startups struggle with partners/users using projects (not buying
products)

4. One way we could have this conversation is to ask:
Who isn’t struggling?

5. History is Important

6. 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
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

7. Collaboratively-Developed Liberally-Licensed Software is
about Engineering Economics

8. 1980 Copyright applied to Computer Software
After ~20 years of experimentation
Open Source Definition
Creates the broadest surface area for engineers collaborating
Served us well for 20 more years
OSI hosts a transparent discussion about the OSD and licenses

9. 1980 Copyright applied to Computer Software
After ~20 years of experimentation
Open Source Definition
Creates the broadest surface area for engineers collaborating
Served us well for 20 more years
OSI hosts a transparent discussion about the OSD and licenses

10. Democratization

12. Everything that could be digitized …

13. Everything that could be democratized …

14. The Democratization of Software

15. Anyone Can Learn to Program Now …

16. “Software isn’t eating the world.”
— Not Marc Andreesen

17. “We are drowning in software – most of it mediocre,
duplicative, and bad.”
— Still Not Marc Andreesen

18. 2012 Octoverse 4.6M+ repositories
2016 Octoverse 19.4M+ repositories
2018 Octoverse 96M+ repositories

19. Cooking Software and Where You Choose to Live

20. We All Know How To Fry An Egg

21. We May Get Good Enough To Cook For Friends

22. We May Tackle
The Holiday
Meal

23. We May Get
Good At A
Particular Type
of Cooking

24. Restaurant

25. We go from
this …

26. … to this

27. This has implications
There is likely a team with specialized roles
There is an added layer of communications
There are standards to be met and maintained
There needs to be reliable and repeatable delivery

28. This has implications
There is likely a team with specialized roles
There is an added layer of communications
There are standards to be met and maintained
There needs to be reliable and repeatable delivery
There are customers
There is a business to run
There are regulations that need to be served
There is money to be managed
There are employees to be hired, motivated

29. … so to with software
There is likely a team with specialized roles
There is an added layer of communications
There are standards to be met and maintained
There needs to be reliable and repeatable delivery
There are customers
There is a business to run
There are regulations that need to be served
There is money to be managed
There are employees to be hired, motivated

30. Community and Your Neighborhood

31. In the World of
Atoms: You choose
your neighborhood
for very personal
reasons

32. 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. ….

33. 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.

34. 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.

36. We’ve collaborated on software since we’ve written it
The OSD creates the broadest surface for collaboration
Software has been democratized and we’re drowning in it

37. We’ve collaborated on software since we’ve written it
The OSD creates the broadest surface for collaboration
Software has been democratized and we’re drowning in it
Software production is like cooking
Building community is an orders of magnitude problem

38. Everyone wants ‘open source’ to be sustained better
• Commercial collaborations finding significant projects
• Individual developers with their own projects
• End users consuming projects
• Startups creating projects

39. Startups Creating Projects

40. Startups Creating Projects
• Liberally licensed, collaboratively developed projects drive engineering
economics – Build vs Buy vs Borrow + Share – Orders of magnitude value capture
• Most problems are business model design problems, not ‘open source’ problems
• Don’t confuse projects and products; don’t confuse community with customers
• Customers have money and no time; community has time and no money
• Don’t confuse early adopting community with Moore’s early adopting customers
– there is no conversion ratio
• Publishing your core value proposition to customers needs to be done
thoughtfully
Links: https://bit.ly/2pkAtYX https://bit.ly/2p9lJML

41. End Users Consuming Projects

43. In a world of promiscuous
sharing communities, would
you eat this ice cream cone?

44. End Users Consuming Projects
• This is a software consumption problem, not an open source problem
• Learn basic software hygiene – wash your hands
• It’s street vendors versus restaurants
• It’s product quality software-at-scale versus a random node package
• Always ask, ‘Who owns this software?’

45. Individual Developers with Their Own Projects

46. Individual Developers with Their Own Projects
• This is the cooking metaphor
• Freelancing is a perfectly well understood business
• You are allowed to say, ‘No’
• Chefs and professional kitchens and money
• Crowd funding support probably doesn’t scale
• Brokerages

47. Commercial Collaborations Finding Significant Projects

48. Foundations

49. Ingo’s Number Crunch (2010)
http://openlife.cc/blogs/2010/november/how-grow-your-open-source-project-10x-and-revenues-5x

50. Committers
Contributors
Community
EcosystemProject
Products
Services
Books
Training
Customers
The Evolution of an Open Source Project

51. Committers
Contributors
Community
EcosystemProject
Products
Services
Books
Training
Corporate
Contributors
Customers
The Evolution of an Open Source Project

52. Committers
Contributors
Community
EcosystemProject
Products
Services
Books
Training
Corporate
Contributors
Customers
The Evolution of an Open Source Project
IP Neutrality,
Liability Management
http://www.ifosslr.org/ifosslr/article/view/64
Business Management,
Marcomms, Events

53. May 1999
27,623 LoC
The Apache Software Foundation Forms June 1999
https://www.openhub.net/p/apache

54. May 1999
27,623 LoC
The Apache Software Foundation Forms June 1999
https://www.openhub.net/p/apache
Aug 1999
87,571 LoC

55. Modern Foundations

56. Engineering/
Partner?/
Customer?/
Committers
Engineering/
Partner?/
Customer?/
Contributors
Community
EcosystemProject
Products
Services
Books
Training
Partner/Customer
Contributors
The Evolution of a Corporate Owned Open Source Project
Setting Customer and Partner Expectations in Community is Critical

57. Engineering/
Partner?/
Customer?/
Committers
Engineering/
Partner?/
Customer?/
Contributors
Community
EcosystemProject
Products
Services
Books
Training
Engineering
Partner/Customer
Contributors
The Modern Reality of a Corporate Open Source Project
Setting Customer and Partner Expectations in Community is Critical
?

58. Engineering/
Partner?/
Customer?/
Competitors?/
Committers
Engineering/
Partner?/
Customer?/
Competitors?/
Contributors
Community
EcosystemProject
Products
Services
Books
Training
Partners/Competitors
Contributors
The Modern Reality of Corporate Open Source Collaboration
Setting Collaborator Expectations in Community is Critical
?

61. Commercial Collaborations Finding Significant Projects
• Historical foundations were project focused and provided neutrality,
IP ownership
• Modern foundations try to create ecosystems
• Ownership versus contribution controls
• Standards vs Open source – Different tools for different problems
• Vendor competitive politics in open source foundations creates
interesting stress points

62. Open Source Sustainability Problems

63. Open Source Software Problems

64. Open Source Software Problems

65. Software Problems
Business Model Design Problems
Community Building Problems
Software Hygiene Problems

66. Open Source doesn’t have a sustainability problem

67. How will you broaden the collaboration?

68. How will you broaden the discussion?
Don’t tell me how we’re supposed to make your world better
Tell me how you want to make our world collectively better

69. stephen.walli@microsoft.com

70. Photo Credits
• Chem Lab on Flickr by theterrifictc
• Chem Factory on Flickr by BASF
• Shakespeare on Flickr by tonynetone
• Berlin Wall on Flickr by Daniel Antal
• Musicians on Flickr by Jorge Bernal
• Block Buster on Flickr by Jason Kuffer
• Newspapers on Flickr by Gary Thompson
• Television family on Flickr by Paul Townsend
• Computer Room on Flickr by Alex Muse
• Books by me
• Andreessen official photo from A16z.com
• Logos all belong to their respective owners