Once More unto the Breach

If We've Won, Why Are We Still Explaining Open Source?

At the most recent Apple World Wide Developers Conference, Apple announced they would "open source the next version of its programming language Swift." This minimally means they will publish the source code to Swift using an OSI approved open source license. That's all really. Indeed, the last paragraph of Klint Finley's (@klintron) otherwise excellent article gets it wrong when it says, "But by moving programming languages and other core developer technology into the realm of open source, companies like Apple can provide some assurances that developers will be able to adopt these tools to their own needs without facing legal action." Not even a little bit true. The risks are all still there. Another company could still happily sue the living daylights out of anyone they believe to be infringing their property.

And it's not simply the community and legal basics people continue to misunderstand. There's still a surprising lack of understanding in companies big and small about the business and economic basics. John Mark Walker (@johnmark) recently completed a brilliant four-part series of posts outlining the basic "how to make money" with open source. The opening paragraph to the series begins:

"I never thought I’d have to write this article in 2015. By now, I thought it would be self-evident how to derive revenue from open source software platforms. But alas, no. Despite the fact that the success of open source software is unparalleled and dominates the global software industry, there are still far too many startups repeating the same mistakes from a thousand startups past. And there are still far too many larger companies that simply don't understand what it means to participate in, much less lead, an open source community."

I encourage you to find time to read all four posts [1][2][3][4]. While John Mark presently works at Red Hat, a company that deeply understands the business of open source, his experience goes back almost 20 years to when he worked at VA Linux. 

Companies are indeed contributing more and more to software licensed as open source. Google is building a community around Go and last year began a community around Kubernetes. Go is certainly an interesting language growing in popularity, but Kubernetes represents a decade of Google research and experience in deploying, managing and orchestrating application containers at a time when the industry at large is just catching up. Apple will launch Swift into the public eye. Even Microsoft has learned that they must engage differently with developers and has published .NET (for the second time) late last year. It is no longer about broadcast communities like MSDN.

Building community is where the work gets done for a company sharing assets and collaborating around software, and building community is hard work. There are lessons for Apple to learn and quickly. To build a community, it has to be blindingly easy to engage. The software needs to download and build to a known tested state on a known platform (ideally many) if you want developers to spend time. Otherwise your project becomes one more moribund collection of software thrown over the wall onto github or SourceForge that will frustrate developers and finally chase them away. There are a well known set of patterns and practices that work to enable and build successful communities. This isn't a secret.

And early communities are skittish fragile things. I was part of the original publishing of .NET under an academic research license. There are lessons here for Apple in how to get it "right". We published roughly a million lines of code for the C# compiler, Base Class libraries, and Common Language Run-time (and a complete platform abstraction layer, and a full test harness). Once a developer unpacked the source archive, it was a two [simple] line sequence to build and then test the components into a known state on Windows, Mac OS X, and FreeBSD. The two pages of documentation essentially told you how to do this small amount of work to get to a guaranteed known state, how to prove it running the sample code, and gave a brief discussion of the source tree so people could quickly begin to explore it. [There’s a good description of the original project on MSDN.]

Within 24 hours we received our first righteous patch. A simple 15 line change that provided a 10% boost in Just-in-Time compiler performance. And we politely thanked the contributor and explained we weren't accepting changes yet. Another 24 hours and we received the first solid bug fix. It was golden. It included additional tests for the test suite to prove it was fixed. And we politely thanked the contributor and explained we weren't accepting changes yet. And that was the last thing that was ever contributed. This was done with malice of forethought. And it was heartbreaking. The project was still successful for what it was -- a research platform for programming languages, but it never became a collaborative community around the platform itself. At the time, Microsoft was still very concerned (and conservatively hyper-cautious) about how close the academic code base was to the mainline .NET product space.

So I wish Apple well. It's great to see them participating more broadly in this particular space. They will have challenges in community building, getting the governance right, and thinking through how they want it to contribute to the business. Fortunately there are lots of excellent resources for them to use as they join the broader open source community. Maybe we’ll even see folks from Apple at this year’s Community Leadership Summit. Because as we all know, collaborative innovation is the new engagement mechanism.

Why Openstack is Different from Other Open Source Projects

