<div dir="ltr"><div>OSCON:  Lessons Learned<br></div><div>by Kirby Urner, Mentor, O'Reilly School of Technology<br><br><br><br></div>What
 the bigger enterprises are discovering, along with small and mid-sized,
 is that Open Source is not just end products, such as Perl and FireFox,
 but a way of working together to create those products, a supply chain,
 a process.<br><br>In order to attract and keep the loyalty of engineers
 who work in the Open Source way, which has proved highly productive, 
the enterprise needs to not only use, but contribute to the Open Source 
commons.   <br><br>In supporting public projects, such as Asgard in the 
case of Netflix, OpenStack in the case of HP, Linux in the case of IBM, 
companies throw their hats in the ring, demonstrating they understand 
contributing source code is a way of earning good will, while reaping 
the benefits.<br><br>Those who contribute quality code to the commons 
are seen as competent and powerful, using a currency engineers respect. 
 Money is just data after all, whereas code is what harvests and 
controls data, moves it around in the cloud.<br><br>Both Walmart Labs 
and Paypal, OSCON sponsors, provided eloquent testimony regarding their 
embracing of the Open Source way.  Governments are not far behind, with 
the UK and US both sending heads of Digital Services departments to 
deliver complementary OSCON keynotes.<br><div><br></div>Conway's Law states that organizations end up with systems reflective of their own internal communications.<br><br>These
 days, staying nimble and on top of one's game, means adopting such Open
 Source practices as having "two pizza teams" (no bigger than might be 
fed on two pizzas) each tasked with maintaining and contributing 
features to smallish, well-defined products and services.<br><br>Netflix sees the benefits of this design, with some teams committing new code at a relatively high rate compared to others.  <br><br>Loosely
 coupled services with managers highly aligned to company goals:  that's
 a recipe for success.  Monolithic proprietary applications, in 
contrast, tend to develop so many internal dependencies (including on a 
small cadre of indispensable programmers) that they encounter logjams in
 development.  The whole enterprise bogs down.<br><br>PayPal's 
name for adopting Open Source practices in-house is InnerSource.  The 
core discovery is when engineers code on the assumption their code will 
be world readable, source open, they simply write better code.  <br><br>In
 practice, the sphere of projects supported by the Apache Foundation 
defines a ready-made commons.  For PayPal, InnerSource means "Apache 
Inside" -- including such products as Spark and Tomcat, not just the 
famous web server.  For WalMart Labs, the code base includes Node.js, 
Cassandra and Mongo.<br><br>Engineers following the Open Source way do a
 better job at decoupling their projects, following the Unix philosophy 
of having many independent tools that each does something well-defined 
and discrete.  The APIs are clearer that way.  <br><br>Innovation leverages the power of a community, including contributions from non-employees.  <br><br>When
 the license keeps the source open, the company partakes of greater 
positive synergies.  Geniuses continue pouring their best thinking into 
vital enterprise assets, precisely because these assets are owned in 
common.  No one may steal and possess exclusively of others:  that's the
 hallmark of Free (as in liberated) Software.<br><br>The Open Source approach is conducive to: <br><br>(a) ownership by responsible teams, capable of responding to feedback <br>(b) containerization and micro-services in the cloud, the most scalable and economical setting for enterprise computing <br>(c)
 quick on-boarding of new talent, oft recruited from the community of 
contributers to one of these open projects a company values.<br><br>The 
Open Source way includes using version control and such Agile techniques
 as test driven development (TDD is featured along our Python Track here
 at OST).<br><br>As Allison Randal summarized recent history in 
her keynote: in the distant dino past of thirty years ago, a lot of 
people assumed Open Source was slated to always be playing catch up i.e.
 the "community edition" would always be second fiddle to what the 
closed source engineers were doing.<br><br>That world view has been 
turned inside out in many critical domains, where open also means 
transparent, as in trusted, as well as best of breed.  <br><br>Who wants
 to build "the cloud" using tools owned and controlled by a tiny few?  
Open Source is a way to insure interoperability and hence long term 
profitability.  Embracing the Open Source way is out of economic 
necessity, not just altruism.<br><br>Open Source is about keeping 
control out of controlling hands and then competing (with "secret sauce"
 i.e. "value added") within that shared context.  As it turns out, the 
business case for "keeping it open" is uber-compelling.  OSCON's long 
list of big name sponsors is evidence of what's accepted as common 
wisdom these days:  Open Source has won.</div>