[Edu-sig] OSCON: Lessons Learned

[Kirby Urner]

OSCON:  Lessons Learned
by Kirby Urner, Mentor, O'Reilly School of Technology



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.

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.

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.

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.

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.

Conway's Law states that organizations end up with systems reflective of
their own internal communications.

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.

Netflix sees the benefits of this design, with some teams committing new
code at a relatively high rate compared to others.

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.

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.

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.

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.

Innovation leverages the power of a community, including contributions from
non-employees.

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.

The Open Source approach is conducive to:

(a) ownership by responsible teams, capable of responding to feedback
(b) containerization and micro-services in the cloud, the most scalable and
economical setting for enterprise computing
(c) quick on-boarding of new talent, oft recruited from the community of
contributers to one of these open projects a company values.

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

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20150730/069a276e/attachment-0001.html>