The Openstack project feels different from other open source projects to me. Let me try to explain.  Henrik Ingo did an excellent analysis of open source project size versus governance structure a few years ago.  Essentially, the nine largest most vibrant open source communities were anchored inside non-profit foundations. The tenth largest was an order of magnitude smaller and existed inside a corporation. Henrik was a good engineer and provided his data and listed his assumptions.  He was not suggesting that the growth was causal, simply that there was a strong correlation.  He rightly observed that it will be fascinating to see what it all means using Openstack as an example when he presented his findings Summer 2011. (He wrote an excellent follow-up post comparing cloud projects later.)

Henrik’s analysis and observations presumes certain criteria about how the open source licensed project must be functioning in and of itself.  It has to be a “well run project” before getting to the foundation amplifier. Lots of people have described essentials of successful communities.  Some of my favorites include Dave Neary, Donny Berholz, and Kohsuke Kawaguchi, and of course there’s Jono Bacon’s essential reference.  I tried to capture and collect together the patterns and practices of successful open source projects in a blog post a while ago. 

Paula Hunter and I offered rationale for the foundation amplification when we were executive and technical directors at the Outercurve Foundation. What might be the cause of the amplification?  We believe it comes from the one thing ALL foundations do for their stakeholders around their projects. Foundations exist at the behest of their stakeholders to make clear the IP management requirements and provide IP risk mitigation. The project community must be well run from engineering and governance perspectives, but once a foundation exists, corporate participants have a clear on ramp for participation and the investment in the community can grow substantially. 

So Solid Engineering Practices + Strong Community Governance + Clear IP Management enables Growth. So far so good. 

But Openstack is somewhat unique as an open source project. It was 2010. Amazon had enormous early mover momentum in providing cloud services [2006]. Eucalyptus was open source-licensed but controlled by a single vendor (née 2009). Cloudstack was just published under an open source license [May 2010] but still closely held by Cloud.com. The time was ripe for a vendor neutral option.  Openstack was announced into existence by then Rackspace CEO, Lew Moorman, and NASA CTO, Chris Kemp, at OSCON 2010. 

A large collection of vendors jumped early and hard onto a simple infrastructure to evolve it rapidly forward into a marketplace of potential customers.  The project governance was created and people started gathering at summits. Openstack was correctly forced into a neutral, non-profit foundation within two years to clarify IP ownership. (Everyone had MySQL as an example on their mind, as it had been bought by Sun Microsystems [2008], and then bought and ransomed by Oracle [2010].)

But here’s where Openstack begins to break patterns. There was relatively little code at the start. It was created from the start to engineer forward.  Openstack is going through forced growth in a time frame that is a 20%-25% of the time of other large-scale successful open source-licensed infrastructure projects.  Instead of 20 years, the effort is becoming enormous in four, already driving serious vendor-lead products to market. 

Project	Started (age)	LoC Mid-point**	LoC Today	Contributors Mid-point	Contributors Today	Re-Arch	Foundation
Linux kernel	1991 (23)	4,000,000	17,000,000	186	1000	2002	2000
Apache (httpd)	1995 (19)	980,000	1,700,000	17	17	2002	1999
gcc	1987 (27)	1,150,000	6,900,000	50	94	1998	1987*
Openstack	2010 (4)	500,000	2,300,000	174	575	???	2012

[* gcc started in the Free Software Foundation; ** All data pulled from Ohloh.net, Wikipedia, and interviews]

Openstack didn’t evolve in simple use cases with the experimental and experiential use that other infrastructure open source-licensed projects saw (e.g. Linux, Apache) before large vendors got involved.  Openstack continues to demonstrate enormous growth and participation. As vendors begin to develop cloud delivery products and services out of the various Openstack projects, they are discovering holes in functionality requiring them rapidly to create new Openstack projects to fill the gaps.  Vendors are also starting to discover that Openstack itself may not scale to the needs of certain industry desires (e.g. Telco desires around NFV).  As well, all core infrastructure open source projects hit points in their organic histories where a reset was required in the architectural design to account for the stresses of new use and deployment.  Linux, Apache, and gcc were each re-architected at points in their histories to accommodate the organic growth of the project into new deployments and use.  

So interesting questions:

• When do the developers at the heart of Openstack projects collectively re-architect/re-factor/re-write core Openstack components to scale to the real world workloads that people are discovering customers need to manage over the next 5 years?
• How does the Openstack Foundation capture those consumer requirements in a fiercely competitive landscape of competitors?
• How will the Openstack Foundation adapt to the needs of its vendor, user, and consumer stakeholders? 

Open source communities are amazingly adaptable organisms.  It will be fascinating to watch Openstack as a community of projects and as a foundation continue to grow and evolve to meet the challenges of the cloud marketplace. 

 

