Corporate Open Source Anti-patterns

Talk originally given at FISL 2012 in Porto Alegre, Brazil. Video was on YouTube but regrettably taken down. Fortunately, I gave a slightly updated (and frankly, tighter and better produced) version of this at the Liferay Symposium in the fall of 2012: https://www.youtube.com/watch?v=Pm8P4oCIY3g

Transcript

1. Corporate Open Source
   Anti-Patterns:
   Doing It Wrong
   VP, Engineering
   bryan@joyent.com
   Bryan Cantrill
   @bcantrill
   

   View Slide

2. Open source: A commercial history
   • In the beginning, there was nothing but source code
   • Starting in 1983, IBM led the move to proprietary
   enterprise software with its “object-only” model
   • The 1980s and 1990s saw a boom in proprietary
   software centered on the PC — with Microsoft as its
   spiritual and commercial leader
   • By the late 1990s, proprietary software gave rise to
   monopolistic behavior (“vendor lock-in”); open source
   became commercially attractive despite its shortcomings
   • Open source started with infrastructure software:
   languages/runtimes (Perl, Python), OSs (Linux, BSD),
   DBs (MySQL, Postgres) and web servers (Apache)
   

   View Slide

3. Open source in the 2000s
   • It became acceptable (and then, with the Dot Com Bust,
   required) to use open source wherever reasonable
   • Companies would occasionally contribute their changes
   back to the open source software they used, but rarely
   did they open the software they themselves invented
   • The counterexamples were in domains in which open
   source became a hard requirement, e.g. operating
   systems and language runtimes
   • Alone among the proprietary Unix vendors, Sun elected
   to take the arduous path of open sourcing its operating
   system to assure its vitality...
   

   View Slide

4. Aside: The birth of OpenSolaris
   • Sun open sourced Solaris (OpenSolaris) under a weak
   copyleft (CDDL) in 2005, starting with DTrace
   • The OS was developed henceforth in the open, making
   it one of the largest and most important bodies of
   software to leap the chasm from proprietary to open
   • While Sun did some things right, lots of things were
   done wrong; by the time Oracle bought Sun in 2010, the
   community was rudderless and adrift
   • It became quickly clear that Oracle had absolutely no
   interest in the OpenSolaris community — or in open
   source for that matter
   

   View Slide

5. Aside: The sad death of OpenSolaris
   • On Friday, August 13th, 2010, an internal memo was
   circulated by the putative Solaris leadership at Oracle:
   • Oracleʼs depraved act — closing an open system —
   greatly alienated the community and accelerated a
   Solaris diaspora that was already underway
   • Fortunately, the source was still out there...
   We will distribute updates to approved CDDL or other open
   source-licensed code following full releases of our enterprise
   Solaris operating system. In this manner, new technology
   innovations will show up in our releases before anywhere else.
   We will no longer distribute source code for the entirety of
   the Solaris operating system in real-time while it is
   developed, on a nightly basis.
   

   View Slide

6. Aside: The rise of illumos
   • A new community rose from the ashes of OpenSolaris,
   and exercised open sourceʼs most important right: the
   right to fork
   • Dubbed “illumos” (from illuminare, Latin for illuminate)
   and made available in August, 2010
   • Essentially all of the Solaris diaspora landed in illumos,
   including the core of key technologies like ZFS, DTrace,
   zones and networking virtualization
   • Two years later, illumos is thriving with an established
   track record of innovation, a healthy community, and
   multiple distributions (e.g., OmniOS, Joyentʼs SmartOS)
   • See http://illumos.org and http://smartos.org — or
   search for “fork yeah illumos” for the full story
   

   View Slide

7. OpenSolaris as object lesson?
   • The saga of Solaris/OpenSolaris/illumos contains many
   lessons about both the power of open source and of the
   challenges of moving from proprietary to open
   • It seems that some of the mistakes that Sun made with
   OpenSolaris have been (or are being) made by other
   companies with other systems
   • It is clear that these mistakes are often born of good
   intentions — they are not errors, they are anti-patterns
   • By studying the corporate open source anti-patterns, we
   can try to learn what not to do
   

   View Slide

