photo by kwc

There’s been a lot of chatter lately about dual licensing in open source and its much-maligned companion the contributor license agreement. Since my last two community management gigs involved dual licensing and CLAs, I have a few thoughts on the subject.

These tools certainly make it harder to build a community. As Brian Aker pointed out in Drizzle, Licensing, Having Honest Conversations with your Community:

How do you have an honest conversation with someone where you say “yes, I will need the work you did for free, to be assigned over to me, so that I can make money on it”?

It’s not hard to understand that argument. As anyone who has ever tried to build a community will tell you, contributors don’t grow on trees. It’s a lot of hard work getting a community excited and motivated to work on your project. Having a single-minded focus on the thought process of your contributor community is probably the only way to build a community of any size or consequence.

From the perspective of the potential contributor, being asked for a contribution agreement by the project sponsor is really pushing it. The sponsor is already receiving hours, or maybe even days or weeks worth of free labor. Asking the contributor to sign a seemingly one-sided agreement is asking too much. Most open source contributors probably don’t have a lawyer on retainer (except for the employees of companies big enough to have legal staff), and few lawyers probably understand the benefit of signing these things.

photo from Butte-Silver Bow Public Library

So, that’s the view from the contributor side, but what about the project sponsor? I’m sure there’s at least as many views as there are project sponsors, but let me try to paint a general picture. When a corporate entity invests in creating a new piece of software, they’re adding an asset to their balance sheet that they’ve got complete freedom to do with what they want. One thing they can do is release the source code under an open source license, which we all celebrate as a great thing. They lose resale value, but they don’t lose the ability to relicense it. Even if there is no intention to ever relicense that code, the mere ability to do so adds to the balance sheet of a company. For example, I really doubt that MySQL Inc would have sold for $1 billion had the company not had exclusive ownership of the MySQL database. It’s doubtful Nokia would have forked over $153 million for Trolltech had Trolltech already licensed Qt under LGPL.

Contributors who balk at contribution agreements probably don’t fully understand how companies arrive at their decision to insist on them, and so ascribe it to malice or big company stupidity, when in fact it’s probably neither.

Open source projects of all stripes rarely get big, tangible features they truly lust after as outside contributions. Those big features are generally developed as separate projects. Instead, they get lots of small patches and improvements as outside contributions.

Taken individually, each patch is valuable, but not a game changer. So, for any one of these patches, as a sponsor of the project, the tradeoff between taking that one patch versus forever losing the ability to relicense the source code is no brainer. As in “no, don’t take the patch”. If the contributor can be convinced to relicense the patch, great, but otherwise, forget it.

While it may be possible to argue that the cumulative value of the delta between those patches one gets with a contributor agreement versus those that one would have gotten without requiring one is worth it over time, it’s very difficult to know what that delta is. Since that number is almost certainly unknowable, so is the benefit. And therein lies the rub.

Many of the arguments against having contribution agreements seem to be rooted in the idea that the patch contributor is the one who is being the most altruistic, and that the original provider of the source is the one who should be grateful. While it’s absolutely true that the one receiving the patch should be grateful, it’s important to understand that there’s a mutual exchange of value occuring. The contributor is partly avoiding the fate of needing to keep a downstream fork in sync with an ever changing upstream. Moreover, as was discovered in the Debian/OpenSSH fiasco, it’s often the case that the upstream has a valuable service to provide in merely saying “ur doing it rong”.

This is all my longwinded way of saying that potential contributors shouldn’t walk away from a project solely because the project requires contributor agreements. Projects can have very good reasons for needing them, and there can be substantial value in a good working relationship with these providers.

That’s not to say I’m in love with contribution agreements and the dual licensing model. They bring with them all of the problems that Brian and others describe. It’s way more work explaining to your community the need for contribution agreements and GPL licensing than it is to just do away with them and run a more community-oriented project. However, it’s one of the few ways that the open source community has proven worthy of significant financial investment and payoff, so we shouldn’t be too eager to cast it aside.

The only good reason to cast it aside is if there are better models out there, which Stephen O’Grady suggests there might be. Here’s the pitch:

But what if open source vendors could leverage their primary strength – distribution – more effectively as a direct revenue stream? I’ve been predicting for three years or so that they would do just that, via data aggregation and analytics. The alignment of customer and vendor goals is better in this model than in virtually any other. The simplest example of this model outside of open source is Google, who provides users with search at no cost, receiving in return massive volumes of data which they monetize both directly (contextual ad placement) and indirectly (algorithmic improvement, machine learning, intelligence for product planning strategy, etc). Why couldn’t software vendors employ a similar model, trading free software for user generated telemetry data? The answer is, they can. SpiceWorks, for one, is doing just that now, quite successfully, albeit not with open source software.