"The Internet was Secured by Two Guys Named Steve"

Jim Zemlin has always been quotable. His keynote at this year’s Linux Collaboration Summit provided a great summary (as always) of the growth of the Linux ecosystem, but also focused on the serious problems in the security of the Internet in an era when key breaches have their own branding and logos. [Think Heartbleed and Shellshock.] He ran through some scary facts:

• OpenSSL secures most of the Internet and the small team at the OpenSSL Foundation (including the “two Steves”, Steve Henson and Steve Marquess) were only pulling in about US$2000 in donations per year. 
• Theo de Raadt supports OpenSSH part-time. 
• Harlan Stenn “runs the clocks on the Internet”, i.e. he’s responsible for ntpd, and until recently was earning about US$25K/year. 
• Werner Koch maintains GnuPG, which secures a lot of email and provides the confirmation that a software package is what it says it is. According to a recent interview, he was going broke. 

Before readers unversed in open source software get concerned with the security of open source software, let us remember this is a software problem, not an open source problem. Closed proprietary products have their share of exploits, etc.  But with open source licensed software, the broad community can do things. 

It is perplexing that if Linus’s Law is true, “Given enough eyeballs, all bugs are shallow", then such security problems persist.  Jim suggested as he gave the above examples that “there just aren’t enough eyes.” I’d offer a corollary. I think vibrant projects live a culture of review before code gets committed.  I think this is because the developers have perspective and context that can never be built into a static analysis tool. Tools can find obvious portability breakage, or some security related issues (e.g. buffer overflow problems), so issues that are likely syntactically based, but a human can understand the semantic content of the code in front of them.

There's even research to back this up:

• Walcélio Melo, Forrest Shull, Guilherme Horta Travassos, "Software Review Guidelines", Technical Report ES 556/01, COPPE/UFRJ, August 2001. "Code review is more effective than test because in review the faults in the code are found directly, while testing uncovers only the symptoms of problems, requiring debugging to find the direct cause. The seriousness of the wrong behavior by the system does not have a relation to the type of mistake, since even simple mistakes can cause complex behaviors."
• Reidar Conradi, Amarjit Singh Marjara, Øivind Hantho, Torbjørn Frotveit, and Børge Skåtevik, "A Study of Inspections and Testing at Ericsson, NO", a rewritten edition of the paper presented at PROFES'99 (Oulu, Finland, June 1999). From the Conclusion: "Software inspections are indeed cost-effective: They find about 70% of the recorded defects, take 6% to 9% of the development effort, and yield an estimated saving of 21% to 34%. i.e., finding and correcting defects before testing pays off, so indeed “quality is free”.” and: "Individual inspection reading and individual Code Reviews are the most cost-effective techniques to detect defects, while System Tests are the least cost-effective."

In the open source community bugs are found quickly, but this happens after the fact.  Vibrant projects live a culture of review before code gets committed so it’s much more like they find the bugs before they happen.  Many of the key projects that have had breaches are taken for granted and don’t necessarily have the vibrancy of a Linux, or an Openstack. These projects have simply become part of the fabric of the Internet. 

The Linux Foundation is stepping up to tackle these problems with the Core Infrastructure Initiative (CII).  The Foundation is in an excellent position at this point in time to be the centre of gravity for such industry action. Jim talked about the Initiative in his keynote.  A broad collection of players have banded together to provide a three pronged approach to the problem of securing the open source software that secures the Internet. 

• Invest in the people that are the most knowledgeable about key projects. 
• Provide deep audits for the key projects to work to prevent the next security breach. 
• Develop and disseminate best practices and guidelines for developing and deploying secure software. 

Jim’s big concerns are how not to perturb the market economics that drive open source software ecosystems and how to avoid creating an open source welfare state. He rightly used the example of I35W bridge collapse of an example of failing infrastructure that should have been fixed before a key transcontinental artery collapsed. I think that’s the right idea economically. 

Governments invest in infrastructure to enable economic growth. Support and investment for rights of way for railroads, deep port infrastructure, or interstate highway systems creates the transportation infrastructure that enables economic growth and free markets for all. All the projects Jim discussed are fundamental Internet infrastructure. If a project under consideration implements or secures an underlying universal communications protocol  or cryptographic algorithm then it is probably a good candidate for CII investigation.