8. Anti-pattern: Inverted thinking
   • Itʼs very tempting (and natural) to think of open source in
   terms of: What will this buy me?
   • This is the wrong way to frame the problem: the benefits
   of open source are often secondary and tertiary
   • Should be framed instead as: What does this cost me?
   • Reminder: software costs nothing to manufacture;
   making it available to everyone via its source code has
   no marginal cost!
   • The only cost can be from someone who would have
   paid you, but will instead take the source and
   productize, operationalize and support it on their own
   

   View Slide

9. Anti-pattern: Wishful thinking
   • People who would take your software and do everything
   else on their own werenʼt going to pay you anyway
   • The choice is not if they pay you or not (no one is
   getting paid), but rather if they run your software or not
   • Internalizing this as the choice allows one to focus on
   those secondary and tertiary benefits of open source:
   • For most bodies of software, there is marginal gain to
   have more people running it (e.g., bug fixes, support of
   esoteric platforms, etc.)
   • For most bodies of software, there are non-linear
   network effects — in proportion to the API surface area
   

   View Slide

10. Anti-pattern: No source!
    • An amazing number of corporate open source efforts
    are announced without source code!
    • For example, HP and the loud announcement of their
    “intent” to open source webOS in December 2011 — still
    not available as of July 2012 (& the team has since quit)
    • This is a mistake so stupid, it can only be due to open
    source being an entirely non-technical decision — it
    reeks of emphasizing perception over reality
    • Donʼt do this — you gain nothing (duh!) and you lose
    credibility (perhaps forever)
    • In the words of Bob the Angry Flower, “This one is
    stupidly simple, people!”
    

    View Slide

11. Anti-pattern: Forkaphobia
    • When software is large and complicated, one is naturally
    afraid of a communityʼs efforts being divided by a fork
    • But there is a forking paradox: the easier it is to fork the
    software, the more difficult it is to fork the community
    • If forking is easy, experimentation with ideas can be
    pursued while still remaining safely downstream
    • But if forking is difficult, experimenters are reduced
    to dissenters — resulting in endless arguments (best
    case) or divorce (worst case)
    • Corporate entities must therefore encourage forking —
    open source that cannot be forked has no vitality
    

    View Slide

12. Anti-pattern: Governance orgy
    • Forkaphobia is such a destructive anti-pattern that it
    breeds its own anti-patterns: if and where forking is
    technically difficult, the community is forced to “agree”
    • Of course, people donʼt actually agree — so systems of
    governance are established to determine a groupʼs will
    • This gives rise to a focus on governance (constitutions &
    elections) grossly out of proportion with any project
    • Further, elections have two corrosive side-effects:
    politics and losers — both of which factionalize and
    undermine community
    • If corporations are not forkaphobic, they are much less
    likely to engage in a governance orgy
    

    View Slide

13. Anti-pattern: Ersatz democracy
    • When corporate entities are contemplating open source,
    itʼs much easier to establish governance than it is to
    actually respect that governance
    • The only thing worse than paralyzed and metastasized
    democracy is ersatz and farcical democracy
    • Democracy is not an implication of open source; no
    corporate entity should feel an obligation to create a
    democracy that it in fact has no intention of observing!
    

    View Slide

14. Anti-pattern: Eschewing leadership
    • Good open source projects have good leadership!
    • Consensus is great when you have it, but you need
    leadership when you donʼt
    • Corporate entities shouldnʼt fear exerting leadership on
    projects that their engineers themselves conceived
    • Like any good leadership, it should be exerted in a
    transparent and inclusive way — the “B” in BDFL
    • The challenge for corporations is that they must give
    visibility to the employees that are the technical leaders
    • This requires corporations to fully internalize the truism
    that organizations donʼt innovate — people do
    

    View Slide

