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

1. Corporate Open Source
Anti-Patterns:
Doing It Wrong
Bryan Cantrill
VP, Engineering
bryan@joyent.com
@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:
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. 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:
MIT/BSD/Apache
GPL
AGPL
Public domain
None
MIT+GPL dual
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!)

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!