Likewise, software projects that are not owned by corporations seem to be a necessary attribute. A database, even one as broadly deployed as MySQL, shouldn’t be a candidate. A fabulous engine for application deployment (node.js) is owned by a company. I’m pretty sure the investors would love the vendor community to invest in securing node.js “because it’s so hugely important going forward at enabling blah blah marketing blah.” Sorry — if a company controls the copyright, then you’re off the list. Private roads didn’t get government funded bridges. 

The Linux Foundation is obviously not a government, but it is a well-funded well-organized industry non-profit.  As such it provides an excellent place for the vendors that best benefit from the Internet infrastructure to collectively support the infrastructure on which they all depend. 

The Core Infrastructure Initiative efforts are fundamentally important.  A complete list of participants to date exists on the Linux Foundation site. Jim’s excellent keynote is up on Youtube, the slides will hopefully be up soon, and Jim’s blog post introducing CII is published on the Linux Foundation blogs. If your company isn’t supporting the initiative, it is well worth exploring how best to participate. 

Patterns and Practices for Open Source Software Success

How do you create a successful free or open source software project?

There are two parts to “success”:

• Deployment growth: One publishes software to see it used. Even from the minimalist view point of, “It was useful to me; it might be useful to you.” But as the software is used, it reflects the dynamic nature of software, and as a solution to a problem, it gets used in new ways to solve new problems. This leads to the second part of the success formula -- contributions.
• Contribution flow: A free or open source software project is at it’s simplest a discussion in software, and without contributions the conversation fades and fails. From a more complex community perspective, a FOSS project is about the economics of collaborative innovation and development. Without a continuous contribution flow, the dynamic aspect of a software project will become static and brittle and lose its relevancy.

As the software at the core of the project is the dynamic thing (the “meme” to replicate), we need developers capable of contributing to the project. Developers that might contribute are people that probably started as users of the software project. They found the software, used it, perhaps fixed a bug, perhaps added a feature, or repurposed the software to a new problem. At this point they are in a position to contribute, but there’s work to be done to encourage and allow that contribution.

So there are three onramps that a FOSS project’s committer(s) need to build and relentlessly improve:

• Attract lots of users: The software needs to be easy to install/configure/use (and this applies to developer tools, libraries, and frameworks as much as to user space apps and tools).
• Out of this user base, attract developers: The software needs to be easy to download, and build and test to a known state. This allows potential developers to experiment/fix/extend the software project FOR THEMSELVES and their own selfish needs.
• Out of this pool of developers, attract contributors because there's actually a well thought out pipeline and communications about what, where, and how to contribute.  Contributions DO come from users, for example bug reports. But a project still needs to communicate with users to enable them to contribute good bug reports.

We have seen these pipelines anecdotally for years.