I agree this is a pretty neat trick if you can pull it off. I think Google, for one, is big enough to pull it off. But I also don’t think its an accident that Stephen had to resort to mentioning a closed-source vendor (SpiceWorks) to make his point. The problem with using open source with this type of strategy is that your downstream distributors can cut you out of the loop, stripping out key revenue and data generating tethers back to the mothership, as Canonical recently did with Firefox. Since Ubuntu users don’t represent a huge portion of Firefox’s user base, it’s probably not that big of a deal for Mozilla, but just imagine what would happen to Mozilla’s revenues if Microsoft started distributing Firefox rewired to point to Bing.

photo from Archie McPhee Seattle

The only real leverage that an upstream producer of open source software has in this case is withholding their trademark, and we all know how much the community loves that.

As I said before, open source contributors aren’t easy to attract to projects. They don’t grow on trees. Then again, neither do compelling, commercially-competitive open source applications. Since we’ve established we can’t plant orchards of contributor and application provider trees to get a lot of both, let’s make sure we’re brokering good deals for both sides to attract many more of both.

This new project builds on some earlier work that I’ve retroactively renamed “jsonwidget-javascript“. jsonwidget-javascript is AJAX-y generation of forms inside a browser based on a JSON schema. jsonwidget-python is intended for terminal users at first, but will extend to other contexts as well.

Here’s a simple screenshot to show what’s going on:

Simple Address Entry in jsonwidget-python

jsonwidget-javascript screenshot with the same simple address entry form

It also handles more complicated schemas if your application calls for it. For example, let’s say that one wanted to build a real address book application. Clearly a lot more flexibility would be needed than merely allowing multiple phone numbers. Here’s a screenshot showing a much more sophisticated schema that’s more like what real address book applications allow:

More complicated data entry with jsonwidget-python

So, what is this good for? Well, I think it’ll be good for a lot of stuff. I suspect it might be a very good user interface to stick in front of a augeas-based user interface. I think it might also be a good tool for building a terminal-based frontend for editing CouchDB and similar databases. In particular, I’m thinking about making a desktop-couch interface for contact editing. Another idea I’ve dabbled with is automatically building a UI based on parameters to Python’s optparse. Yet another thought is an editor for Python’s ConfigParser or alternatively ConfigObj. Lots of different possibilities here.

I’m particularly interested in suggestions for applications that people would use. So, if you have an application for this type of thing that you’re reasonably sure you’d use if I did a good enough job implementing, let me know.

Of course, that’s probably getting a little ahead of myself. There’s a number of things on the roadmap to do, such as more kosher packaging for easy_install and for Linux distros, as well as the ability to edit arbitrary JSON. I also need to investigate SitePen’s JSON schema work, which they appear to be well along toward some sort of RFC (probably informational, but that can be enough for something like this).

Anyway, if this sort of thing is up your alley, please give it a whirl and let me know what you think. You can download jsonwidget-python and give it a spin. I’ve set up a jsonwidget mailing list which you’re more than welcome to use, but you can also just post a comment here or contact me via email.

Update: March 9 – there’s now several ways of getting jsonwidget:

• Latest version at PyPI
• Ubuntu users: PPA on Launchpad
• Bitbucket repository
• off of my website

One new feature that I just enabled is the ability to comment using Facebook or Twitter login. It appears as though if you use it via Facebook, you’ll get the “allow to automatically post to your wall”, which is something that I don’t intend to exploit. If anyone with Facebook Developer-fu knows how to tweak it so it doesn’t ask for that permission, I’d be grateful if you clued me in.

The downside, of course, is that now there is 15 different logos down in the comment area now, not counting the additional 9 or so that pop up when you hover over the little orange RSS icon. Who knows, given the lack of color in the plain-jane theme I’ve recently switched to, maybe that’s a feature.

Thankfully, Python’s simpleparse module lived up to its billing (thanks in large part to JSON having such trivial syntax) Here’s the working BNF suitable for passing to simpleparse:

<ws> := [ \t\n\r]*

>string_json< := string_single_quote / string_double_quote
key := string_json
array := "[", ws, ( value, (ws, ",", ws, value)* )?, ws, "]"

