I’m skeptical about Diaspora specifically, because it reminds me a lot of an effort to take RealNetworks down a peg more than a decade ago. In 1999, the Free Expression Project was started to “help people distribute their content to other people without being beholden to any corporation”. A laudable goal, and one that earned them a fawning writeup on CNet News, which claimed that Real was under siege by these folks. The project never seemed to make it much further than a website with a few diagrams, and nothing that came even close to challenging the streaming media hegemony we enjoyed at the time. (I was at Real from 1996-2005)

However, that’s not really the whole story. What the fawning press coverage indicated was that there were a lot of people who wanted Real to be taken down a peg or two. I imagine that the CNet reporter was as skeptical as anyone about the ability of the Free Expression Project to deliver, but he wrote the story anyway because he knew that people would eat it up. He knew that story would generate traffic because people would see his headline, think “Thank GOD!”, and click through to read the story. He was probably right.

It ultimately wasn’t a ragtag band of open source developers that toppled Real’s dominant position, but rather a one-two punch from Microsoft then Macromedia/Adobe. Still, their job was made a lot easier by the prevailing mood. When we tried to rally the open source community a few years later, despite our success in landing deals with hardware vendors (which it appears they are still successful with), we didn’t get a lot of organic contribution. By then, MPlayer, GStreamer, Xine, VLC and other efforts were already underway, and contributors to those projects had little incentive to join forces with us at that point. The developers on those projects thought: “we can do this better, and why would we want to help Real anyway?”

Facebook has a pretty solid network lock-in going for them, so its not as though we’re about to witness a sudden collapse of their market position. However, they’ve got a serious problem with their brand, and I wouldn’t be surprised if Zuckerberg is in complete denial about it, preferring to think about the privacy controversy as a storm that will blow over soon enough. It’d be easy for the Facebook crew to believe that no one is going to be able to pull together all of the elements needed for head-to-head competition. I’m betting that’s not how it plays out. My guess is that someone like Twitter or Google figures out how to add just enough functionality that many more people feel comfortable giving up on Facebook. Moreover, if I were going into competition with Facebook, I think I’d try to turn their strength into a weakness. For example, for many younger people, a network not overrun with parents, grandparents and extended relatives might just be a selling point.

I’m not deleting my Facebook account anytime soon, but I know I don’t need everything Facebook currently offers.

That's me giving a lecture to my daughter about the importance of proper modularization in large scale development

• April 13 – Lighting talk at the Seattle Django Users Group – this will be about jsonwidget, which is shaping up nicely. I’m toying with the idea of making a Django interface for jsonwidget which will be the main point of the discussion.
• April 24 or 25 (tbd) LinuxFest Northwest (Bellingham) – Using urwid and Python for console applications – I’ve had a pretty good experience working with Urwid over the past couple of months or so, and I’m planning to share what I’ve learned.
• July 21-22 – Two talks at O’Reilly’s Open Source Convention in Portland:
  • July 21 – Financial Incentives in Open Source
    – this is a panel I’ll be moderating, with a lot of really interesting people with a pretty broad range of experience. Stormy Peters has given a lot of really good talks on the subject already. Leslie Hawthorn has been the community manager for the Google Summer of Code program for the past several years. Mike Milinkovich is executive director at Eclipse Foundation, which among many things, is host to the Eclipse Community Awards. Last but not least, Todd Crowe is an independent web developer who has a lot of experience working with freelance sites like Elance. Additionally, Todd has done a lot of work for Love Machine, Inc., a startup that’s taking a pretty innovative approach to organizing their work.
  • July 22 – Great User Interfaces in the Terminal Window – This will be similar to my April talk about Urwid at LFNW, but will be a broader overview of the various approaches. When I was hunting for Urwid, I evaluated some of the alternatives, so the idea behind this talk is to step through the advantages/disadvantages of the various approaches.

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)

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)