One wiki

I like running my own web software. Sometimes that is a problem, because if I have a bunch of ideas for a particular software project, I can obsess over the details of setting up farm instances, with robust backups and turn-key deployment. When I figure all that stuff out, it is very helpful for my work. It is how I go into this, actually. WordPress, Drupal, and a whole bunch of other things.

Being paid is helpful, because it tends to give me focus. An example is that back in 2005, I had more blogs than blog posts. Fortunately, after the “maiki blog bubble” popped, I was able to get some writing done. People exchanging cash for development tends to make me more productive. However, after a while, I feel like this is a job, instead of my paid hobby.

I am fairly certain I am obsessed with wikae, Wikipedia in particular, but the idea of wiki in general. At least once a day I wish the internet was just a big wiki. I don’t think that is a good idea, but it is actually a pretty cool way of thinking about the net, and how we use it. Anyhow, the point is that I am really into these tools.

It was a problem. My ratio of wiki articles to wiki instances was closer to 1:1 than care to admit. There was my personal public wiki, then my personal private wiki, then the ones for recipes, character sheets, tech stuff, fiction bible, and then just a whole bunch more for anything I could think of.

MediaWiki is cool software, but it doesn’t come installed in a form that is easy to use. There are literally a bunch of dead links, right out of the box. And it uses a database, which practically doubles the requirements for installing it (in the context of someone using a hosted web service). Also, there are annoying things, like how URLs are created (maiki doesn’t have capital letters in it). Since I was deploying so many wikae (which really should be the plural of wiki), I turned to DokuWiki, which I still think is much better for what I was trying to accomplish. In fact, I still recommend folks look at DokuWiki before MediaWiki, if they need something that just works.

This all changed recently. The first reason is that I am starting to actually collaborate with others a lot more, in a way that makes using a wiki helpful. Much like git, the network effect increases the value of wikae by a lot. This lead to the catalyst, which was in trying to create workflows that I knew to be possible, I was essentially recreating MediaWiki’s core functions in DokuWiki (which is part of the reason I am not as enthusiastic about Drupal anymore). And then there is Semantic MediaWiki

Since looking at alternatives for Drupal, I’ve been looking at the Semantic MediaWiki extensions. Well, I’ve been playing with them for a while, but it didn’t click until just recently. When you get to add structure to a wiki using form validation, it just adds this layer of abstraction that feels like a giant sandbox of awesome to me!

So, I gotta get into this, ne? But what about the initial issues? What about maintaining a bunch of instances of MediaWiki, isn’t that a pain?

Well, it totally is, but I was fortunate enough to get a fresh perspective on it. Over a series of discussions with Kevin, I was able to express my concerns, and answer to them. I really just needed a soundboard, but it had to be someone who was directly affected by my decisions, so they could provide feedback. Kevin and I are writing a lot of fiction these days, as well as all the other projects I have going on. Once the choice to be transparent with our process, to the point of working in public, we opened up the path I’ve decided to take.

One wiki (to rule them all [except *.Wikipedia {of course}]).

Let me point out the sandbox thing again… w00t!

Having decided that, I’ve been spending time pruning and moving over content from a variety of wikae to a single MediaWiki instance. It is a great relief, because I feel like I can actively fill in a wiki now, instead of spending time maintaining the software for all of them. We still have some meta-pages to set up before I unveil it, and I would like to do more research into account verification extensions (hesitant to use reCAPTCHA, but I know I need something). I will also be writing about how I am using git submodules and symlinks to keep the extensions set up.

If I am not blogging as much, you know where I am. ^_^

Also, I use マイキ as my login. So there is that.

Theming licenses

I am in a kind of odd spot with a project I want to do. The idea is to create a unified theming system for the different software that my site is composed of. I say system, because some of the software is more complex than the others, but really I just want to output the same HTML (as much as possible) using each template engine, and then apply the style-sheets and whatever other enhancements I can figure out.

The first wall I come to is how I would license it, because I do plan to distribute it. My difficulty comes because I want it to be consistent, but each of the software projects involved are released under different licenses: DokuWiki (GPLv2; license FAQ), Drupal (GPLv2 or later, license FAQ), StatusNet (AGPLv3) and WordPress (GPLv2 or later, clarification in licensing language).

Huh, I hadn’t caught the change in WordPress going from GPL to GPLv2 or later at the time.

I want to figure this out for myself, but also to clarify how “GPLv2 or later” works.

First scenario, if DokuWiki (or rather, GPLv2) were excluded, I could release a theme under the AGPLv3 and it would be compatible with Drupal and WordPress because it is compatible with GPLv3 (and obviously it is compatible with itself, in StatusNet’s case).

Second scenario, including GPLv2, I can release it under a dual-license of GPLv2/AGPLv3, which while kinda defeats the purpose of the AGPL, allows the theme to be licensed depending on the software that it is for. Hmmm, this made more sense in my head, but now it is just a pain in the ass.

Okay, smart people who I know are not lawyers providing me with legal advice, can you give me some feedback on how to best do this? I personally don’t think that having the theme as AGPL is essential, since I don’t plan on doing anything interesting with the code that is not related to styling, and I don’t think that styling has to be shared with visitors to a site. However, I like the AGPL, and start there when choosing a license. My point is, I am open to discussion, and would like to know what options there are.

Please reply in the comments here, or ping me on my slice of the social web.

Post script: I should note that I left out the non-code license issue aside, in hopes that it would simplify this. I will likely license the rest of it as CC-BY or CC-BY-SA, if that means anything to this discussion.