As of last week, I’m officially an employee of the Wikimedia Foundation. Here’s the the official announcement of WMF hiring me. I’ve been working there as a contractor for the past couple of months, and it’s been a great experience so far. I’m working with a lot of really smart people that I stand to learn a great deal from. I’m pretty used to being the “open source guy” at the companies I’ve worked at in the past, so it’s going to be an interesting twist to work somewhere where publishing the source code (and most everything else, for that matter) is just a given.

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.

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. [...]

I’ve been working on a project to make building forms really simple. My latest work is “jsonwidget-python” for terminal-based applications (like you would use via SSH or local terminal on Linux and Mac). It’s all very retro, but terminal windows are still very much in use for buzzword-compliant activities like configuring virtual machines for cloud computing, in addition to being the preferred user interface for a lot of people out there (*cough* nerds *cough*).

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

There’s nothing too fancy in this screenshot, but this is probably the most typical case. What you see there is deceptively simple, but there’s a lot of complicated stuff going on under the hood. Most of the complicated parts (drawing the fields, handling focus, handling keyboard shortcuts) is being provided by urwid, an excellent Python-based library for building terminal-based user interfaces. jsonwidget is providing a further abstraction that hopefully makes it even simpler to provide this type of interface, though sacrificing much of the flexibility of programming directly against urwid. Here is the complete configuration file (the schema) describing that address entry form, as well as the documentation for the schema format. jsonwidget-python is compatible with jsonwidget-javascript, so the same schema also works in jsonwidget-javascript.

jsonwidget-javascript screenshot with the same simple address entry form

One nice feature on display even in the simple demo is the ability to have arrays as fields. You’ll notice that the phone number field has two phone numbers, and offers to let you add a third. There’s no artificial limit on the number of phone numbers that one can enter using this tool, beyond the usual limits of computer memory, patience, etc.

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.

As you may have noticed if you visited blog.robla.net directly, the comment area is handled via Intense Debate. I did that to get myself out of the account management business while still maintaining a modicum of control over my site. Other than then weird blue flaming logo and the name “intense debate” on [...]

I’m working on a project that required a bit more from the JSON parser than the stock JSON parser with Python allowed for. After doing some hunting around, I came to the unfortunate conclusion that I’d probably need to write my own.
Thankfully, Python’s simpleparse module lived up to its billing (thanks in large part [...]

I’ve decided to leave my current job at Linden Lab. Those of you interested in the ins-and-outs of Second Life may want to look at my post to “sldev” (our open source development mailing list). It was a tough decision to leave, and even tougher to make without having my next move totally [...]

There’s a bit of a flamewar going on right now between the main PulseAudio developer, and another Linux desktop developer who grew frustrated by some very real problems caused directly and indirectly by it. PulseAudio is the latest of many savior technologies that promise to make audio on Linux not suck. I’m actually [...]

This article in CIO Magazine touches on things that you should look for in choosing open source software:
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 [...]