Corporate Open Source Anti-patterns

Talk originally given at FISL 2012 in Porto Alegre, Brazil. Video: https://youtu.be/anXKAcrJ5Wc. 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
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)
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...
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
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.
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
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
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
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
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!”
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
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
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!
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
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
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...
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?
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
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
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...
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!
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!