Capabilities for Open Source Innovation: Background

Over the past decade, I’ve been researching open source and technology innovation, partly through employment at multiple different companies who engage in open source, and partly through academic work towards completing a Master’s degree and soon starting a PhD. The heart of this research is looking into what makes companies successful at open source and also at technology innovation. It turns out there are actually many things in common between the two.

Organizational Capabilities

One of the lines of research that’s relevant to this topic explores organizational capabilities. These capabilities are the knowledge that individuals have at a company, but they’re also the abilities the company as a whole has built into their processes, into their business, and into their employees. Capabilities can be learned over time, so a company isn’t frozen to a fixed point of capabilities that can never change, but it does take time to build up new capabilities or strengthen existing capabilities. If a company doesn’t have the capabilities to tackle a totally new strategic area or a totally new project, then deciding to enter that new area is only the first step of a learning process. Organizational capabilities also affect strategic outcomes, so if two companies make the same strategic business decision—no matter how good that decision is in the context of their target market—one company may succeed because it has the organizational capabilities required to achieve that strategic goal, while the other company fails because it is lacking necessary capabilities.

Open Innovation

Another relevant line of research explores open innovation, which was first proposed by Henry Chesbrough in the 2000s, but has been through a number of different iterations over the decade plus since then. In some ways, open innovation is similar to open source, but it’s not quite open source and people get confused about that. The fundamental concept of open innovation is that innovation in general—and this can be technology innovation or business innovation—can be accelerated if companies are willing to go outside their boundaries and either share innovative ideas externally or assimilate external innovative ideas internally. An idea that a company shares outward may be one that they can’t profit from directly, but the other company can help them profit from it, so together they can both make more profit than if the idea just died internally. Being open to assimilate ideas that other companies created means having capabilities (processes and knowledge) around taking that innovation from outside and building it into your own innovation internally.

Open innovation is related to open source in the sense that open source does include both concepts of sharing your internal innovation externally and bringing external innovation internally. But it goes beyond just sharing ideas and knowledge, to actually sharing source code externally and bringing external source code inside the company. If your company is successful at open innovation, you have a set of capabilities towards being successful at open source. You’re not all the way there, but it’s a good boost to getting there.

Much of the change a company makes to become capable in open source has to do with thinking slightly differently about how you create and capture value for customers. It’s no longer a matter of creating all value yourself and capturing all value yourself. Perhaps you created some code, someone else created some more code, and yet another someone created even more code, and you’re getting much more value out of the code that you all develop together than you’re putting into it. Which means you can actually be more effective at driving innovation by not doing all the work yourself. A big part of the change is a matter of getting comfortable doing development in a way that is not purely under your direction. Work isn’t driven under one company from someone up on high, down through a hierarchy, to a set of individual developers. Instead, the work involves relationships across company boundaries.

Levels of Engagement

There are different kinds of relationships across company boundaries. Some relevant research into these relationships is around companies’ levels of engagement in open source and how that impacts their success, their failure, the capabilities they need to succeed, and ultimately their effectiveness in open source and in delivering value to their customers from open source.

Level 1: The lowest degree of engagement is often called Inner Source. A company at this level has taken some ideas from open source, but isn’t consuming external code or sharing code externally, they are just collaborating internally a little more like an open source project.

Level 2: The next step up is to use open source, but purely as a consumer, bringing in external code.

Level 3: Companies at this level deliver open source to customers, either straight up, combined with other open source software, or combined with proprietary software.

Level 4: Companies at this level lead an open source project that they created. They release their code as open source, but they don’t really have an active external community.

Level 5: Companies at this level participate in external projects by contributing code, sponsoring, or supporting the project in other ways, but the relationship is somewhat one-directional or distant. Their participation isn’t highly active, but they still benefit from contributing patches and other support, and getting back the source code.

Level 6: The highest degree of effective open source participation is companies who participate as co-leaders. These companies don’t just throw patches over the wall at the open source project, but take the time to actively share their needs with the open source project, to actively advocate for the directions that they think the project needs to go, and contribute developer time to the project. That doesn’t mean they control the project, in fact, there’s a great deal of value in having many perspectives contributing ideas and together negotiating the direction of the project, for the benefit of everyone involved. At this level, you find companies participating as equals with individual open source developers and respecting them for their technical expertise and role in the project. There’s some nuance here, in terms of how to be effective as a co-leader in an open source project, but the biggest thing to understand is that companies who take that step forward are more effective and get more value out of open source projects.

Other Relationships Across Company Boundaries

Some other relevant research is around more traditional collaborative innovation approaches like strategic alliances, where companies get together under a strong NDA and binding contracts to do some development. These kinds of alliances generally produce proprietary software rather than open source, but some of the research around how strategic alliances work and how companies participate in them is similar to the way companies participate in open source, so the research is relevant.

Research into standards bodies with patent pools is also relevant. The patent pools give the participating companies some degree of protection from each other, which makes them more comfortable all sharing together in terms of the strategic direction and the advancement of the technology. Open source foundations often play a similar role when they include some aspects of patent calming within their contribution and licensing terms, so the participating companies don’t have to be afraid of each other. They can set aside defensive tactics and focus on what’s best for the technology, what’s best for innovation, and what’s going to give all the companies the best value together.

Internal and outsourced R&D also have many similarities to open source. The way an internal R&D department works, or the way a company relates to an outsourcing partner, are in fact very similar to the way that a company relates to an open source project, or the way that companies relate to each other within an open source project. Both open source and more traditional R&D approaches are examples of development happening in a different group, and they require building the same kinds of relationships across the different groups.

Another relevant piece of research is licensing as acquisition. Licensing technology or components as part of a larger effort in innovation is an incredibly common pattern. When one company needs an innovative technology that another company has already developed, they negotiate a license with the other company to use that technology rather than spending the time and money to develop it in-house. The difference between this form of proprietary licensing and open source licensing, is that open source makes the whole process of licensing external innovative technology much easier, because you don’t have a long negotiation before you get to the point that you can license that technology. Open source technology is just freely available under the open source license, you can pick it up, try it, and choose whether you want to integrate it or not. This is one of the concrete ways that open source accelerates innovation, because it makes it faster and easier for companies to acquire innovative technologies and components through licensing.

Technology Innovation and Open Source

The overall focus of this background study was looking at existing research into technology innovation and existing research into open source, and exploring the similarities between the two sets of research. I didn’t start off with specific assumptions on what I might find, just an idea of cross-referencing between the two, since the people who research the two topics don’t seem to talk to each other, read each other’s research, or attend the same conferences. What I found is that the organizational capabilities required to succeed at technology innovation are a very near match to the organizational capabilities required to succeed at open source. I mapped out more than 100 shared characteristics, but I’ll summarize the top few.

Collaborate with external communities: You will innovate faster by taking advantage of available knowledge and resources out in the open, than by trying to do it all yourself internally. Source code is one form of external knowledge and resources that you can use to help your company innovate faster.

Share ideas outward: Tightly grasping every idea you have internally is generally not the path of greatest advantage. You can help accelerate the entire pool of innovation if you’re willing to share ideas outward, and see if other people are willing to contribute to successfully implementing those ideas.

Organizational learning, assimilate ideas inward: Observing external technology innovation or open source isn’t enough, you have to have capabilities in place to assimilate external knowledge and external code.

Efficiency of reuse/modification: In both open source and more general technology innovation, you get an acceleration of innovation from the reuse or modification of existing innovation. There are slightly different mechanics around that in proprietary technology innovation and open source, but the organizational capabilities are basically the same.

Strategic approach to customer value: One set of authors (Morgan & Finnegan) called this “strategic open source”. It’s about taking an approach to customer value where you’re not just blindly assuming that the only way to produce customer value is to do everything yourself in-house, but instead consciously examining your customers’ needs, the capabilities you have, the technology you have, and strategically planning out which pieces you should outsource, which pieces you should build in-house, and which pieces would benefit from inviting customers to participate in creating that value, because it will serve their needs better if they’re involved.

Low barrier to entry: In open source this is partly related to the licensing, which makes it easy to pick up the source code and use it. More generally, it has to do with the fact that innovation moves faster as a whole, across an industry, when we aren’t working in tightly constrained silos. If every company across the cloud industry was working in a silo, we would pretty much have Amazon leading the pack, a couple of other companies struggling to try to do something similar, and that’s it. The barrier to entry for any one company entering the industry would be far too high. When a number of companies are willing to share their ideas and work together, the combined brain power of all of those companies together is orders of magnitude larger than any one company on its own.

Conclusion