• In the early days of PC-based software (in the early '90s) there was the 5-Minute Rule (or 10-Minute Rule depending on who you consulted) that said if the software didn't install and do something useful [very] quickly it became shelfware.   Today, how many people download an open source project and never get it working and walk away? How much time are you willing to invest installing, configuring, building, testing, working through the forums, before you declare defeat and move on. How many potential contributors do you leave feeling frustrated and stupid?
• There was an idea expressed by core committers in some open source communities 10-15 years ago that said it's orders of magnitude between communities and contributions, i.e. for every 1000 users, you might see 100 bug reports, out of which 10 will send code that purports to fix said bug, out of which 1 read your coding guidelines and really did fix the bug.  I heard this from a couple of communities (BIG = sendmail, small = graphics drivers) and have "tested" the statement on many core committers since who all stop, think, and agree.  (Caveat lector: This is purely anecdotal. I’m thinking about ways to hunt through the data streams for proof along the lines of Donnie Berkholz’s excellent recent investigation.)
• We see it in statements in their talks from the likes of Jono Bacon ("We want to turn drive by contributors into regular contributors,"), Kohsuke Kawaguchi ("potential contributors start as visitors to your website,"), and Donnie Berkholz ("your future potential contributors start by lurking on your project's communications channels").
• Tim O’Reilly wrote “The Architecture of Participation” in 2004 describing the nature of systems that are designed for user contribution and extending Mitch Kapor’s meme on “architecture is politics.”

There are patterns and practices successful FOSS projects use to grow and evolve the community (users + developers + contributors), and thereby ultimately the software itself. Each group in the community needs an onramp. These activities can be arranged along two axes:

• Software construction: The patterns and practices that make the software itself easy to install, configure, run, build, test to a known state.
• Community development: The patterns and practices that encourage the participation of the people that will grow the user base.

So if we look at the onramps in light of the axes, we get the following diagrams.

Once a project begins to grow, there will be commercial interest. Companies will want to use the software in interesting ways in their own products and services, or provide services around the project to other users. At this point, there are an additional set of activities a project needs to undertake for community growth and contribution flow. (These activities make up their own axis so really there are three axes):

• IP management: The patterns and practices that encourage commercial participation that allows an ecosystem to take hold.

So driving open source project success is an exercise in building onramps for communities of users, developers, and contributors, and eventually commercial contributors to enable an project ecosystem.

I’ve written and presented before now on the role of foundations enabling growth. Many of the IP management issues are handled by free and open source software foundations, as they create neutral non-profit spaces for IP sharing and collaboration. Looking at the history of the Apache Software Foundation, with its incubation program to drive certain software construction and community development activities, and the role of the foundation IP structure itself, one can see the practices and patterns for open source software project success. The “Apache Way” is a reflection of the patterns and practices.

So too, with the Eclipse Foundation, its rigorous IP management and development practices and community support, and the Linux Foundation support for the Linux ecosystem. One can see this as far back as the Free Software Foundation and gcc and the enablement of a C-compiler ecosystem for the likes of Cygnus Software, and the Outercurve Foundation continues the tradition of supporting the three axes of activities for FOSS project success.

So, to summarize:

• Successful FOSS projects grow their communities outward to drive contribution to the core project.
• To build that community, a project needs to develop three onramps for software users, developers, and contributors, and ultimately commercial contributors.
• The patterns and practices involved in the onramps can be arranged along three axes of software construction activities, community development activities, and IP management activities.
• Build the onramps, and one builds the potential for the ecosystem.

I've written about many of these ideas over the past year, but without the framework. I presented the framework of patterns and practices for the first time at the Outercurve Foundation Open Source Software Conference in May this year [video below]. I'm looking forward to continuing the discussion through this next week at the Community Leadership Summit and OSCON 2013.

On Leaving the Outercurve Foundation

I’ve not written one of these posts for some time. I left the Outercurve Foundation effective the beginning of July. The Outercurve Foundation is in the process of restructuring its services and membership structure to meet a broader audience of developers and to deliver hopefully more value to its existing projects.   (Stay tuned for announcements in that space.) Part of this effort will require an increased focus on technology to facilitate more automated services, rather than "staff intensive" services.   To that end, I have left as Outercurve’s Technical Director.

It has been a great three years. The technical non-profit consortia of my experience were all launched with a collection of a dozen CEOs on stage explaining to customers the strategic significance of the collaboration to their businesses. This anchors the initial membership and acts as the inbound vector for new sponsors and members. The Outercurve Foundation (originally called the Codeplex Foundation) launched differently.

Outercurve has always had much more of a start-up feel to it. The interim board hired Paula Hunter as executive director in Feb 2010, who then hired me in May of 2010. Paula and I defined a business model for our “start-up”, iterating over the value foundations provide their free and open source software projects, and why they’re important for the growth of their projects. A lot of the thinking has gone into the various presentations we’ve given, and culminated in the recently published International FOSS Law Review article.

It’s been interesting to define the Outercurve business against the other key foundations as they each evolved around their key projects. Foundations provide IP management, a neutral non-profit space for projects to grow as commercial interest in participation grows, and experience to guide new projects. We worked at Outercurve to define a light weight IP policy while remaining rigorous. Likewise, we developed a mentorship program instead of insisting projects survive an incubation process. Our efforts at education have grown to include hosting the first modest conference for our projects with an agenda that included the likes of Jono Bacon, Scott Guthrie, Donnie Berkholz, Ross Gardler, Kohsuke Kawaguchi, and several of our more experienced project leaders.

Outercurve has grown to 28+ projects, with hundreds of contributors, and millions of lines of code across three gallery “collections”, with shining stars in each gallery. Website Panel, Chronozoom, Orchard, and NuGet continue to grow and thrive. (NuGet is now embedded in Visual Studio demonstrating that even Microsoft product teams are fully taking onboard how to live in a co-joined open source-enabled proprietary product world.) There are more, varied and interesting projects in the pipeline in discussions with the Foundation.

Working with Paula has been a pleasure. I’ve learned an enormous amount about non-profits as businesses, and the start-up as non-profit. She remains the Operational Goddess. I’ve also had the privilege of making many new acquaintances and friends this past three years. But the Board is shifting its business model evolution, it’s a new fiscal year at the Foundation, and it’s time for me to move on.

There are a couple of projects I’m chasing presently.

• At the Outercurve Open Source Software Conference I presented the start of work on patterns and practices for open source success [slides, video]. I believe there are certain activities that software development teams do that allow them to scale successfully, regardless of whether they’re building collaborative liberally-licensed projects (a.k.a FOSS), closed proprietary product for sale, or an internal IT program. I’ll be continuing to evolve this work. I feel it’s important. I also feel it has repercussions for how software engineering is taught (or not) in a Github world. Software is amazingly dynamic and if the project/product can’t scale, it’s useless. I’d like to see the equivalent of the Google Summer-of-Code re-invented into university programs to teach the next group of CompSci and software engineering students how software is constructed in the real world.
• Donnie Berholz did some great statistical work with the Ohloh dataset to demonstrate that active FOSS projects grow more active. I want to build on that work to see if there are ways to demonstrate that the patterns and practices [above] manifest themselves in more active and successful projects. The joy of datasets like Ohloh is that they demonstrate what developers actually do, and not what they say they do.
• “Open hardware” is coming. 30+ years may not be a long time to work, but in our industry it is long enough to see waves of innovation arrive that obliterate the previous model. I started work in the world of minicomputers, saw the arrival of the “toy” we called the PC, the rise of networking and client-server UNIX (now Linux) computing, and now the state of ubiquitous networking and handheld devices based on a smart phone model that didn’t exist six years ago. Embedded devices (software+hardware) are everywhere. The amateur historian and amateur economist in me is always looking for patterns in the rise and collapse of successive waves of tech and the companies that come and go. I think the rise of the Raspberry Pi, Arduino, and open hardware at places like SolderPad will become something fascinating.

All that said, I love to build teams and products that excite customers, so I’m absolutely looking for interesting work. I remain fascinated with the state of FOSS in China. [LinkedIn profile]

Collected Ideas on Open Source Software

[Updated 17-Jul-2013, 12:47 PT: Added a couple of additional links from opensource.com.]

It seems to be time to pull together the past year's posts and ideas here.  I've not been writing as much on the Network World blog, focusing instead on the Outercurve Foundation blog.  I've been working to develop a theme on making open source software projects successful. To that end I started around a collection of writing on the basics of understanding the motivations and some of the mechanics:

• Making Open Source Software starts the theme by looking at the motivations around open source software, whether one is a user, a buyer, or a maker of FOSS, and if you're going to "make", why the economics works and what you need to consider. 
• Making Commercial Open Source Software picks up the theme of the maker but from a commercial perspective.  If a company is to contribute or make FOSS, then one needs to have a clear understanding of the return on investment and how to consider certain additional tools at one's disposal for making open source. [This post takes the theme from the idea of developing FOSS as a strategic product/service edge, and doesn't get into the nuts and bolts of customers versus community.]  This post appeared in opensource.com as well. 
• Building collaboration communities comes with certain realities.  One of the ideas I wanted to develop was the importance of "freeloaders" because if contribution is the lifeblood of a project, one needs a lot of users to find people interested in contributing.  I cover these ideas off in "The Math of FOSS Freeloaders: Why Freeloaders are Essential to FOSS Project Success" [opensource.com link]
• Finally I wanted people to understand the role of software construction practices in scaling FOSS projects beyond a handful of users.  If you don't build onramps for potential contributors, you'll never see the contribution potential of your project.  These ideas were tackled in "Git[/SVN/Mercurial] and Growing a FOSS Community".  [This post also appeared recently on opensource.com.]

