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. 

OPNFV: When Open Source and Standards Cultures Meet

I attended the Linux Collaboration Summit last week. There was a kick-off panel on the opening day (http://sched.co/28x6) and then a couple of days of working group style presentations around OPNFV. The work comes under the sponsorship of the Linux Foundation and hopes to establish a carrier-grade, integrated, open source reference platform that industry peers will build together to advance the evolution of Network Function Virtualization. (Or read here for the ETSI definition of NFV). There’s a really good description of the intended work and architecture on the OPNFV site. 

The panel was moderated by OpenDaylight exec director Neela Jacques, and participants included Eriksson, Red Hat, Cumulus Networks, and the community manager from Openstack.  I tracked the OPNFV work for its first half day of the follow-on workshop and spot checked the work for much of a second day. OPNFV started last Autumn. To develop a "reference platform" for NFV activities, the group wants to integrate the work across other open source projects (OpenDaylight, OpenVSwitch, Openstack, etc.), determining what is needed and working with the relevant upstream groups to contribute to each project community appropriately. 

What’s most interesting to me is the very different cultures that are exposed in the room.  Successful open source communities:

• build the one true implementation
• by collaborating through contributions upstream, and 
• meritocratic influence is driven by the contribution of code, infrastructure, and effort. 

Standards organizations on the other hand : 

• collaborate on interface specifications to enable multiple [communicating] implementations 
• by negotiating a compromise position amongst participants, and 
• democratic influence is gained by diplomacy and participation. 

Time frames are also different very different between such technical collaborations. Successful open source communities are building in real time, and larger complex projects have begun scheduling themselves around agile six month delivery cycles. Standards documents often need to support complex externally driven procurement and certification needs and are carefully [sometimes deliberately slowly] developed to ensure participants can meet those needs, and once agreed, change relatively carefully i.e. slowly and with rightly conservative process. (For the moment we’ll assume the open source project is mature enough to be hosted inside a foundation so IP management is understood, and that the IP management of the standard is equally well managed in the standards development organization.) 

NFV is a telecommunications thing and the telco world was historically driven by standards with large internationally-focused organizations (ISO/IEC, ETSI, etc.) at their core. Linux as a vibrant open source community has demonstrated its ability to deliver vendor-collaborative engineering value this past 25 years. Openstack is attempting to replicate that success and is the hub for much of the present Infrastructure-as-a-Service (IaaS) cloud work. As explorations of software defined networking (SDN) have begun in the open source community, projects such as OpenDaylight (also under the auspices of the Linux Foundation) and now OPNFV have begun. The telco community wants to invest in driving this sort of open source collaborative work forward to reap the benefits of reduced costs and delivery agility. They just don't necessarily know they need to participate differently.

The OPNFV working group provided a stark example of this lack of understanding. Dave Neary (Red Hat) gave an excellent presentation on open source collaboration to the room. Chris Wright (also Red Hat) led a number of discussions. But many of the comments from the telco audience participants tended to be of the nature:

• When are you going to have work done for us to review?
• Notes on <some topic> are missing from the OPNFV wiki.

Many of the standards-centric telco participants seem to not understand that work happens in an open source community WHEN they participate and by their very participation.

Chris Price (Ericsson) is a primary technical leader for OPNFV. He too is working hard to understand the sort of coordination and participation that will be required. The coordination efforts across the collection of projects is enormous. Chris Wright made reference to one piece of work he tried to negotiate that required changes to OpenDaylight, Openstack, OpenVSwitch, libvirt/qemu and a couple of other projects and how trying to communicate requirements and priorities across such diverse projects is difficult. Just because he had a coordinated set of patches for each project doesn't mean there's interest to accept such contributions "from a stranger" into a project focused on different priorities. It’s not simply about drive-by contributions. One needs to participate enough to be heard.  

Likewise, using terms like "reference platform" in a standards-centric audience is often an invitation (indeed a command) to fork code. There is an enormous engineering cost to living on a fork, and to not aggressively contributing small changes regularly, and it often takes vendors unfamiliar with open source participation a while to come to grips with this learning curve. 

Ultimately, the work is very important going forward. There are many vendors in the room (including HP where I work) with a wealth of open source experience.  Hopefully, any initial confusion is sorted quickly and the work will move forward accordingly. 

 

When NOT to Make Open Source Software

I've been working over the past month with Paula Hunter and the Outercurve Foundation on a short book to introduce executives to the fundamentals of free and open source software. It's based on writing she and I have done in the past with a few new essays. One of the last topics I wanted to tackle is the question of when not to publish software under FOSS licensing terms from the perspective of companies in a position to "make" FOSS software.

Many managers are concerned with creating and contributing to the open source ecosystem for two primary reasons:

• Losing control of the “value” inherent in the IP creation, and
• the liability risks of contributing to or publishing the software.

If liability risk is the real problem, then one needs to be sure that one is comfortable with the FOSS license terms, any terms of service that may be involved in the project’s web presence, and the IP management process in place to vet contributions, regardless of whether one is accepting inbound contributions to one's own FOSS-licensed project or outwardly contributing to another project. There’s not much more that can be done about such perceived risk. A company will either be comfortable with the benefits against the risk analysis or not.

A good measure of the risk however is the number of lawsuits that have happened in the open source space relating to copyright. The few that exist tend to be focused on a company using open source software in their products and services while blatantly ignoring the FOSS licensing terms. Openly and honestly participating in an open source community doesn’t appear to lead to lawsuits. Liability risk is probably not a good reason NOT to make FOSS software unless you have a particular risk profile.

The value of the software published is a very different discussion. People need to be very crisp when discussing value. One should never publish one’s core value proposition to its customers. Geoffrey Moore published “Crossing the Chasm” in 1991, and helped business managers understand the concept of their core value proposition. This was a very customer-focused “core” value. Everything else was a complement around the core. It related to the problem one solved for the customer. In later writings (“Dealing with Darwin”) Moore once again discussed core value, but here he was discussing core competency. It was an inward focused core value, and everything else a company did was context. It wasn’t what the customer bought, but rather how one solved the customer's problem.

Core competencies and core value propositions shouldn’t be published for all to use. If the software you have represents the core competency of the company, or generates a substantial competitive edge, it shouldn’t be shared under liberal licenses. The trick, however, is in understanding the truth about the core competency.

Google is an excellent example of this idea. Google consumes a lot of open source, and contributes back in a myriad of ways. But it hasn’t historically shared certain changes it has made to the Linux kernel, nor does it publish all the tools it uses to rapidly deliver software to customers.

Red Hat is another more interesting example. One could argue they simply publish a Linux distribution. The reality is that they dominate the space because they understand it isn’t the software asset that the customer is buying (and over which Red Hat has no particular ownership or control) but all the value around the software in services and risk mitigation and quality and ease-of-deployment that made Red Hat Enterprise Linux such a great replacement for expensive proprietary UNIX systems, and now an excellent server platform going forward.

There is a lot of software in an organization that isn’t in and of itself mission critical to the value they deliver to their customers. Modern Internet properties like Facebook, Netflix, Twitter, and LinkedIn all collaborate on software infrastructure and publish tools they use because it improves the infrastructure for all. Their value to their customers and their competitive business lock is the data, and in some cases the data in aggregate. Or it will be otherwise unrelated to the software platform, e.g. their ability to deliver customer value through a particular channel at a particular price point. These companies deliver a high-quality robust software-based experience to their customers that would make the average enterprise IT shop envious — and they do it on a software platform on which they’re happy to collaborate.

Software is valuable. It represents an investment in its creation, and delivering good software isn’t easy. But in relation to a business endeavour, the cost of creating it may best be shared through collaborative development because it doesn’t represent the core value of a corporation. It’s context in the business.

An interesting further observation from Moore was that a company’s core competency changes over time. They leave a growing pile of context behind them. Google also provides an interesting example of how a company’s edge changes over time. When they were a young company, the company’s ranking algorithms were critical and it would have been idiocy to publish them. At this point in time, with the value that may have been built up in their indexes, they might well be able to share the algorithm because it only works properly in conjunction with the rest of the structured data they have amassed.

Likewise, Microsoft originally needed to protect the Windows NT core competency at the software level. Now, their competencies may be more around the release processes and delivery channels. While there is a lot of third party software in the Windows product of today that cannot trivially be shared, the company’s value is likely no longer tied up in the kernel software anymore than Red Hat’s value is tied up in the Linux kernel that they don’t own and only influence.

Reliably developing robust useful software is hard work. Liberally sharing software and collaborating in open communities is an excellent way to distribute the costs and gain domain insight and knowledge, regardless of whether one is an individual or a corporation. For companies, the challenge is to understand their real and evolving value proposition to customers and the core competencies that enable them to best deliver to those customers. Everything else can be shared.

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

Catching up on the Network World Posts

It's been a while since I last blogged here as I continue to post to my Network World blog when I've something to say. Here's a quick summary of what I've been posting over the past year.

• The Role of FOSS Foundations
  Clean IP management and neutrality encourage collaborative development.
  There’s an excellent discussion begun over the past few days on the value of foundations in the free and open source software (FOSS) world. It includes people calling into question the Apache Software Foundation’s role, promoting foundations, and discussing the broader role of FOSS foundations. This was my take.
• Do Lawyers Ignore Copyright Law?
  Creating software versus creating contracts and a little irony to start your week.
  A view on the irony of lawyers ignoring copyright law to make the practice of law easier for them, while making software developers lives more complex.
• Software Discipline and Open Source
  Software discipline is critical to successful community development
  Good software is developed by good software developers. It involves a discipline not found in most programmers. Rigorous version and configuration management, checklists for style and review, “desk” checking reviews before commits, automated (continuous) builds, and fully automated test frameworks are all necessary steps to successfully, reliably delivering executable software that works. I argue that scaling a software project (open or otherwise) is impossible without this discipline.
• Peace and Harmony between FOSS contributors and lawyers
  Version 1.0 of the The Harmony Documents Launch
  Harmony is an effort that was begun and shepherded by Amanda Brock, the general counsel at Canonical, makers of Ubuntu Linux. The intent was to create a small collection of consistently-worded contribution agreements (both licenses and assignments) for free and open source projects to use to reduce the friction such agreements can cause when they’re encountered for the first time by corporate counsel unfamiliar with FOSS licensing. The first version of the work was published in July, 2011 and this was my take on it.
• Re-inventing SuSE and Three Futures for Mono
  Imagining the potential for Mono going forward
  In June 2011 we saw the rolling announcements out of Attachmate as SuSE gets spun into a separate organization with a return to Germany and Mono employees (along with many other Novell employees) finding themselves on the outside looking in. Here were three ideas for the future of SUSE and Mono.
• The End of the Symbian Foundation
  The end of the Symbian Foundation was in sight before it ever began.
  My analysis of how the Symbian Foundation failed before it ever got going properly.
• Red Hat Obfuscation is a Tempest in a Teapot
  Voting with one’s pocketbook and one’s feet is exactly what software freedom is about.
  I encounter another reference in the mainstream analysis about Red Hat “obfuscating” their work on Red Hat Enterprise Linux. This really is a tempest in a teapot, and I outline why I think that's so.
• Solving the Apple App Store Incompatibility with the GPL
  What’s needed is a little legal linguistic grease to enable the two orgs and their differing goals to slide by one another.
  Here was an idea for all open source legal experts to gnaw on and solve for the community. I saw that Apple pulled down the VLC media player because of the conflict between the GPL and the Apple App Store terms of service. I think there are easy ways around the GPL software on Apple Appstore debate.

I will keep posting collections here from time to time to keep readers abreast of what I'm writing in other places.

Coffee Houses and Code Communities (and other Network World blog posts)

I was invited last Summer to blog at Network World and have been a bit remiss in keeping up on the home blog. Here's the list to date. Several ideas I think are very worth capturing with respect to the discussion around open source community, business, and IP management

• Of Coffee Houses and Code Communities
  We can learn a lot about successful community building from Starbucks
  Brian Proffitt has a great article on the difference between communities and crowdsourcing and how companies still often get it wrong with respect to their community building by treating them as a group that will get things done. I came across a good model for this separation of ideas quite by accident and it differentiates between the co-creation of the asset and the co-production of the community.
• Makers, Users and Buyers of Open Source Software
  Understanding your relationship to a project lets you ask the right questions.
  More and more is being written about governance and license compliance and open source. The FUD of lawsuits continues unabated. Simon Phipps has an excellent post on trying to break out of the conversational frame that some use around compliance and governance. I try to frame a participants relationship to a project so they can best understand what they do (and don't) need to care about.
• How to Talk to Your Lawyer about Open Source Software
  Lawyers know surprisingly more than they think about open source software.
  If you’re a developer that wants to use free and open source software then sooner or later you’re going to need to talk to a lawyer. Many developers have a working understanding of software intellectual property, but unfortunately software copyright is a space fraught with exceptions and edges and ambiguities. Karen Copenhaver came up with a great way to explain open source to a lawyer, and I managed to find the recording of it again.
• It’s Not That Complicated
  Too much is being made of FOSS licensing complexity.
  We seem to be seeing a rise again in the discussions surrounding free and open source software licensing complexity, and the fear that open source may infect or taint your software. I'm tired of it. It's just not that complicated to maintain a clean IP environment in software development.
• Please Don’t Confuse Standards with Open Source Software
  While standards and FOSS may overlap, they can’t be merged into one mega concept
  Some people want to merge the idea of free and open source software with standards, and indeed open the discussion into one of “open standards.” This confuses two ideas that are very different once you get beyond the idea they both involve collaboration in a technology community.
• Open Source: No one is working for free
  To understand the economics of open source, look to the R&D of collaboration.
  People continue to wonder how to make money in the free and open source software world. It’s dressed up in discussions of how one makes money when you give away the software for free, or why developers are working for free. It can likewise lead to a management backlash of not contributing to FOSS projects because some think their developers are working on FOSS instead of their own work. I take another run at explaining why the economics is in a business's best interests.
• A FOSS project isn’t necessarily a software product
  For FOSS the question isn’t just build vs. buy but also borrow versus share.
  Confusion often reigns over how to judge free and open source software (FOSS) as people investigate using it in their businesses. Do they use Red Hat Advanced Server? Fedora? CentOS? Should they use the community edition of the Alfresco content management server or buy the product? How does one judge the “software” and whether it’s “right” for one’s business? These are all questions that confront developers and IT managers as they encounter the FOSS world. I try to tease it apart for people so they understand the difference between a product for sale and an open source project.

Enjoy!

882 Patents

So I'm confused. (Not an unusual state for me, I know.) From the Novell acquisition 8-K as referenced in Andy Updegrove's excellent indepth analysis of the deal so far:

The Patent Purchase Agreement provides that, upon the terms and subject to the conditions set forth in the Patent Purchase Agreement, Novell will sell to CPTN all of Novell’s right, title and interest in 882 patents (the “Assigned Patents”) for $450 million in cash (the “Patent Sale”).

N.B. I'm presuming "Assigned Patents" in the above quote refer to the 8-K, and not the USPTO terminology below.

Taking a quick look at what the USPTO has to say about patents Novell owns as assignee, we find:

• Patents with Novell as Assignee Name or Novell as Inventor Name: 467
• Patent Applications [published] with Novell as Assignee Name or Novell as Inventor Name: 290

So 757 patents and applications. Even adding Attachmate's patent portfolio (14 plus two applications) doesn't really make a difference. I don't know how many "unpublished" patent applications exist in the mix. I don't know if there are a pile of provisional filings that don't show up in the list. I don't know if there are patents outside of the USPTO that are different (unlikely) or overlap in different jurisdictions (in which case one wonders at the import of them if only ~100 were cross-filed. Even doing a search through the USPTO "Patent Assignment Database (Assignments on the Web)" only brings up 775 patents with Novell's name on them.

So to me (naively) it looks like Microsoft vacuumed up the Novell portfolio because it could. I find it more interesting that US$450M was paid for the portfolio. That's about a half million dollars per patent. That seems like a rather large premium when the average patent is supposedly worth about US$75K to file and maintain over its lifetime. (Investors should be curious.) I'm betting it has more to do with Microsoft having a lot of cash and needing to make the overall deal terms palatable to all the partners. So as Brian Proffitt pointed out, I'm not sure things are any more dire today than they were a week ago.

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

The Linux Foundation Announces the Open Compliance Program (on CodePlex)

Companies have been concerned about software license compliance with respect to free and open source software for some time. Part of this is due to simple competitive FUD designed to frighten people away from using FOSS or to sell services and tools around it, and part of this was due to genuine concern with license compliance when lawsuits appear because of violations. The Linux Foundation announced the Open Compliance Program at LinuxCon in Boston today to help companies understand and manage such compliance needs. I describe and comment on the program on my CodePlex Foundation blog.

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.