If you only take away one thing from this post, make it this: open source is mostly just technology innovation. If your company has already developed the capabilities for technology innovation, then open source won’t be a big hurdle. There are a few new things to learn, but it’s not as radically different as you might think. If your company hasn’t really embraced technology innovation yet, you’ll find open source and any other approach to technology innovation challenging. The good news is, the capabilities that you need to learn to effectively engage with open source, are actually pretty much the same capabilities you need to learn to effectively innovate at technology anyway. And, open source is a particularly easy way to learn those capabilities, because open source communities are generally eager to teach people how to participate and how to succeed with their project. Your competitors in proprietary technology innovation, on the other hand, probably consider every aspect of their technology a closely guarded secret, and are unlikely to have any interest in sharing or helping you learn from their successes and mistakes.

Transitions in Open Source Initiative leadership

What we call the beginning is often the end
And to make an end is to make a beginning.
The end is where we start from.
— T.S. Elliot, “Little Gidding”

Serving as president of the Open Source Initiative over the past few years has been a joy and an honor, and if I write a memoir someday I’m sure these will stand out as some of the best and brightest years in a long and happy open source career. It has been a delight to collaborate closely with so many people I admire greatly, including Deb Bryant, Molly de Blanc, Richard Fontana, Leslie Hawthorne, Mike Milinkovich, Simon Phipps, Josh Simmons, Carol Smith, Paul Tagliamonte, Italo Vignoli, and Stefano Zacchiroli.

I’m incredibly proud of what the organization has accomplished in that time, continuing stewardship of the open source license list, and growing our individual membership and affiliate programs which provide a path for the entire open source community to have a say in the governance of the OSI.

All good things must come to an end, and the time has come for me to pass along the president’s hat to the next volunteer. My work life has grown busier and busier in recent months, and I’m starting a PhD soon, so the time I have available to contribute to the OSI has become incredibly fractured. I’d rather empower someone else to do a great job as president than do a mediocre job of it myself for the rest of the year.

It gives me great pleasure to share the news that the OSI board has elected Simon Phipps as the next president. Having Simon at the helm will help make the transition particularly easy, since he served as OSI president before me. I’ve known Simon for many years, long before either of us was involved in the OSI, and one thing that has always impressed me is the way he consistently engages with new ideas, championing the relevance of open source in the ever-changing modern world. He also gave the best talk that I’ve ever seen explaining the four software freedoms and advocating for software freedom (at a conference in Oslo in 2011).

I’ll remain as a member of the OSI board, both to support a smooth transition to the new president, and to continue involvement in several active projects at the OSI. My hope is that handing off the administrative responsibility to Simon will enable me to focus my limited volunteer time on other things like improving the license review process.

I’ll close with an invitation: if you have a passion for open source and/or free software, consider running for the OSI board in one of our annual elections. Any individual member of the OSI can self-nominate as a candidate for the board (voted by the body of individual members), and active affiliate organizations of the OSI can nominate anyone as a candidate (voted by the body of affiliate organizations). Director terms are only 2-3 years, so serving on the board isn’t an overwhelming commitment, and is a great way to contribute your skills and experience to the open source and free software community. Who knows, maybe you’ll be the next president of the OSI after Simon.