I also posted this past year from several perspectives on licensing and FOSS.  Software is protected by copyright law in the United States and other countries.  There has been an enormous rise in the power and popularity of github.com this past few years, but many feel they don't need to worry about licensing their software if they want to share it, living in a "Publication = Sharing" world.  Trying to sort out licensing can be daunting at times.  Depending upon my frustration levels, I've covered the topic from a number of perspectives this past year:

• "Open Source, Software Hygiene and STDs" starts the discussion about the problems of not licensing one's software.  [Also appearing in opensource.com.]
• "Which Open Source Software License Should I Use?" tackles the question head on explaining the broad levers available in FOSS licensing.  There was a crossover post on Network World discussing licensing versus business models for the commercially minded FOSS advocate. [Also appearing in opensource.com.]
• Finally I broke down to the very short "Everything You NEED to Know About Software Copyright and Licensing-to-Share in 2 Minutes". [opensource.com link]

Lastly, I've written in several places on the "theory of FOSS foundations" that Paula Hunter and I continue to expand on:

• The most comprehensive discussion is in the International FOSS Law Review in a refereed article Paula and I co-authored "The Rise and Evolution of the Open Source Software Foundation". 
• I tackle the fundamental differences between FOSS Foundations and forges in "Forges and foundations: Chalk and cheese".  [This post began on the opensourcedelivers.com website.]
• I've presented the FOSS Foundation ideas several times this past year, and slides can be found on slideshare.net.

