So Google are shutting down Google Code.

To be honest, I don’t think it will be much missed. It’s a tacit acknowledgement that the state-of-the-art for code-hosting sites, and even how to run code-hosting sites, has moved far beyond it with GitHub.

Google have obviously worked with GitHub and BitBucket to support migration. And, ironically, even support migration back to SourceForge, a site which predates Google Code and which was probably going before the GitHub guys were even born.

I have some nostalgia for the old days of Slashdot and SourceForge. It would be nice if this was a boost to the older site. I wonder when they’ll acknowledge it on their blog.

Dave Winer asked a great question back in December. What standards are like (his ideal for) RSS?

That is, basically fixed forever by convention, large userbase and multiple suppliers?

My suggestions :

In practice, a few Unix classics : SSH, the diff / patch formats, rsync, finger. All used on a grand scale by many parties. Multiple implementations. Multiple pieces of software committed to them. No one really trying to change them.

Email protocols are pretty widely supported and fixed.
Git. It’s notionally owned by Linus Torvalds, but he doesn’t seem to have any commercial interest in extending or breaking it. GitHub showed you can build a great commercial site around it without trying to make proprietary extensions. And I can use the same clients to push and pull from my server running the default Git daemon, from Github, or from rival offerings (I’m pretty sure BitBucket / SourceForge / Google Code now offer Git as an option)

Possibly Jabber / XMPP

As mentioned previously, I’ve been looking into Ward Cunningham’s “Smallest Federated Wiki” concept. And I’m increasingly impressed.

So much so, that I’ve re-oriented a lot of my projects around it.

What do I mean? A decent follow-up to SdiDesk has been promised for an embarrassingly long time. Over the years I’ve struggled with exactly what it should be and how it should be implemented. Largely whether it should be a desktop application or something you access via the browser. The browser has always been the logical answer but, until recently, the network diagramming aspect of SdiDesk was not really an option in mainstream browsers. OTOH, desktop GUIs open a can of worms. Which OS? Which GUI framework? How do I write installers and distribute? (And, frankly, what is my, as a non-Mac owner / developer, attitude towards the iPad?)

In 2012 though, HTML5 and CoffeeScript have become extremely plausible options for the client. And the server can become a simple wrapper around a basic PageStore. That’s an architecture I’ve been meaning to get down to write. But it’s the architecture that already exists for the SFW.

So, great! By hooking onto that project, I get my basic server / PageStore / client architecture free.

Furthermore it’s extensible via plugins. So I can embed special types of paragraph data and special renderers. That’s exactly what I wanted to do with the new SdiDesk – instead of having *pages* that were network diagrams or grids, have these as individual components of pages. This is perfect. I can concentrate on what interests me – the special plugin types – and Ward’s team can do the infrastructure. 🙂

Not to mention, Ward and co. are doing amazing plugin wizardry already : hooking data-feeds from Arduinos, graphing it, bytebeats, calculators. It already has a lot of what looked nice about QEDWiki.

The multi-panel view surprised me initially, but it’s really useful for refactoring. And that’s going to help me considerably with wiki-composting.

Finally, the “federated” part of the Simplest Federated Wiki is the answer to a bunch of problems I didn’t even know I had. Or, at least, didn’t conceptualise well. How do I have a private wiki (like a local SdiDesk, where I like to draft things before they go public) AND a public wiki (like ThoughtStorms) and make it easy to move newly public stuff from one to the other? How do I balance the desire to have special project focused wikis (like the OPTIMAES one) with wanting to refer to that stuff from the main wiki? How do I balance contributing to my own wiki and contributing to other communities’ wikis?

So, I’m sold. As Dave Winer likes to say, it’s the second mover who makes the standard. And that’s what I want to help with. There’s enough overlap between the SFW and the things I’ve been wanting to do over the last few years that it makes sense for me to implement my ideas as plugins for the SFW, to port my wikis over to to it and to go around shouting about how wonderful it is. Because, actually, it is pretty damned wonderful.

So, Project ThoughtStorms is where I’m putting the code: so far, converters from the ThoughtStorms UseMod and the SdiDesk formatted pages, and plugins to render the markup. I’ll be porting ThoughtStorms over to a SFW server soon. Then I’ll be doing some serious refactoring and cleaning up the actual writing. Trashing a lot of the ephemeral junk and dead-links. TS has become a bit of a museum, which it shouldn’t be. It should be a living, learning, and forgetting thing.

After that, I’ll be sitting down to do some of the other things I’ve wanted to do in a wiki context but not had the platform to do justice to.  Now I think I have one.

My day-job means that I now have a github account.

And I have to say, I am very impressed by it.

I decided on bzr last year as my distributed source-control system, mainly because it felt so similar to svn and it was written in python. In comparison, git is still bloody confusing. But bzr seems to be losing momentum (hg is the pythonic candidate in the race) and git-hub with its YASN-oriented social approach to source-hosting feels way ahead of other repo-hosting services like Launchpad and Google Code or running my own Trac-SVN solution.

So, I’m quite likely to switch my projects over to github in the near future.

PS : Oh, and if felt really cool to just fork my own repo of Folknology’s Reactored. Encourages me to start playing with it.