(Re-posted from: https://opensource.org/node/902)

The Future of Open Source

William Gibson has a concept of the future in relation to science-fiction, which he’s mentioned on many occasions in slightly different forms. My favorite source is the earliest one I can find, which isn’t quite as quotable as the more polished form on Gibson’s Wikipedia page, but it has a more authentic ring of roughness to it, as if he articulated the idea on-the-fly during the interview:

The future is already here and it is very unevenly distributed and it arrives in bits and pieces constantly.
— William Gibson, “There’s no future in Sci-Fi”, London Sunday Express (April 2, 2000)

The future isn’t a binary switch, where suddenly, someday we’ll find ourselves “bang!”, in the future. The future is a progression over time, and while it’s impossible to predict the future with 100% accuracy, we see the “bits and pieces” of our future all around us. Sometimes it’s hard to figure out which bits will be significant, and which will simply fall by the wayside. But, significance develops over time too, so by looking back far enough we can trace which bits increase in significance and which decline, and the apparently random distribution begins to develop a pattern.

Lately I’ve been applying this idea to the industry that’s grown up around software, and especially free software/open source, sort of looking though the past to see the future. In the process, I’ve hit on an analogy from physics that provides a decent framework for exploring the history of software and the distribution of innovation over time. It’s based on the concept of an object traveling faster than the speed of sound. Similar principles apply for a particle traveling faster than the speed of light, but the speed of sound is generally easier for people to relate to.

First Age of Software

The early days of software, from about the 1940s to the 1970s, were like traveling at subsonic speeds. Sound naturally travels in waves, outward from the source of noise in all directions. To visualize this, you can picture a pebble dropped into a still pond, and how the water ripples outward. By analogy, innovation in software was initially slow and happened in scattered pockets. An innovation strike is the bit where “the future is here”, while the ripples in waves out from the center are the uneven distribution of that “future” into the wider world.

In the First Age of software, the pace of innovation was slow and regular. The tech industry didn’t value software terribly highly, regarding it as a mere extension of hardware.

“There was little or no interest in protecting software technology separately, because patent protection for computer hardware adequately rewarded innovation. […] When computer programmers first approached the U.S. Copyright Office about protecting programs by copyright law in the mid-1960s, the Office expressed some doubts about whether machine-executable forms of programs could be protected by copyright law on account of their utilitarian nature.”
— Software & Internet Law, 4th Edition, page 31-32

All software was “free and open” in this age, because there was no legal restriction on copying, modifying, and redistributing it.

Back to our analogy: as an object accelerates, the pattern of sound waves changes. The ripples are no longer concentric circles, because each wave travels outward from the object at a specific point in time and space, which the object leaves behind as it travels onward. The fundamental dynamics of flight are the same across a range of subsonic speeds, but the “bunching” of sound waves in the direction of travel hints at what might come next. Similarly, toward the end of the First Age of software, several bits increased in significance, accelerating toward what was to come in the next age.

The U.S. Copyright Office started to issue copyright registrations under the “rule of doubt” in the 1960s, but uptake was quite slow.

“Between 1966 and 1978, only about 1,200 copyright registration certificates were issued [for software].”
— Software & Internet Law, 4th Edition, page 32

Public sentiment started to shift, and while sharing software freely was still perfectly legal, some people thought it shouldn’t be.

“As the majority of hobbyists must be aware, most of you steal your software. Hardware must be paid for, but software is something to share. Who cares if the people who worked on it get paid?”
–Bill Gates, An Open Letter to Hobbyists (February 3, 1976)

In 1974, U.S. Congress established the Commission on New Technological Uses of Copyrighted Works (CONTU) as part of the review for drafting the U.S. Copyright Act of 1976. CONTU’s final report in 1978 concluded that software should be copyrightable, but too late to be included in the 1976 Act, which was finalized October 19, 1976 and went into effect January 1, 1978.

“A majority of the CONTU Commissioners concluded that computer programs already were copyrighted under the Copyright Act of 1976, but it recommended some changes to this Act to make appropriate rules for programs.”
— Software & Internet Law, 4th Edition, page 32

This recommendation can be regarded as the tipping point for software copyright, but apparently the tech industry took a “wait and see” approach to it, since no copyright infringement cases were filed for software until after U.S. copyright law was officially amended.

Middle Age of Software

A funny thing happens when an object accelerates to the speed of sound (also called Mach One). Because the sound waves are traveling at the exact same speed as the object, they keep pace with it, and the longer the object flies at Mach One, the more overlapping sound waves build up around it, creating a massively turbulent zone. For a long time, people thought it was utterly impossible to fly faster than the speed of sound. They called that leading edge of overlapping waves the “sound barrier” and pilots died trying to break it. Traveling at Mach One is analogous to the rush to capitalize on software copyrights in the 1980’s and 1990’s, and the sound barrier corresponds to an area of disruption where business models based on licensing proprietary software can succeed. The calmer area behind the turbulent zone is the massive body of free and open software that persisted and grew, despite all predictions to the contrary.

The defining moment of the second age of software was in one sense quite a tiny thing, no more than a few small changes (pages 14-15) to the lengthy title 17 of the United States Code, enacted on December 12, 1980.

“In 1980, Congress expressly incorporated protection for computer programs into the Copyright Act.”
—Intellectual Property in the New Technological Age, 6th Edition, page 433

But, those few words had a radical impact on the software industry. What followed was a period when companies eagerly and actively sought to enforce their new rights, through litigation or direct action.

“The first questions about copyright for computer programs involved the simplest form of copyright infringement — direct copying of the program code. […] the disputed issue in these early cases was whether computer programs could be protected by copyright at all. The first major case confronting this issue involved Apple Computer.”
— Software & Internet Law, 4th Edition, page 33

Apple Computer, Inc. v. Franklin Computer Corp., filed on May 12, 1982, was initially ruled in favor of Franklin, but Apple appealed successfully, establishing case law precedent for operating systems as software subject to copyright law. In the original ruling in favor of Franklin, the district court concluded that Apple Computer failed to show irreparable harm, stating “It is also clear that Apple is better suited to withstand whatever injury it might sustain during litigation than is Franklin to withstand the effects of a preliminary injunction.” In hindsight, the district court had a reasonable point, and in light of Apple’s statements that they already “had annual sales of $335,000,000 for fiscal year 1981”, it seems fairly unlikely that the case had any significant impact on Apple’s success and future growth as a business, or that Franklin’s continued business would have detracted from their profits in any meaningful way.

Over the same time period, another story arc was unfolding, which was barely noticed at the time, but had a far greater impact on the course of software history. Richard Stallman, working at MIT’s AI Lab, was surprised by an encounter with changing attitudes toward software ownership, inconveniently preventing him from porting a fix to send out paper jam notifications from an old printer at the lab to a newer printer.

“In the course of looking up the Xerox laser-printer software, however, Stallman made a troubling discovery. The printer didn’t have any software, at least nothing Stallman or a fellow programmer could read. Until then, most companies had made it a form of courtesy to publish source-code files–readable text files that documented the individual software commands that told a machine what to do. Xerox, in this instance, had provided software files only in compiled, or binary, form.”
—Free As in Freedom (2.0), page 4

Richard tried to gain access to the source code, reaching out to academic colleagues as he would have done in the past. He was unsuccessful, as those who had the source code declined his request for a copy, citing a contractual agreement with Xerox as the reason. As surprise gave way to thoughtful reflection, Richard began to shape the seed of an idea that would grow to become his life-long passion.

“I already had an idea that software should be shared, but I wasn’t sure how to think about that. My thoughts weren’t clear and organized to the point where I could express them in a concise fashion to the rest of the world. After this experience, I started to recognize what the issue was, and how big it was.”
— Richard Stallman, Free As in Freedom (2.0), page 9

Beginning quite informally with comments on “communal sharing” in a paper about Emacs, he fleshed out his ideas over the course of several years, leading to the announcement of the GNU Project in 1983; the publication of the GNU Manifesto, formation of the Free Software Foundation, and first release of the GNU Emacs License in 1985; and a generalized version of the Emacs license (and other variants for the GNU C compiler and debugger) dubbed the GNU General Public License in 1989.

In another parallel story arc, in 1977 UC Berkeley released a mixture of their own and code from AT&T Unix, under the name Berkeley Software Distribution (BSD). They released before software copyrights existed, so imagine their surprise 15 years later, when a subsidiary of AT&T filed a lawsuit against against them for copyright infringement. The judge denied the injunction, and the case was settled out of court.

Notable milestones in proprietary software in the Middle Age include the first release of the Oracle database in 1979 (rewritten in C in 1983); the first release of MS-DOS in 1981; the first release of Norton Utilities in 1982; the first releases of IBM DB2, Lotus 1-2-3 , and Microsoft Word in 1983; the first releases of Apple’s Macintosh operating system, MacPaint, MacWrite, MacDraft, AppleWorks, and Quicken in 1984; the first releases of Microsoft Windows, Aldus (later Adobe) PageMaker, and StarOffice in 1985; the first releases of Adobe Illustrator and OS/2 in 1987; the first release of NeXTSTEP in 1989; the first release of Adobe Photoshop in 1990; the first release of NCSA Mosaic web browser in 1993; the first release of Netscape Navigator in 1994; the first releases of Microsoft Internet Explorer, Sun Java , and Netscape JavaScript, and launch of Amazon.com in 1995; the first release of Macromedia (later Adobe) Flash in 1996; the launch of Google search in 1997, the first release of Netscape Communicator in 1997; and the first release of Mac OS X Server in 1999.

Notable milestones in free software in the Middle Age include the first release of LaTeX in 1984; the first releases of GCC and Perl, and the Artistic License in 1987; the BSD and MIT licenses, the first release of POSTGRES (later PostgreSQL), and commercial support for free software by Cygnus in 1989; the first release of CERN httpd in 1990; the first releases of the Linux Kernel and Python in 1991; the first releases of Debian, FreeBSD, NetBSD, and Lua, and commercial sales of machines pre-installed with a free software operating system by VA Linux in 1993; the first release of Red Hat in 1994; the first releases of MySQL, the Apache HTTP Server, PHP, and Ruby in 1995; the first releases of GIMP and KDE in 1996; the first release of the Mozilla Application Suite (formerly Netscape Navigator & Communicator) in 1998; and the first releases of GNOME, Asterisk , and CUPS in 1999.

The Middle Age of software was characterized by proprietary software at the leading edge of software innovation, and free software playing catch up, combined with a belief that the world would always be this way. No one considered the possibility that the introduction of software copyrights might have induced a unique set of conditions, sustained for a time but fading and not reproducible. In the latter half of the Middle Age, more and more new software innovations were built on free software or as free software, and yet conventional wisdom still held that business profiting from free software was an oddity. Ultimately, the golden age of proprietary software lasted a grand total of about 15 years, a mere blip on the scale of software history.

Modern Age of Software

The most important thing to understand about the sound barrier is that it doesn’t actually exist. The turbulence experienced at Mach One is really no more than a convergence of transition effects between subsonic speeds and supersonic speeds. With advances in technology, “breaking the sound barrier” quickly shifted from deadly to merely dangerous, and eventually became so easy it wasn’t even a noticeable disruption in flight. Once an object accelerates past Mach One, it travels faster than the sound waves it creates, and so the waves fall behind the object, creating an outward spreading cone. The compressed sound waves at the outer edge of the cone form a zone called the “shock wave”, which is experienced by observers as a sonic boom (comparable to the noise level of firecrackers) as the edge passes by them. You can visualize this like a wake stretching out behind a fast boat. In software, the shock wave is the same disruptive zone we saw in software’s Middle Age, where business models based on proprietary software can succeed. But at a supersonic pace of innovation, this zone is much thinner, and presents no barrier to open solutions overtaking and surpassing proprietary solutions.

There was no single defining watershed moment at the start of the Modern Age of software, like there was for the start of the Middle Age, but a convergence of factors places the beginning sometime around the year 2000. That doesn’t mean the final outcome was obvious to everyone in the year 2000, but in hindsight we can approximately place the point at which the future was “here” in 2000, and characterize what followed as a process of evening out the distribution and accelerating the pace.

While it’s tempting to identify the open source movement as a catalyst for the Modern Age of software, it’s more precisely accurate to say that events and conditions surrounding the start of the Modern Age were the catalysts for the open source movement, in much the same way that events and conditions surrounding the start of the Middle Age were the catalysts for the free software movement. What was a significant factor in the start of the Modern Age was that attitudes started to shift: corporations were more open to using free software, and many free software projects were more open to corporate involvement. A small group of people in favor of this shift chose the name “open source” and it gained popularity surprisingly quickly. But under any other name (“collaborative software”, “shared software”, “modern software”, or simply continuing under “free software”), the outcome would have been nearly identical. The market forces driving the start of the Modern Age were broad, deep, and strong.
It was difficult to predict the outcome of Netscape’s underdog maneuver of releasing their Navigator web browser as open source through the Mozilla Organization in 1998. Mozilla’s announcement 7 months later that they’d be scrapping Netscape’s codebase further clouded the issue. But looking back, the beginning of the end was clear in Internet Explorer’s slowed growth from 1999-2001 and market share peak at 96% in 2002, followed by a subsequent decline to 10% today.
The burst of the dot-com bubble in 2000 and subsequent evaporation of lush VC funding, meant that paying for proprietary software licenses to programming languages, databases, web servers, etc. simply wasn’t a viable option for the vast majority of startups, especially in the face of stable, reliable free software/open source alternatives already used extensively in production environments.
Apple transitioned their flagship operating system to a free software/open source base over 1999-2001, just one indicator out of many of the shifting attitudes.
20 years of experience with proprietary software was enough to see and begin articulating its practical disadvantages. Since the free software movement started at pretty much the same time as proprietary software, it could predict the failure modes, but its (impressively accurate) predictions were unfortunately often dismissed by those with high hopes for making big profits from software copyrights. The start of the Modern Age was littered with catchy aphorisms about collaborative, dynamic, faster-paced development models: “given enough eyeballs, all bugs are shallow”, “scratching a developer’s personal itch”, and “users as co-developers” for “rapid code improvement and effective debugging” (Eric Raymond, The Cathedral & the Bazaar). The subsequent 15 years have shown that the benefits of open development models aren’t automatic. It takes work to build a healthy collaborative community, and simply slapping a free software/open source license on a chunk of code and tossing it over the wall rarely succeeds. But the fact remains that proprietary development models exclude any possibility of collaborative benefits. The fundamental nature of proprietary software restricts its own potential for growth.
The rise of software patents from 1995 onward was regarded as a potential threat to free software and open source, and lead to the addition of explicit patent license clauses in the Mozilla Public License 1.1 in 1999, the Apache License 2.0 in 2004, the Artistic License 2.0 in 2006, and the GNU General Public License 3.0 in 2007. Ironically, it turns out that one of the safest ways to drive forward rapid innovation in a space that’s heavily patented by multiple companies, is to gather as many of those companies as possible, license their patents into a free software/open source project, and run along with collaborative development while effectively ignoring patents, on the strength that all the companies together own far more patents in the space than any single company outside the pool.

The period from 2000 to 2005 was marked by growing acceptance of a new way of looking at software. Fearful predictions that open source would undermine the software industry, gave way to recognition of open source as a new model of decentralized economic production. The message of free software and open source didn’t change, but more and more people were repeating it. In 2006, Tim O’Reilly predicted that by 2010 open source would “be part of every business and every company’s strategy“. And indeed, 2010 saw the rise of the meme that “Open Source Won”.

After the celebrations died down, the open source movement suffered from anti-climax: If the true goal of open source was “enablement of a commercial industry“, then what’s left to do after you succeed? In recent years this has been followed by a form of low-grade disillusionment: If we won, why are we still repeatedly explaining how open source collaboration works? The answer to both questions is that corporate adoption was never the sole defining goal of the open source movement, it was only a significant milestone along the way. The true goal of the open source movement is encapsulated in the Open Source Definition, advocating for the freedom to use, modify, and redistribute software, and the benefits of exercising that freedom. If this sounds stunningly similar to the philosophy of the free software movement, it should come as no surprise: the Open Source Definition is a slightly modified copy of the Debian Free Software Guidelines, which were drafted as an explicit expression of the philosophy of free software. That doesn’t mean the two movements are identical, just very, very similar.

To a large extent, the free software movement was unaffected by the open source identity crisis. Free software’s focus from the beginning was on the freedom to use, modify, and redistribute software, and while it offered several ideas around profiting from free software using business models based on support or services, attracting corporations was never one of its goals. However, the free software movement hasn’t been excluded from the benefits of growing acceptance in the Modern Age of software. While it’s only one indicator out of many, an easily accessible form of public hard data for U.S. non-profits is their tax returns, which show that the Free Software Foundation saw an increase in annual revenue from $376k in 2001 to $1.25m in 2012. (Even though it’s really comparing apples to oranges, I feel obligated at this point to share the same public information for the Open Source Initiative, which saw an increase of annual revenue from $25k in 2001 to $117k in 2014.)

Some feared that open source “winning” would undermine the work of the free software movement, by tempting people to settle for the lesser goal of corporate adoption,and lose sight of the ultimate goal of software freedom. I can’t find any evidence that this has turned into a significant trend. Anecdotally, over the past few years, I’ve seen quite a few open source developers do a bit of soul-searching and find their true roots in the free software movement, but I haven’t seen a single free software developer decide to give up on software freedom because free software and open source achieved corporate adoption.

In the period from 2010-2015 free software and open source continued to grow rapidly, without any concrete vision from the open source movement on what should happen next, and with the free software movement still firmly focused on a more distant future where all software is free software. This success is driven by a self-reinforcing cycle of economic necessity and acceleration of software innovation. The greater the body of stable, reliable free software and open source, the greater the pressure to use it and build on it. If your competitors are using and building on free software and open source, then avoiding it puts you at a competitive disadvantage, because they can innovate faster and cheaper through free reuse rather than wasting resources on reinventing wheels. Once the use of free software and open source is ubiquitous among a group of competitors, the game shifts and “use” becomes mere table stakes for entry. The new competitive edge is participation, because the companies who dedicate resources to fix bugs and add features in the projects they use, end up reducing their own cost of providing support and services for those projects, and by contributing changes back upstream they reduce their own cost of maintenance and integration of new releases. Greater contributions over time lead to more stable, reliable, and successful free software and open source solutions, which in turn increase the pressure for even more use, and even more participation.

That sounds like we’re done, right? Well, not yet, but we’re definitely headed in the right direction.

What Lies Ahead

Looking back over the past 70 years or so, some patterns emerge. The legal system is moving toward increasing restrictions on the intellectual property of software, with no sign of rescinding any significant portion of earlier restrictions or the accumulation of case law built on those restrictions, and every indication that new restrictions will continue to be added in the foreseeable future. The good news is that free software and open source have always found ways to overcome each increasing restriction, so the successive introduction of new intellectual property laws for software ownership hasn’t ultimately presented a serious obstacle to software freedom. In a surprising twist, the increasing restrictions have served to boost the growth of free software and open source, by making it more difficult to successfully innovate using a proprietary business model.

Over the next 20-50 years, we can expect to see an increasing number of technical innovations released initially as free software and open source. Of the technical innovations that are initially released as proprietary, we can expect an increasing number to be either undercut and sidelined by rapidly innovating open alternatives, or else released later as free software and open source by their creators to avoid being undercut and sidelined. We can’t say proprietary software is dead, and it’s likely to linger in one form or another for decades into the future. But the patterns of significant bits through history brand proprietary software as a less-than-healthy offshoot in the evolution of software business models, and the trend for proprietary software from the 1980’s to today is one of slow decline and increasing dependence on free software and open source to survive. Some companies attribute their success to proprietary software, but a deeper analysis tends to reveal their true success lies in some combination of other business models (support, services, integration, content, or hardware) that are compatible with free software and open source licensing, so the perceived effect of proprietary software licensing is a mirage.

We can expect to see an increasing number of companies who go beyond use, to participate in creating free software and open source. More and more of these companies understand the principles of software freedom, from the most junior developers to the most senior executives. Others are still only driven to adopt free software and open source out of economic necessity, and herein lies one of the great challenges of the next few decades. Inexperienced companies can cause a great deal of harm as they blunder around blindly in a collaborative project, throwing resources in ways that ultimately benefit no one, not even themselves. It is in our best interest as a community to actively engage with companies and teach them how to participate effectively, how to succeed at free software and open source. Their success feeds the success of free software and open source, which feeds the self-reinforcing cycle of accelerating software innovation.

We can expect to see an increasing diversity in the individuals who participate in free software and open source, not just social diversity (culture, geography, ethnicity, gender, etc) but also diversity of skills beyond development to things like graphic design, user experience, product design, and user support. This change is already happening, and we’re making good progress, but we can expect more growing pains in the coming years. Diversity isn’t a matter of us teaching them to fit in, it’s a matter of them teaching us what they need, and us giving them room to explore and find their own way to work with us. Lately, one of the places I’ve frequently seen the need for embracing diversity of skills is when multiple companies hire user experience and product people to work on the same free software/open source project, but the project doesn’t provide channels for them to collaborate across company boundaries, because they aren’t developers. The OpenStack project has started experimenting in collaboration for user experience and product skills, and I’m pleased with the results so far.

It’s looking promising that over the coming decades we’ll see increasing unification across the free software movement and the open source movement, under the banner of software freedom, or perhaps some other name. (Personally, I’ll gladly accept whatever name the two communities can agree on, and for the past decade that seems to be “software freedom”.) As free software and open source succeed and proprietary software continues to decline, the motivation for debating about tactics dissipates, leaving a growing motivation to collaborate around accelerating, solidifying, and celebrating our success.

(The illustrations of subsonic, Mach One, and supersonic pace of innovation are based on “Transonico” by Ignacio Icke, licensed under Creative Commons Attribution-ShareAlike 3.0 Unported.)

Open Source Enlightenment

(My thanks to Audrey Tang for this lyrical transcript of my talk at OSDC.tw, to Macpaul Lin for the video, and to Chia-liang Kao for proofreading the Chinese translations in my slides.)

Over the years, I’ve started thinking that participating in the open source community is like traveling on a path, toward becoming not only better programmers, but also becoming better people by working together.

You might think of it as a path toward enlightenment, growing ourselves as human beings. So what follows is really my personal philosophy which I’d like to share with you.

The first thing is this: The most important part of every open source project is the people. While code is important, the center is always the people.

There are different kinds of people involved in a project: People who code, who write documentation, who write tests. People who use your software, too, are just as important for a project.

Also there are people who work on the software that your project uses — you’re likely using projects from other people in the upstream, and you might want to send them a patch from time to time.

Or maybe you’re writing a library or a module, and so other people will be using your software, and communicating with you as their upstream as well.

So why do people work on open source software? This is a very important question to ask, in order to understand how open source works.

For people’s day jobs, they may be working with software already. And why would they take the extra effort to work on open source? Part of it is that it involves working on exciting things and new technologies.

Sharing is also a large part of it; as we share with each other, we increase the amount of fun for everyone working together on an open source project.

People also work on open source in a spirit of giving to others; in doing that we’re reaching out as human beings, and this is a very important part of being human.

There are many rewards, too. A big one is respect: As we create something new, draw people in, and share software with them that they can work on too, they recognize who you are and what you are capable of, which gives you a sense of accomplishment.

Conversely, it means that we want to make sure that we show respect to people joining our projects in any way we can, because it helps them to stay involved.

Another important aspect is appreciation; as people publish their work, if you talk with them — Even just a simple thank-you email message saying “this meant a lot of me”, it helps bring about a culture that keeps everybody motivated.

Credit is also important. As you are presenting a project, be sure to mention other people around you, saying “this person did such a wonderful thing”, so we can build a feeling of community together.

One of the things that keeps people interested in open source is that, as we work together, we become stronger and can do more.

Part of it is simple math: 2x people makes at least 2x code, and 3x people makes 3x code, although there is much more to it than that.

When we work together, we can make each other stronger and better — part of that is encouraging each other; as you see people working on a very difficult problem, you can encourage them saying “you are doing great, and I see you will do great in the future”.

You can empower people just by talking and sharing with them.

And then also there’s the fact that, when you have many people together, they’ll have different sets of skills. When you are working together, maybe you know the five things the project needs, and they know the other five things, and so you have the complete set of skills to finish the project, which wouldn’t be possible if either of you worked alone.

So the effect is not only a linear increase in productivity; there’s a multiplication effect when people start working together.

Encouraging each other to look beyond, to look into the future, is also important — We can all inspire others to solve interesting problems. Sometimes just saying “I have an idea” is enough for someone else to make it into reality.

Sometimes you’d look at what someone else is doing — you have not done all the work, but you have the critical idea they needed, and so with that idea they can reach out and go much further.

The key thing about working on open source is that we’re not just standing alone. When you are working with other people, the main thing you’d want to improve is your communication skills.

We communicate about the plans we have: How we want to make the software, personal plans such as a feature you want to work on, and so on.

One of the things I observed in open source communities is this: People often have good plans to create software, but they sometimes clash and fail to communicate with each other about plans. If you work on one plan alone, without communication, you may end up hurting people working on other plans.

So it’s like a hive of bees — a constant buzz keeps us all functioning.

We’ll also often communicate about possible futures: What’s the best way to solve a technical problem? When this happens, you may communicate in a way that’s contentious and angry, making it very hard to make actual progress.

One of the things we’re learning in our process is how to embrace all possibilities. Keep working on the possibility you’ve imagined, but remain fully open to other possibilities other people may have.

And as you make progress, you’ll also be communicating constantly about what you have done — There’s email, there’s twitter… there are many ways to let people know about your progress.

Sometimes we may feel shy, or not wanting to be seen as bragging. But that’s not what it is! It’s good for the project, and for the people as well, because they can learn from what you have done.

Another aspect of communication skills is the ability to ask questions. The advantage of having a community is that some people might have solved your problem before, and asking a question on a forum or IRC may save you days of work.

In the same way, when others are learning, you can be responsive to them too, instead of putting them down like answering with “RTFM” for simple questions.

It’s true that answering “RTFM” maybe save you a bit of time, but it is also teaching that person that they shouldn’t ask those questions in the first place. That is not what you want to teach people at all — you want to teach them to communicate with others.

Also, learn how to make answers that are helpful to people, and help them see that they can also walk down the path as well, and take the path further in the future.

Sometimes you do have to criticize people; we should be open to many ways of doing things, but sometimes one technical solution really is more correct than others. However, the best way to get people to change their ways is to answer them kindly, so they can be open to learning from you.

You have to show some grace, even to people who do not respond very well. Some people may be harsh with you, but this is also part of the path. Sometimes it helps to have a thicker skin, and even in situations when other people should have said things nicer and better, maybe there’s a bit of truth in what they are saying, and you can still learn from that.

From this perspective, even if they speak in a way that is not polite, you can still respond politely.

The other half of communication is not talking, but listening. Instead of telling others what we think, sometimes all that’s needed is just sitting very quietly, and let others talk.

It’s not just listening, though — it’s important to have empathy. As the saying goes, “If you really want to understand someone, you have to walk a mile in their shoes” — perhaps so you can get the blisters they have experienced.

Now, some people think you have to be a genius to work on open source software, but that is simply not true. There are people like Larry and Guido and Linus, yes, but there are also so many different kinds of talents that any projects needs, too.

And no matter how smart you are, it’s important to stay humble. Because with humility, you will be open to other people, and see new ways of doing things. Humility lets you welcome other people into your project. Pride, on the other hand, is essentially telling people “I don’t need you; I can do things my way.”

By being humble, we also welcome people with diversity of genders, of different cultures, creating a richness in open source by opening to different kinds of people.

The diversity also appears between different projects; it’s almost like languages and cultures of different countries. For example, the community around Linux, Perl, Ruby, and Python all communicate and collaborate differently.

And by being humble with each other, maybe we can see that our project is not the only way, and maybe we can appreciate the ways of other communities.

Now, open source is not all about fun — it’s fun, of course, but it’s also a responsibility. When you agree to participate in a project, you’re taking a weight on your shoulders, and it’s a good thing, as it teaches us to improve ourselves and become better humans.

But life can get in the way — significant others, parents, children, jobs — we may accept responsibility for a time, but there may also be a day where we can’t carry so much responsibility anymore.

So there is a cycle, where you start by assuming more and more of a role in a community, and as life goes on, you gradually take on less and less responsibility. This is entirely natural, and it’s bound to happen in a project’s life cycle.

So it’s worth keeping this question in your mind: “Who will continue my work when I no longer have the time?”

To make sure other people can continue our work, we can think of it as a continuous process: Teaching and sharing the knowledge we’ve learned, and at the same time learning more and more from other people — a continuous process of gaining and sharing knowledge.

Finally, as you work on open source, please be happy, with a smile on your face, and make other people happy! Because this happiness is what gives us the power to make great things.

Do you feel happier now? 🙂

Tody Task Manager

Failing to find any free software task manager I could live with, I created my own over the December holidays. I called it “Tody”. It’s a simple GUI app, focused on quick searching, editing, and tagging for tasklists. The file format it uses is identical to the plain text format used by Gina Trapani’s Todo.txt command-line tool and Android app, it even loads preferences from the Todo.txt config file. Since the file format is plain text, tasklists can be shared between machines (or users) over Ubuntu One or Dropbox.

I created it using Rick Spencer’s Quickly templates (GTK, Glade, and Python). I went for a streamlined workflow for the way I use tasklists, so I’m curious if it will map well to others. It appears as a simple text file, with a search box at the top of the window. Clicking on a tag performs a search for the tag (these are similar to Twitter tags, any word that starts with “@” or “+”). The list sorts tasks by priority (marked with “A”, “B”, “C”, etc) and then alphabetically. When the list is limited to search results, the search terms are highlighted in the tasks.

Clicking on the text of a task brings up an editor window, with a checkbox for “Done” tasks, a field to edit the task, and clickable palettes for task priorities and all the tags you’ve used previously in your tasklist. It’s streamlined with shortcuts, so typing Space, Enter marks a task as done, saves it, and closes the editor window.

I’ve started using Tody as my primary task manager, after dumping all my old tasks from other task managers into one text file. I’d like to tweak the search feature, right now it does a completely literal string search, but I’ll change it to split up search terms (so it’s not sensitive to order of terms). Then the next step is to link it up with my Todo Lens, so the edit window for Tody pops up as the action for clicking on a task in the Lens.

The Tody app is up on my PPA, let me know if you try it out and have any requests for features that fit your workflow:

https://launchpad.net/~allison/+archive/ppa

Free Software for Task Management

I am perpetually trying out online task management tools. My never-ending quest is to tame the massive sea of things I should be doing at any given moment, both making sure that important tasks don’t get lost in the mix, and to extract a reduction more closely approximating “the most important thing to accomplish right now”. My two favorites at the moment are Thymer and Rypple, but neither is perfect.

I like Thymer’s simple task creation, twitter-like tagging of tasks, and the smooth drag-and-drop motion for prioritization. But, at the end of the day, it’s just a massive web page of “things I should be doing” and gives me no assistance in taming the beast. I have to manually prioritize each task, and if I want the priorities assigned to tasks to be at all relevant, I have to go on manually gardening them every day. And, while task creation is as easy as tweeting, task editing is a clunky collection of buttons and drop-down menus. The tags are handy in small numbers (and projects really are just tags with a slightly different display), but any more than about 10 unique tags/projects across my whole data set becomes a jumble at the top of the screen and not at all helpful in finding anything. Thymer offers some reporting features, but I never found them particularly useful.

I like Rypple’s social features, it’s got a good take on sharing thanks and feedback, and the 1:1 pages (a collection of tasks you share with another person) are incredibly useful for weekly meetings with co-workers. I like the organization of tasks by goal rather than by project, it encourages grouping tasks into larger sequences toward an overall purpose. But, I found that I still needed some goals that were really just projects or a collection of semi-related tasks, so the construct was a little artificial. Rypple offers a tagging feature, but tag links don’t do anything useful (like take you to a page listing tasks with the same tag), and a task can’t live in more than one goal at the same time, so there isn’t really any good way to pull up a group of cross-cutting tasks. And, Rypple also gives me little help in managing the mass, though it has drag-and-drop priority setting similar to Thymer.

The worst thing about both of them is that they’re neither open source nor open data. Philosophical considerations aside, this is an immediate practical problem, since my access to Rypple was only a free trial which is now ending. I started with the best intentions of only putting in a few things to try it out, but it quickly became an integrated part of my working life, and I now have well over a hundred little individual blobs of data (tasks) that I’m tracking there. Because it’s not open source, I can’t fire up my own instance of it. And because it’s not open data, I can’t get a dump of my tasks. So, I’ll have to manually copy every bit to some other task management system. Which means I’m in the market for a new task management tool, with a very immediate enlightened self-interest in picking something that’s both open source and open data.

Yesterday, I tried out Todo.txt. The biggest appeal is the simple open data format, so simple that it would work just fine as a manually edited plain text file. But, it offers a GPL licensed command-line client for easier task creation, searching, sorting, grouping by project, priority, or “context” (a notion from “Getting Things Done“). It also offers a GPL licensed Android client, which is in the process of being ported to the iPhone. On the downside, it doesn’t offer any collaborative features, so I can manage my own tasks, but can’t share tasks with others, or even provide visibility to others on a subset of my tasks or projects. And while creating tasks on the command-line is clean and simple, actually viewing/managing my 100+ tasks on the command-line (or Android client) feels a bit like viewing an elephant through a pinhole. It doesn’t have a desktop GUI client, though the wiki offers some suggestions on ways to integrate the simple plain text format into other desktop tools like Conky. The results weren’t thrilling (not really any better than the command-line), but they did give me an idea: how about a Unity Todo Lens?

I spent a few hours hacking on that, parsing the Todo.txt format in Vala and displaying the results in a Unity Lens with a general search box and filters for Project, Priority, and Context. I’m pleased with the result for a short experiment, but there are some drawbacks. The Lens really wanted my filters to be statically compiled in advance, while I wanted to create the filter sets on-the-fly from the Todo.txt file (i.e. let me filter by Projects that are in my tasks, not for some list of projects determined in advance). I may be able to hack around that with more time or a Python Lens instead of Vala. Also, a Unity Lens is a great interface for searching tasks, but not great for managing tasks. There’s only one “action hook” for a task, when you click on the icon/title. You can make that one action do anything you want, but it’s still only one action. I could make that one action mark a task as done (that seems most logical), but I’d still have to go back to the command-line to add new tasks, and edit task descriptions, priorities, projects, contexts, etc… Which takes me back to the original problem that the command-line isn’t a great interface for those tasks. What I really want is a slick, simple GUI client that the Lens could launch whenever a task is clicked in the search interface. Possibly a project for another weekend.

That’s all the time I have to work on the idea right now. While I leave it sitting for a bit, any suggestions on free software+open data task management tools you love? Or hate?

Harmony 1.0 Reflections

The month before the Harmony 1.0 release was quiet, and I was starting to wonder if anyone other than the drafting group was even paying attention any more. So, I was pleasantly surprised to see the posts start to appear last week after the Monday release. Some more positive, some more negative, but the most important thing right now is that people are engaging with Harmony, thinking through what the agreement templates mean, and how they fit in the general FLOSS ecosystem. So far I’ve read posts by: Bradley Kuhn, Dave Neary, Jon Corbet, Mark Webbink, Richard Fontana (part 1 & part 2), Simon Phipps, Stephen Walli and a Slashdot mention (glad for links in the comments if you come across others). I’ve observed a few common themes, so I thought it might be useful to take a step back and ponder through them.

Who’s the leader?

Various posts talk about Canonical leading the project, or Amanda Brock, or Mark Radcliffe, or me. For the first few months I was involved in Harmony, I thought it was lead by the SFLC. The surface question seems to generally be whether the “leader” influenced Harmony in a direction against the poster’s philosophy. But there’s a deeper question here: How is it possible to have so many different ideas of who is leading Harmony? Shouldn’t it be immediately obvious who the leader is? The answer is that Harmony has no leader, and since there is no leader, any member of the group looks as much like a leader as any other member of the group. Simon put it best, calling Harmony “the work of a loose grouping of people”. If that seems strange, think about this: In a group made up of so many radically different philosophies, including several who publicly state that they only got involved to keep the process from going off the rails, who would we choose as leader and how would we choose them? Is there anyone in the group who could adequately represent all the diverse perspectives? Anyone who could stand as neutral arbiter? I deeply respect the group of FLOSS lawyers and advocates who have participated in Harmony, and have only grown to respect them more over the past year, but there’s not one person I’d put in that position. Honestly, it’d be some form of cruel and unusual punishment to give anyone the responsibility of herding the rest of us cats. A second thing to think about is whether a group like Harmony really needs a leader. Of the FLOSS lawyers and advocates you know, are any of them shy about expressing their opinions? Do any of them seem likely to hesitate to negotiate for fair representation of their philosophy? The Harmony process works because it’s a table of equals speaking their minds. It could not have worked any other way.

I don’t have confidence in the Harmony documents because of some blessing from some authoritative leader. There is no blessing, no authoritative leader, and if you get right down to it, no one in the world I would want to be that leader or give that blessing. I have confidence in the Harmony documents precisely and only because they were born out of the chaos of collaboration.

What’s the agenda?

As some posters/commenters have pointed out, the Harmony agenda is stated plainly on the project’s website: “We hope that our work will enable more people to contribute code, by reducing the cognitive cost and legal time of reviewing contribution agreements.” It talks about how contributor agreements are “one available tool out of many” and not “a necessary part of all FOSS legal strategies”. So, the public agenda is clear and obvious. But, there’s been speculation about a hidden agenda, or an agenda behind the agenda. Why is that? Why is the simple and obvious answer not enough? I would guess it’s because the posters are students of human nature and know how complex and multi-layered human motivations usually are. The public statement is so straight-forward that they figure there must be more to it, and so speculate on the possibilities of what “more” might be there. I can pretty much guarantee that there are other agendas floating among the Harmony participants. Probably at least 200+ completely different agendas for the 100+ participants, many of them entirely incompatible. I don’t know all the deep and varied motivations of everyone involved (though I know enough to be confident that none of the speculations I’ve read so far are accurate).

The statements on the public website are the set of things that the Harmony drafting group agrees on. We spent a great deal of (probably too much) time hashing those out early in the Harmony process. The reason the public statement is so straight-forward is not because it’s hiding some big secret agenda, it’s because Harmony is so diverse that the simple stated goals are all that we could 100% agree on. For students of human nature, this won’t be too surprising either. Collaboration is rarely about gathering people who agree on absolutely everything, it’s mostly about gathering people who agree on a small set of things, to make progress on that small set.

Do the Harmony agreement templates meet the stated goals for Harmony? I believe they do, but I hope you’ll read them and decide for yourself.

What do they mean?

Some of the discussion has ranged around what various parts of the agreement templates mean, or what it means that various things aren’t in the templates. I’ll touch on a few key points.

inbound=outbound: I won’t argue against the “inbound=outbound” strategy, because I think it’s a good one, and works well for many projects. But, I will argue that it’s not the only valid legal strategy within the realms software freedom. There are reasons to choose inbound=outbound, and reasons not to choose it. If an inbound=outbound strategy is right for your project, you should use it. And if you do, I encourage you to take a look at the Linux Kernel Developer Certificate of Origin (DCO) as an example. In the short-term, part of my 1.0 todo list is to create a page about inbound=outbound for the Harmony website, and I’d welcome contributions to it. In the slightly-longer-term, even though drafting a DCO-style template was more than we could manage for 1.0, there was definite interest in the Harmony drafting group. I’d personally be interested in collaborating on something like this. If you would find a general DCO-style template useful, or would like to work on drafting one, please say so.

Copyright accumulation: There are various ways of talking about it, but one of the fundamental facts of FLOSS contribution is the process of assembling a collection of small bits of code from various sources into one big body of code. Some pieces are relatively independent of the whole, and could usefully stand alone. But for the most part, especially with maintenance work and refactoring over time, the contributions of any one person aren’t particularly useful separated from the whole. This is a beautiful thing about FLOSS, the whole is greater than a simple sum of parts. By copyright law, the default rule in place for all copyrightable work is “only the author has the right to distribute”, which means the project only has permission to distribute the contributors’ work because the contributors have granted that permission. Also by copyright law, the whole collection is itself a copyrightable work, owned by whoever assembled it (a “compilation”). These basic facts apply no matter what contribution policy a project chooses, no matter whether they’ve defined any policy at all. The contribution policy layers on top to more clearly define what kind of permission the contributors are granting the project and what they get in return. When you work on a project with no defined contribution policy, don’t make any assumptions about what the “implied” policy really is. Sometimes it’s inbound=outbound, but sometimes it’s a much older common FLOSS strategy of an original founder or foundation owning the compilation copyright. Fontana talks about how common inbound=outbound is, but in actual fact what’s common is not providing any clarity at all about the contribution policy, not even a simple web page stating “we assume you’ve given us permission to use your contributions”. That complete lack of information is a great disservice to contributors. The Linux Kernel DCO or the Mozilla Committer’s Agreement are good examples of how to be clear with contributors about an inbound=outbound contribution policy. Beyond inbound=outbound is every other possible way of granting permission for the project to distribute the code. Simon speaks against copyright assignment, and there are good reasons not to choose it. In Harmony, the only form of copyright assignment offered is one where the contributor gets back such a broad license to their contribution that there’s only a tiny sliver of a difference between that and ownership. If your project is going to adopt copyright assignment, and there are good reasons to choose it too, this is the best way to do it. Fontana talks instead about “maximalist” contributor agreements, where a project collects inbound permissions from contributors that are broader than the outbound permissions granted to users. There are good reasons for this too, in addition to the unhealthy reasons he mentions. Both talk about the inequality of rights held by the project versus the rights held by the contributors. But, that inequality lies in the fact that the project holds a collection of code, while the contributor holds a few pieces of that collection. All forms of collaborative development are copyright accumulation, there’s no way around it. The act of entering a group project is one of establishing a set of relationships with all the other contributors, which may include some form of legal entity. It’s all about building bonds, and trust, and confidence in this group you’ve adopted, and there’s no way around that either. I’m skeptical that the ultimately very thin differences between DCO/CLA/CAA contribution policies actually have much impact on the overall hurdles for joining a collaborative group or on the overall equality of the situation. Those fine differences will be important to some people, and I encourage people to adopt policies they’re comfortable with, and contribute to projects they’re comfortable with. But, I also ask you all to be charitable to others who have made different choices.

Outbound copyleft license: Harmony offers 5 options for outbound licensing. Fontana points out that only two of these options are a restriction to “only copyleft”. True enough, but this doesn’t mean copyleft licenses are underrepresented. One of those two options (a specific list of licenses) is flexible enough to handle any possible combination of copyleft licenses that a particular project considers compatible with their philosophy. A few months ago, I was hoping for a rigorous legal definition of “copyleft”, that would capture just exactly the set of “true copyleft” licenses, and exclude all others. I even tried drafting some language, but any way of wording it failed to accommodate the fact that different projects have different definitions of what they consider “true copyleft”. Some are only GPL (or even only a specific version of GPL), some include AGPL, some LGPL, etc… The option for a specific list of licenses is a simple (I’d even say elegant) way to capture this diversity, giving each project a fine-grained knob to tweak on their “level” of copyleft. The other option (“FSF recommended copyleft licenses”) provides an updating list of copyleft licenses, which some projects may prefer for “future proofing”. Note from Mark Webbink’s post that a Harmony CAA with a strong copyleft outbound license option is actually a stronger guarantee to contributors than the FSF’s CAA, which only promises some copyleft or permissive license.

Outbound permissive license: Of the 5 options, two are permissive. One is an updating set of OSI approved licenses (again, for “future proofing”) and the other is more generally permissive. Fontana talks about “the appearance of constraining outbound licensing”, as if the permissive options will sneak by unwary developers. This is something the drafting group took great pains to avoid, being very explicit about the types of licenses each option allows (e.g. “copyleft and permissive” for the OSI option). It’s also worth noting that the generally permissive option is also a bit copyleft, obligating the project to release a contribution under “the current license”. In the calls where we discussed it, this was considered by many drafters to be an important expression of developer’s rights, and a step ahead of existing permissive strategies. (I’m glad it made it in.)

Outbound current license: The fifth option for outbound license is “the current license or licenses”. I suspect this may be a less popular option, because one of the big advantages of a CLA/CAA is flexibility for future changes. If your project plans to release always and only under one license, or is willing and able to invest the effort to get a separate signoff from contributors for a license change, you may find that inbound=outbound is actually closer to your needs.

Incorporated feedback: Brad commented that the “1.0 documents differ little from the drafts that were released in April 2011” in support of the idea that they’re “primarily documents drafted in secrecy”. I asked about this and it turns out he ran a diff from Beta to 1.0, and so missed all the changes from Alpha to Beta, which is when we got the most feedback. Here’s a diff from Alpha to 1.0, showing that the changes in response to the public review periods were quite extensive, with only 21 lines of text (less than 10% of the total) remaining unchanged from Alpha to 1.0.

What happens now?

I expect that over the next year a handful of projects will adopt Harmony agreements. That may not sound like much, but I consider my time on Harmony well-spent when I count the collective human-years that will be saved from drafting and redrafting contributor agreements. That time can be much better spent on community building, documentation, coding and everything else that makes FLOSS projects great. Some posters expressed concern that the mere existence of Harmony might divert some projects from one philosophy or legal strategy to another. I just don’t see that happening. The community of FLOSS developers are some of the most legally aware and opinionated non-lawyers on the planet. Harmony will be useful to those projects who would have adopted a CLA/CAA anyway, or for projects who already have one and are looking for an update.

Dave Neary commented in closing “the goal should not be to write a better CLA, it should be to figure out whether we can avoid one altogether, and figure out how to create and thrive in a vibrant developer community.” I completely agree. I’m pleased to see the various efforts for copyright reform, as I think one of the fundamental problems within FLOSS is that we’re trying to build a system of open distribution on top of copyright law, a system that was inherently designed to be closed. I’m in favor of copyright reform, but realize that the law changes slowly and only with enormous effort. On the whole, that slow pace is probably a good thing for the stability of society, but it means there are a few areas where society has changed quickly and radically, leaving the law trundling along to catch up. I also recognize that there’s economic/political pressure to make copyright more closed rather than more open, and it’s not clear who will win.

There’s another idea floating around that I know has been an inspiration for some people involved in Harmony. Right now, FLOSS contribution is all about taking your piece of code and granting permission to one project to distribute it. What if, instead of making individual agreements with individual projects, developers could contribute their code into a kind of “FLOSS commons”, together with annotations on how the code may be distributed. Instead of figuring out each new project’s contribution policy, a developer can just check whether the tags requested by the project are compatible with the tags they’ve chosen. And instead of endless discussions on whether license A is compatible with license B, so library X or algorithm Y can be included in code Z, projects could just check if the code was tagged for their intended use. I don’t know if the idea will ever fly, but if it does, something like Harmony (or future versions of Harmony) could be one of the ways that code flows into a system like that, where Harmony’s “options” turn into tags a developer puts on their own code to identify the forms of distribution they want to allow. Interesting potential there.

A Brief History of Harmony

[This post represents my own memories of my own experiences. All stories have multiple sides, multiple perspectives, multiple angles, so if you’re interested in the story you should talk to other people involved in this first year of Harmony.]

I first heard about Project Harmony around the end of May last year when Amanda Brock sent a message to the FLOSS Foundations mailing list, inviting people to join some face-to-face and phone meetings around FOSS contributor agreements. Not a whole lot of detail, but the general gist was “Wouldn’t it be nice if we could do something a little more like Creative Commons, so projects don’t have to spend so much time creating contributor agreements, developers don’t have to spend so much time to understand them, and lawyers don’t have to spend so much time figuring out if they can approve employee’s requests to get them signed so they can contribute?” This got my attention. I’ve been a long-standing advocate of easy-to-understand legal language, a position I’ve held firmly through the drafting of the Artistic 2.0 license and the Perl contributor agreement, and through my participation on one of the GPLv3 review committees.

At the beginning of Harmony, I wasn’t involved with Canonical, though I’ve been an Ubuntu user and packager almost from the beginning of the Ubuntu project, and a number of my friends work at Canonical. I didn’t know Amanda, didn’t even remember hearing her name before. But, Harmony looked like it had interesting potential, and that was enough for me.

The first few meetings struck me as a little odd. They felt like political grandstanding, a lot of flash with little substance. It reminded me of the GPLv3 review committee phone calls. I kicked in ideas–I can debate like a lawyer even though I’m not one–but I didn’t have the sense that it was going anywhere. Looking back, that was an important first stage. It was how we all got to know each other, where we all stood, what was important to each of us, what we were there to support and to protect. It was a process of embracing chaos.

The group decided to adopt Chatham House Rule for our discussions. I’d heard of it before, but never actually used it. At first glance it seems quite sensible: encourage open participation by being careful about what you share publicly. But, after almost a year of working under it, I have to say I’m not a big fan. It’s really quite awkward sometimes figuring out what you can and can’t say publicly. I’m trying to follow it in this post, but I’ve probably missed in spots. The simple rule is tricky to apply.

At the second face-to-face meeting in early July, the massive block of email CCs that we’d been using to communicate was replaced by a mailing list. Someone brought a discussion piece to the meeting (no name, because of Chatham, but it’s already public knowledge that they were affiliated with SFLC, to my knowledge participating in Harmony as an interested volunteer). It was explicitly not intended as a first draft, but it did read very much like a contributor agreement, though rather too dense. The idea of drafting in options started to take hold. The sense was that we, the Harmony community, were not any kind of authority to say what was “right” or “wrong” in FOSS legal strategies. We were, instead, a rich collection of experiences in FOSS law and could help by explaining what choices FOSS projects could make, and the reasons they might pick one alternative or another. The agreements would then reflect the best practices around the various alternatives, basically “if you make this choice, here’s what experience has shown is the best way to do it”.

Through the rest of July, I was completely absorbed by OSCON planning. This blackout-month before the conference has been pretty common for me every year since I took on OSCON, and talking to other conference organizers I hear it’s common for all of us. In August I took a new job at Canonical and dove straight into “drinking from the firehose” to increase breadth and depth on my knowledge of the distro architecture. I also moved from the UK back to the US, suddenly and unexpectedly, as a visa requirement for taking the job. All that is to say, I was quite busy for a few months, and as a side-effect I didn’t really track what was happening in Harmony. I made it to a phone call or two, a face-to-face meeting in Boston, and half-way followed the mailing list, but I was mostly out of it. And, if I’m being completely honest with myself, I have to say I pretty much lost interest in Harmony during those months. I haven’t made any secret of the fact that I had a bad experience in the GPLv3 process. As a committee, we worked hard thinking through the issues and making suggestions, and as far as I can tell none of those suggestions for clarification, simplification, corrections, or perspectives on the needs of the free software community made it into the final draft. The final text released as the GPLv3 is, to me anyway, entirely disappointing. I saw Harmony going the same way. Those first drafts, intended as a seed for discussion, became the real drafts. They were bloated and dense legalese, and even though we had healthy discussions in meetings or on the mailing lists, somehow they didn’t seem to have any visible impact on the documents. In my mind, and it was probably entirely unfair, I figured that since I had a bad experience with the GPLv3 process, and was having a similar bad experience in Harmony, that the similarity probably wasn’t a complete coincidence, and might just be rooted in the drafter. <shrug> I can’t really say for sure, but I do know that my suspicion killed my motivation to participate. I’ll call this the start of the “Dark Ages”.

At Linux Plumbers Conference in November, Michael Meeks gave an excellent keynote about LibreOffice, that I attended with interest because we’d already started talking about shipping LibreOffice instead of OpenOffice.org in the 11.04 release of Ubuntu. In the talk, he mentioned Project Harmony in an unfavorable light. I don’t remember the details, but it was something about companies pushing an agenda of copyright assignment. The comments really baffled me, they didn’t seem to fit at all with my experience of the process or the goals of any of the participants. Even after chatting with him over a group dinner (a fun evening, I found out his wife and I used to work for the same non-software non-profit organization), I still couldn’t reconcile the gap between what I saw and what he saw in Harmony. I was going to set it aside as “somebody else’s problem” when a friend who I deeply respect and admire took me aside at Plumbers, and expressed concern about Harmony. I promised that I’d look into it.

So, I started asking tough questions, and what I found was both better and worse than I expected. I found that no one at Canonical had a bizarre agenda to force copyright assignment on the world. I also found that Canonical had an interest in replacing their current contributor agreement with a Harmony one, and that “success” for them was measured in community-driven, community-approved, and community-adopted agreements. All good. I also found that Harmony was pretty much stalled, all meetings on hold, waiting on a draft with some changes requested by the Harmony group (substantial changes, but shouldn’t have taken terribly long). Not good.

In a message to the Harmony list just before the mid-December face-to-face meeting, someone (again, no name for Chatham) said that SFLC would no longer be drafting the Harmony agreements. The general gist was that someone (again no name) had a bigger idea for how to improve the current system of FOSS contributions and copyrights, and that Harmony wasn’t enough of a solution. No animosity, wishing us the best of luck, with some possibility that Harmony versions 2.0 or 3.0 might play a part in a longer-term vision. I genuinely believe there was no ill-will in their parting as drafters. I still don’t know the reason for the drafting delay. Maybe they just got swamped with other projects, they do offer pro-bono legal services to the free software community at large, and tend to be quite busy. It is what it is.

I have the feeling that Harmony could have fallen apart at that point. Stalled for something like two months, the drafters bailed, rumbles of public criticism, and nothing to show for 6 months of work. You might think the tone of that face-to-face meeting would be a little dark. Instead, the universal reaction of the group was more like a head-scratching “Huh. That was odd. What next?” We had the seeds of something really good in Harmony, I had a deep sense this was true, and saw it reflected in the faces around me. We decided to reboot, set a schedule for release, go public, and pick a new drafter. A few participants said they’d find out if their companies could help fund the drafting work so we could actually hit the planned April 7th Alpha release date. I’ll call this the “Renaissance”.

In January, we launched a public website, the first incarnation of harmonyagreements.org. It was a single page containing the text from the current “What Is?” page, ugly as mud, and hosted on my own web servers.

Also in January, we started up weekly drafting calls. We took the earlier drafts as an inspiration, but started with a rewrite that I handed our drafter in January with the note that it might not be entirely legally accurate, but it was at least comprehensible to ordinary humans. And then we proceeded to pick that rewrite apart, line by line, word by word. The tone of these meetings was entirely different than the previous year. Partly, we all knew each other pretty well by then, knew each other’s values and priorities and could just settle down to work. Partly, the driving beat of the upcoming Alpha release helped us lock our attention on what to ship “now”. I worked hard to attend every meeting, even from exotic time-zones, on weirdly laggy voice connections. (I’m amazed at the patience other participants showed for including me in a conversation hampered by 2 second delays.) The discussions ranged over whether the drafts accurately reflected our intentions, had the intended legal effect, were understandable without a legal education, and would fit into the customs and cultures of existing FOSS projects. Every week our drafter brought a new version of the document (we worked on it as one big file with variations embedded), with substantial changes based on the group discussion. And every week we combed through those changes to make sure they were what we, as a group, wanted. People ask who drafted the agreements, and the answer is that we all did, together.

As we approached the April release date, we had a professional designer, Ben Pollock, prepare a proper design for the website (I highly recommend him, and hope he gets lots of business out of it, because he charged us beans). Oregon State University’s Open Source Lab agreed to host the site and our mailing list (they charged us nothing, please donate). I had a frantic last few days getting everything set up for the launch. To give geek credit where it’s due, the site is static generated HTML (anything else seemed like overkill for the handful of pages, we’ll expand later) with templates processed using Template::Toolkit (the libtemplate-perl package in Ubuntu), and both templates and generated pages stored in Git, so my “site launch” is a simple ‘git pull’. The comment processor for the mailing list that generates the comment review page is a Python script, basically a small finite-state machine using line-by-line pattern matching. (I’ll have to see if I can use Ruby or PHP for the agreement picker forms on our 1.0 website, for even greater compulinguistic diversity.)

On launch day, I woke up early to set the new website live just before Amanda’s panel at the European Legal Network Conference in Amsterdam. I don’t see the names of everyone who spoke at that panel posted publicly, so I won’t list them here. But, as far as I know the ELN conference is completely open to the public, so someone will eventually post it. After resolving a last-minute technical crisis with the review mailing list, and answering some press questions on the launch, I headed over to the Linux Collaboration Summit for the day. Bradley Kuhn slipped me in as a surprise special guest at the end of his Legal track, where I walked through some very last-minute slides, and a round of questions. The questions were good and thoughtful, captured well by Jon Corbet in his LWN.net post on the session. My immediate action items from the feedback in that session are around transparency: to replace the old “temporary” mailing list for drafting work with a second publicly archived list hosted by OSU OSL, and to put up a Sponsors page on the Harmony website as soon as we get approval from the various donors (names again withheld for Chatham). To anyone who is concerned about unfair influence by our drafter (even after I described how our drafting process actually works), let me say that sponsorship for the drafting work was only promised to the Alpha release, and is unlikely to be continued, since the workload of integrating revisions from the public review process is light enough to be handled by the volunteer participants.

I’m proud of the community group we’ve built around Harmony. I don’t think there has ever been such large-scale harmonious collaboration around FOSS legal strategies before. I take it as a positive sign for the future, that the FOSS legal community can embrace diversity, work together, and change the world for the better. I’m pleased with the template documents we’ve produced. They aren’t perfect, certainly, but they are a good reflection of current best practices, and I hope that through the public review process they’ll be even better by the time we make the 1.0 release.

Allison Randal

Category Archives: floss