All in all, it's been a good year of writing on the development of free and open source software. 

Open Source, Software Development Futures, and Monki Gras 2012

I had the pleasure of attending Monki Gras 2012 last week in London, UK. It is a fabulous small conference and that will always be it's challenge. (More on this in a moment.) Monki Gras was probably the best small conference I've ever attended. It was ostensibly a conference about where we're going in software development, tying it back to ideas of craft over industrialization. Following along that theme, we had craft coffee for the breaks, craft beer in the reception and as a tasting at dinner, and enjoyed craft food at the breaks and lunch.

The presentation content, however, was incredible. The format was "short" talks lasting 20-30 minutes. It worked well, allowing lots of time to talk amongst the participants. There were ~150 participants and speakers and this was a perfect size. Over the two days, I walked away with something new to think about from almost every single talk.

Some highlights for me included (and I'll post slide references as I received them):

• Excellent observations from Matt Lemay (@mattlemay) from bit.ly on "What we share is different than what we click". Best quote: "We've had social media for long enough to be embarrassed by ourselves."
• Matt Bidulph (@mattb) talked about new ways to consider social media data analysis and presented ideas for the "Place Graph" alongside the "Social Graph" (see pictures below). In a question: What is the Holborn of Amsterdam? Or the Williamsburg of London?
• Laura Merling (@magicmerl) walked us through a great introduction to the idea of the "craft telco" building on the history of the telco space, and comparisons to the brewing industry from pure to industrialization to craft. (Think Twilio.)
• Kohsuke Kawguchi (@kohsukekawa) talked about developing developer communities from his experience in Jenkins and the idea of a developer pipeline (analogous to customer pipelines) and how to get developers qualified through it by making everything relentless easier. Slides here on SlideShare. This talk was a great complement to my blog post on software development discipline and developing communities. I also blogged Kohsuke's talk separately on the Outercurve Foundation blog.
• Jason Hoffman and Bryan Cantrill gave an enormously entertaining "Doppelbock" talk on the differing roles of CTO and VP, Engineering with some wonderful anti-patterns. Slides here on SlideShare. Best quote from @bcantrill, "Process doesn't write software."
• Zack Urlocker (@zurlocker) gave a great talk on considerations for distributed product development practices.
• Mike Milinkovich (@mmilinkov) also gave a great talk on the relevance of foundations in an open source world. (There was a broad debate on the subject back in November 2011.)

Those were my highlights from Day One in Conway Hall in Bloomsbury. Okay, I also had the Best Espresso of My Life from the Barista-for-Hire. And the beer tasting at dinner led by Melissa Cole was also awesome.

Day Two moved us down to Rich Mix, an equally interesting and completely different venue in Shoreditch. The talks were equally brilliant. My top picks:

• Gavin Starks gave us great insight into developers and apps driving social change at amee.com. Very cool example of Autodesk integrating with the AMEE environmental data feeds to allow designers to model carbon footprints of designs while still designing, rather than discovering the cost in manufacturing.
• Paul Downey (@psd) talked about hardware forks and gave us a view of solderpad.com (@solderpad). (Think git for hardware developers only better — very cool.)
• Donnie Berkholz talked about how much assholes cost projects with examples from the Gentoo world. (They lost 20% of their community from trolls and trouble makers and they NEVER CAME BACK even after the asshole problem had been solved. That's how expensive it gets.)
• Dave Neary (@nearyd) gave a great introduction into how to develop developer communities from a different perspective to Kohsuke, but again emphasizing the need for detail and craft. He built on ideas of mentorship and apprenticeship and examples from the world of Go. (Ask him about the design of Go boards sometime if you want to be blown away by craft.)
• Joe "Zonker" Brockmeier (@jzb) introduced people to ideas for promoting their projects with the press and some insight into the world of tech journalists being pitched by PR. A very good how-to with slides here on SlideShare.
• Leisa Riechelt (@leisa) gave a wonderful talk on "Why most UX is Shite." Her [excellent] notes are up on her blog with a link to slides.
• Finally, Irene Ros (@ireneros) and Alex Graul (@alexgraul) gave a great presentation on what makes good data visualization and how subjective it can be from both the presenter and observer perspectives.

There were a number of great observations flying around the twitter verse during the conference but two bear repeating:

#monkigras is a new kind of conference where the participants are equal to the top calibre speakers

— alexis richardson (@monadic) February 2, 2012

And from Matt Lemay, one of the speakers:

Unsurprisingly, @monkigras was a tremendous success. This will be the future model for many, many tech conferences. This is a *moment*.

— Matt LeMay (@mattlemay) February 1, 2012

And therein lies the challenge. It was the perfect size at ~150 people. It wasn't an invite only event so there was a wonderful mix of people. Smaller would have been fine, but bigger and it will lose some of the sense of intimacy and informality that makes the side conversations easy and important. (One person observed that the U.S. event last Fall was more interactive. I've heard of that difference between the U.S. and UK at similar sized events in the past.) I believe James Governor did design the agenda, asking speakers to give specific talks and I've seen this work really well before (Transfer Summit/UK) at bringing an underlying sense of coherency to a small conference. It certainly worked brilliantly well at Monki Gras. Pairing the event with craft beer and craft coffee also worked in ways I didn't imagine.

All in all, a brilliant conference. Redmonk hopes to have all the filmed talks online soon, and I'll update a link as it becomes available.

Update [15 Feb 2012]: I have also written about three perspectives on the care and feeding of development communities on Network World based on three talks given at the conference.

www.flickr.com

The CodePlex Foundation is now the OuterCurve Foundation

The CodePlex Foundation has re-branded itself to the OuterCurve Foundation. There continued to be confusion between the Foundation originally sponsored by Microsoft and the Microsoft forge site (codeplex.com). In June the Board decided it was time to rebrand the organization to clear up the confusion. [Most recently we were given credit for some excellent sponsor work the forge did in the open source community, so we knew the rebranding work was still necessary.]

We worked with a professional agency (Protobrand) and investigated a number of names that conveyed attributes we wanted to have associated with the Foundation. We wanted the name to support our efforts to build credibility for the Foundation within the open source community, and make the Foundation an attractive investment for additional sponsors. And of course we also had to find a name where we could own the urls. In the end we chose the OuterCurve Foundation. We hope it conveys our goal of helping the expanding universe of companies using open source to contribute to the communities they care about and to create their own.

A number of press articles have positioned us as "putting some distance between Microsoft and the Foundation" as the rationale for the rebrand, and I want to emphasize that the distance we're hoping to create is between the forge and the Foundation. We have an excellent working relationship with Microsoft as our founding sponsor. The Codeplex name was originally chosen as there was thought to be more affinity between the forge and the Foundation but it proved not to be so. Not every plan is flawless in its entirety.

The rebranding also coincides with our anniversary. The Foundation is now a year old. In that year, the interim Board put an initial governance structure in place, hired core staff (Paula and I) and we have accepted the creation of two galleries and a half dozen projects. More are on their way. The mission hasn't changed. The Outercurve Foundation exists to provide a software IP management process and project development governance to enable organizations to develop software collaboratively and encourage the growth of the open source software as a development methodology. It's an exciting time.

Some of the coverage:

• Dana Blankenhorn: CodePlex Foundation becomes OuterCurve
• Joab Jackson (NYTimes): CodePlex Foundation Called OuterCurve
• The Register: MS-backed CodePlex Foundation morphs into Outercurve [And no, Paula doesn't gush about things.]
• DJ and H-Online: CodePlex Foundation becomes Outercurve Foundation

Open Core and the Open Source Business Model Debate (on CodePlex)

The past few weeks have seen a resurgence in the debate over whether or not open core is a valid open source business model or not. There has been a lot of passionate and pragmatic discourse from lots of knowledgeable people (Phipps, Ingo, Mickos, Aker, Aslett, Proffitt, O'Grady).

I add my take on the debate on the CodePlex Foundation blog.

Software Freedom and Open Source Software (on CodePlex)

I just posted my opening thoughts on the current debates over software freedom versus open source software as a foundation for a discussion about open core as a business model. They are over at the CodePlex Foundation blog. Please discuss there rather than here.