member := key, ws, ":", ws, value
object := "{", ws, ( member, ( ws, ",", ws, member )* )?, ws, "}"

true := "true"
false := "false"
null := "null"
>value< := false / null / true / object / array / float / int / string_json
>document< := ws, value, ws


This is also available in source code form here: jsonorder.py. jsonorder.py is part of a larger project, but it also works as a standalone library (albeit not a terribly useful one for most uses)

The habit of insisting that only the right and the left have “ideologies” and that people in the center don’t is one of the absolute most frustrating elements of conventional political discussion in the United States. The fact of the matter is that “centrist” ideological taboos have been the big story of the Obama administration. That starts with the imposition of an arbitrary cap on the size of the stimulus bill, it continues to the utterly merciless and fanatical centrist opposition to the existence of any public option, to the Fed’s refusal to undertake further monetary easing, to the unwillingness to contemplate really stern measures against bailed-out banks and their executives, and on and on and on.

The idea of a “centrist” ideology is easiest to apply to the “left-right” political spectrum in the U.S., but it holds true in other areas as well (e.g. proprietary versus open). While the “correct” answer is often between two extremes, that’s not always the case. People who tend to favor shades of grey are not necessarily more reasonable, just more prone to picking shades of grey.

Without going into too much detail about what I’m working on, suffice it to say that it involves open source in a pretty big way. Even if this immediate opportunity doesn’t pan out, the scope of stuff I’ll be looking at is going to be pretty narrowly focused on facilitating the creation of open source software. I’ll write more here as things get clearer.

Anyway, Jeffrey Stedfast wrote a series of blog posts culminating in “PulseAudio: I told you so“. In these, he documents his frustration with being given the runaround when trying to point out PA problems that he ends up debugging to the point of finding and/or filing several bugs/patches in various bug trackers. PulseAudio creator Lennart Poettering had enough, and posted to his blog with a long rebuttal, claiming that Stedfast’s blog post “flamed my software and hence me”. It’s a pretty run of the mill developer flamewar, which only caught my eye because I’ve had a few frustrating problems with PA myself and was hoping to learn more.

These kind of arguments make me sad, because they unfortunately seem an inevitable consequence of open source norms (at least as they exist today). Anyone who knows me knows I’ve laid down my fair share of smackdowns and attempted smackdowns myself. But I’ve also become more ashamed of doing it as I’ve gotten older. It just seems that there’s got to be a better way of communicating than this.

In this particular case, I get both sides of the argument equally well. I’ve been on the side of the creator who is told they need to get a thicker skin. That’s pretty rough, though, given how brutally honest many people think they need to be just to make a point. On the flip side, I’m also using PulseAudio now, and its inclusion in distributions like Ubuntu does feel like it was horribly rushed. However, it’s obvious there wasn’t any malice here; just two people who have different views on what the right path to “better” is.

The only thing I would say is that “brutal honesty” should be the last resort, and that public brutal honesty should be the absolute last resort. Just plain old honesty is good enough more often than not.

• Project stability: Can you trust the project to be there when you need it?
• Project support: Can you get support when you need it?
• Internal software management: Does your company know what open-source programs it’s using? How it’s developing and deploying them both in-house and to customers?”

I’m not so sure that these problems are truly bigger problems for open source as they are for software in general. When people in companies select a new piece of software (for use as a standalone product or as an integrated component of a larger system) they miss one important thing: it is much more like a hiring decision than they probably realize. Many of the considerations people make for new employees (reputation, cultural fit, how they are to work with) are equally applicable to new software components and systems.

(CIO article via Matthew Aslett @ The 451 Group)

My answer to the first two questions is “yes, of course projects dominated by one company are still open source, and no it doesn’t need to be ‘organic’”, where “organic” is (arguably) defined as a project which the first release included source, and is generally characterized as by a distributed development team with no single company truly in control, and “inorganic” is generally code that started off life as a proprietary effort. Yay, panel concluded, thanks everyone!

No? Ok, the line of questions above implies a question of quality, and there are very real qualitative differences between “organic” and “inorganic” open source…..

(this is a riff on my earlier email to the sldev mailing list)

Now that Firefox is such a big success, it’s easy to forget the long years that the Mozilla folks spent building the community and figuring out how to transition from proprietary to open development. Jamie Zawinski was the initial leader of this effort, and burned out after the first year. He wrote a scathing essay upon his resignation from AOL/Netscape. In that essay, he notes: “There exist counterexamples to this, but in general, great things are accomplished by small groups of people who are driven, who have unity of purpose. The more people involved, the slower and stupider their union is.” His assessment is brutally frank (probably too brutal), but any of us who do a similar job would be lying if we said we had no idea what he’s talking about.