15. Anti-pattern: Eschewing ownership
    • It has become fashionable for corporations to open
    source software by giving it to a foundation
    • Even though it is not technically the case, this says that
    the software is, in fact, worth nothing
    • It sends the message that the company is stepping
    away from the technology and leaving it for dead
    • Foundations are not simple: if they are to be tax exempt,
    they need independent directors and capital
    • To give software to a foundation one is required by law
    (in the US, anyway) to eschew leadership
    

    View Slide

16. Anti-pattern: Competitive paranoia
    • Very common to believe that your competitor canʼt wait
    for you to open source your stuff so they can rip it off
    • Newsflash: your competitor thinks youʼre a jackass
    • Of course, itʼs your competitor thatʼs the jackass —
    thatʼs why they think youʼre a jackass!
    • (If you donʼt believe this, go work for your competitor)
    • Paradoxically, not-invented-here (NIH) is much stronger
    than the will to survive — companies will gladly go out of
    business before they adopt their rivalʼs advances
    • The companies that adopt your technology are nearly
    tautologically not your competitors...
    

    View Slide

17. Anti-pattern: Anti-collaborative licensing
    • One way to address competitive paranoia is to use a
    strong copyleft license that takes either a broad (GPLv2)
    or absurdly broad (AGPL) definition of derived work
    • Strong copyleft was an interesting experiment (and
    arguably essential to the proliferation of open source),
    but it has generally outlived its usefulness
    • Strong copyleft excludes competitors — but also
    collaborators: today, strong copyleft prevents cross-
    pollination across open source code bases!
    • For example, GPLv2 has prevented the integration of
    open source technologies like DTrace and ZFS in Linux
    • Was it the intent of those who licensed their work under
    GPLv2 to erect walls within open source software?
    

    View Slide

18. Anti-pattern: Anti-collaborative licensing
    • Many have decided that this is not, in fact, their intent;
    the GPLv2 is in decline relative to MIT/Apache/BSD:
    • And since this analysis, the decline has accelerated:
    GPLv2 is now at 36.32% as of the end of June 2012
    

    View Slide

19. Anti-pattern: Anti-collaborative licensing
    • The 50 most watched Github projects shows a more
    acute decline in the GPL relative to MIT/BSD/Apache:
    Source: http://ostatic.com/blog/the-top-licenses-on-github
    • If you want a collaborative copyleft license, consider a
    weak copyleft like MPL v2.0 (GPLv3 compatible!)
    MIT/BSD/Apache
    GPL
    AGPL
    Public domain
    None
    MIT+GPL dual
    

    View Slide

20. Anti-pattern: Dual-licensing for profit
    • Some have opted for a dual-licensed model in which the
    software is available either for free under a strong
    copyleft license or for a fee under a proprietary license
    • This encourages bad behavior by the commercial entity:
    the company is incentivized to spread fear, uncertainty
    and doubt as to the strongly copylefted variant
    • The dual-licensed model is only possible with a strict
    copyright assignment to the commercial entity for all
    contributions
    • Copyright assignment is so fraught with peril that it is its
    own anti-pattern...
    

    View Slide

21. Anti-pattern: Demanding assignment
    • Need to be very careful about demanding assignment —
    it relies on a community trusting a commercial entity
    • Unfortunately, bad actors in open source (which is to
    say, Oracle) have forever shattered that trust
    • Corporate entities may (and indeed, should) have a
    contributor agreement to protect the source base from
    third-party claims of copyright and patent infringement
    • Copyright assignment still might make sense for
    established projects — but it should always be treated
    as a social contract
    • Be aware that copyright assignment will create a
    permanent asymmetry in the community!
    

    View Slide

22. Learning from anti-patterns
    • The anti-patterns shouldnʼt necessarily be treated as
    hard-and-fast rules — local conditions vary
    • In the illumos community, we are mindful of these anti-
    patterns — they have shaped who we are (and arenʼt!)
    • At Joyent, we avoid these anti-patterns in the open
    source projects that we lead: node.js and SmartOS
    • Open source is absolutely essential to our business —
    as consumer, contributor and innovator!
    • We are undoubtedly making mistakes — just hopefully
    new ones...
    • Come to my FISL talk in 2022 to learn about them!
    

    View Slide