Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Corporate Open Source Anti-patterns

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

Bryan Cantrill

July 26, 2012
Tweet

More Decks by Bryan Cantrill

Other Decks in Technology

Transcript

  1. Corporate Open Source
    Anti-Patterns:
    Doing It Wrong
    VP, Engineering
    [email protected].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