Brian Aker pointed out in a blog discussion with Theodore Ts’o that there’s not really a successful blueprint for taking projects open source. There are at least some “do’s” and “don’ts”, and an ability to analyze the many projects that have followed in the decade following the initial Mozilla release. But no one has had anything approaching a home run when it comes to both community and commercial success when opening up proprietary software. Some base hits, sacrifice flies, and strikeouts, but no home runs that I can think of.

Corporate-originated open source (arguably “inorganic” software) has a much, much more difficult time keeping the core team aligned around open principles, because there’s a much weaker selection bias keeping out open source skeptics in the same way that organic projects generally keep them out. Participating in “organic” open source projects is often more appealing, since they generally start from day one with public tools for everything. It’s much more comfortable as a community member to have the full visibility of a peer from the first day you take an interest in a project, even if you probably won’t be treated as one until you really prove your mettle.

There are many company-driven open source projects that drag their feet at getting that level of transparency. Many potential participants in these fledgling communities rightfully get frustrated, because they imagine how much more they could potentially help with a peer’s level access to the tools and information. They are probably correct in thinking that companies that don’t do it as quickly as possible are squandering a big opportunity, and get tired of trying to hit companies upside the head with the cluebat. They retreat back to the organic alternatives, because, well, they just aren’t getting paid enough for that….stuff.

I think ushering companies into the open source development model is a hard but extremely worthwhile problem to solve. That’s why I took the job I have today. I have a pretty unique situation at Linden Lab. When we launched, I was helping a company open the source code for a very commercially successful product from a market-leading position (rather than as a scrappy underdog or a has-been). It’s easier than trying to do it while trying to start or revive a business, but presents the different problem that I was (and still am) worried about killing the goose that laid the golden egg. We’ve taken a gradual approach, in part based on my recommendation, and in part because the development cycles just weren’t there for anything more radical than what we did. I’m not going to argue that I’ve done the best job at this (in fact, I know I’ve made several textbook errors), or that Linden Lab has been without fault. But I think we’ve done pretty well with our approach, and as of this writing, our business is still doing very well, and we’re getting a lot of code contributions and bug reports.

While that gradual approach has been good for our business, it has frustrated many people in our community, and it’s clear we’re not the only company in that position. It’s really difficult when you have to untangle processes and habits that have formed over years. Regardless of whether or not those are the best practices, they are the current practices, and the difficulty of process change is often underestimated by those with the best of intentions. Compound that with the fact that the open source culture is a very email-centric (or at least “text-centric”) culture, and how well that works for actually gaging goodwill, and you have a situation where too many people draw their cluebats too soon.

The success of Firefox shows us why it’s worthwhile to persevere with corporate-origin open source. We can kid ourselves and say that that was a fluke, and that the rest of the software we need is going to come from building it all from scratch. We can read too much into Eric Raymond’s statement that 90% of professionally-created software is written by the same companies that use the software, and not for resale. Raymond’s 90% is the long tail, and that general purpose software is still largely written for resale, and most often, isn’t open (yet).

We’ve got an uphill battle to fight to get companies writing proprietary software to instead direct those resources to writing free software. Savio Rodriguez points out:

IDC estimates OSS software revenue growing from $1.8B in 2006 to $5.8B in 2011. [...] Now take that $5.8B as a percentage of the IDC estimated total software market and you get a grand total of 1.8%. [...] This is the future; 1.8% won’t convince vendors to abandon the business model driving the other 98.2% of market spending on software. [..] It’s completely possible that IDC estimates will be proven wildly wrong. Maybe the actual number will be 4.9%

The point I’m making here is that there’s going to be a lot of vendors chasing the (projected) 95-98% of the software market associated with proprietary software. That’s where the investment is going to be for the foreseeable future. I have a hard time believing that all of that software is junk that we shouldn’t need to care about. Let’s take the best case scenario and say there’s a sea change coming. That means there’s going to be a lot of formerly proprietary software (and associated software professionals) that we’re going to need to get better at ushering into the broader community. It’s not merely about teaching those companies “how things are done”, but probably changing those norms in obvious and not-so-obvious ways.

We have a hard problem to solve, but I think it’s worth solving. I’m anxious to have much more software that doesn’t suck.