Corporate Open Source Anti-patterns


Published on

Talk given at FISL 2012 in Porto Alegre, Brazil. Video is on YouTube, albeit with suboptimal video and sound: I gave a slightly updated (and frankly, tighter and better produced) version of this at the Liferay Symposium in the fall of 2012:

Published in: Technology, News & Politics
  • slide 14: Look, a cost of open sourcing things: exerting leadership. That's non-trivial. It's not just a matter of issuing commands, and denying requests. You need to explain yourself, and discuss your rationales, or face forks and the costs of those.
    Are you sure you want to  Yes  No
    Your message goes here
  • slide 12: there's a huge good reason to avoid forking: everyone benefits from bug fixes and enhancements with minimal effort. Once you fork, then each fork has to deal with these things on its own, which increases the cost of ownership of each of the forks. Do you really want to take that on?
    Are you sure you want to  Yes  No
    Your message goes here
  • slide 8: '... making it available to everyone via its source code has no marginal cost.' False, false, false. If you want it to succeed, and to retain some modicum of control (you wouldn't want your source to run away from you, would you?), you have to manage the community. This means writing better docs than you might have done just for internal use, as well as having some kind of community forum. Open architecture docs so that someone else actually has a chance of contributing? Then there's reviewing pull requests. Don't want to do that? Then don't expect anyone to participate; but your code may get forked, and a variant you don't like or manage may actually become dominant. Just throwing it out there just makes you look lazy or stupid.
    Are you sure you want to  Yes  No
    Your message goes here
  • Are you the same Bryan Cantrill that infamously wrote to David Miller 'Have you ever kissed a girl?'?
    Are you sure you want to  Yes  No
    Your message goes here
  • @miahfost ahahaha. have you ever had a look at the source code or development? please do not refer to BTRFS if you are cosidering typical production/enterprise use-cases. i can't even begin to count mission critical bugs that have surfaced over the last year in BTRFS.

    one i remember very well, a hash collision (very likely to occur in commercial setups) yields linux's own BUG_ON();

    i've always developed free software, but i'd rather have the users choose what to do with my product or their forks of my code. don't get me wrong, GPL is fine with me, i just don't like to write GPL code.
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Corporate Open Source Anti-patterns

  1. 1. Corporate Open SourceAnti-Patterns:Doing It WrongBryan CantrillVP,
  2. 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. 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. 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. 5. Aside: The sad death of OpenSolaris • On Friday, August 13th, 2010, an internal memo was circulated by the putative Solaris leadership at Oracle: 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. • 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...
  6. 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 and — or search for “fork yeah illumos” for the full story
  7. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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: MIT/BSD/Apache GPL AGPL Public domain None MIT+GPL dual Source: • If you want a collaborative copyleft license, consider a weak copyleft like MPL v2.0 (GPLv3 compatible!)
  20. 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. 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. 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!
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.