Invision Power Board (and presumably most of its commercial competitors, such as vBulletin) follows what I would call a “shared source” model. Shared source also happens to be Microsoft’s official term for a very similar offering, though while in their case, this type of source licensing is restricted to specific kinds of customers (such as governments and high-profile corporations and organizations), it applies to anyone who has a non-hosted license of Invision Power Board. Including MYSTcommunity. Wikipedia has a small comparison table of open source and shared source, which fits roughly with how I see things as well. There was also recently a discussion on reddit, but I strongly disagree with its premise that “‘Shared source’ is bullshit”. It would be bullshit if Microsoft called it “open source” or otherwise insinuated that it is a comparable mechanism, but to my knowledge, they have never made such a claim.

Now, being a “shared source licensee” of Invision Power Board means that I can see the source code of the software in its entirety. In a way, that’s quite nifty. With most commercial software – be it an operating system like Mac OS X, productivity software like Microsoft Office or creative apps like virtually anything from Adobe Creative Suite – , you don’t have that luxury, and probably couldn’t even negotiate a Microsoft Shared Source-type deal. With Invision Power Board, you have this by default. Historically, there’s a good reason for that: it’s written entirely in PHP (and it’s semi-predecessor, Ikonboard, originally in Perl), both of which are primarily designed to be interpreted languages. In other words, you don’t compile into a binary, nor into bytecode; you leave code as it is and have it dynamically dealt with during runtime. Because the PHP interpreter expects to work this way, it wants to see source code, so IPB has to provide it. Indeed, at the early days of Ikonboard, most web applications, commercial or not, had their source code available to any customer whether the developers liked it or not. It was how things worked.

But these days, that is not enough reason any more for IPB to be open source. As the trial version introduced with 2.0 attests, it is quite possible to avoid this, by using an encryption mechanism that decodes the code on-the-fly. While it’s probably possible to crack the encryption (I haven’t looked into this at all, but I can hardly imagine otherwise), it’s probably just about hard enough to make it not worth the effort. (And there’s the usual arguments that apply to any kind of anti-piracy measures. E.g., by the time you’ve actually managed to decrypt the entirety of the source code, there might be a new version already with a different encryption algorithm, and eventually, bugs, security holes, lack of features and other incompatibilities will force you to upgrade.)

So Invision Power Services could have decided to stop releasing the source code to its customers, but they didn’t. Perhaps to avoid the outcry over such a measure – many customers, including yours truly, have gotten used to the perks of this. But perhaps also because they understand, just as many of their customers do, what a powerful tool the ability to completely adjust the software to your needs and preferences can be. This is not about open source. It’s not about having a community that, together, builds a great application. That’s a nice objective as well, but the concept I call “shared source” has its own unique strengths.

It is theoretically possible for an open source project to become a worthy competitor to commercial alternatives, and it is also possible for companies to build their business around offering paid support for such an effort. But with bulletin board software, this hasn’t happened. Anyone who tells you that there is a viable alternative to IPB, vB or Groupee (or whatever they’ll call it next year) when running even just a medium-sized board simply doesn’t know any better. phpBB 2.0 is a pain, and its successor has been delayed for years. punBB, bbPress and Vanilla are great for small-scale boards, but that’s just it: they don’t scale. I fortunately haven’t had the displeasure of working with Groupee, but both IPB and vB deserve to be called gigantic in comparison to open source contenders. IPB ships with its own “kernel”, its own cross-site authentication mechanism, a module system to plug other products in, an updater that almost couldn’t be better, and an amount of features that, every now and then, makes you discover new abilities you didn’t even know the software you’ve been using has had all along. This is far beyond the standard of, say, WordPress, which sure enough ships with its own templating and plugin system, but, among many other problems, makes updates a pain.

None of this is to say, of course, that I dislike working with open source software. I’m writing this on WordPress and don’t mind all that much. I also use MediaWiki for that other Myst website I run. Three out of eight desktops apps I’m running as I type this are completely open source, and another two take significant components from open source projects – not to mention all have probably been built with a tool chain whose bulk is open source, thanks to projects such as gcc. In short, I’m not arguing against open source; I’m arguing for not discounting an app just because it isn’t gratis or has its source readily available even for non-customers. What I truly need and prefer plays the primary role, not what it costs or what I have to agree to.

It seemed a difficult decision at the time whether we should buy a lifetime license, but in retrospect I’m confident about the choice; I’m happy that we have done so. Once we finally did move to 2.0, so many things became easier, and I have no doubt 3.0 is an even brighter future to look forward to. Not without flaws. Not without big annoyances. But with lots of heart, soul and thought put into it. And with your ability to read the source code, the silly comments all over the place are a free bonus.

Over the second half of 2006, IPB put the finishing touches to the 2.2 release, and naturally, we’ll eventually move there as well. (By now, they’re at 2.2.2 already.) But this time, I won’t repeat a mistake of the past again. This time, I’ll use GNU diff and patch.

With an open-source project, that would be a no-brainer. Version control systems even encourage it; Subversion, for one, lets you dynamically create a unified diff file of two different revisions. But with shared source, it’s a little more complicated: I’m obviously not at liberty to just share the entire files that I’ve been working with and then submit the changes. The solution? Instead of placing source files in the repository, I’ll place minimal diffs of my actual changes in there, meaning Subversion would provide, quite literally, a diff of a diff.

To give you an idea:

 +
-+                      if ($update_array['starter_id']) {
-+                              $IRCline .= "[".$update_array['starter_id']."]";
++                      if ($this->ipsclass->member['id']) {
++                              $IRCline .= "[".$this->ipsclass->member['id']."]";
 +                      }

To be sure, dealing with the two prefixes in front of each line takes a little adjustment, but it’s well worth it. Modularization (components, plug-ins, extensions) and abstraction layers are nice; working straight with the source has its benefits too, though. To provide a similar level of flexibility, an extensions system (akin to, say, MediaWiki’s) would have to provide an absurd amount of event hooks, which would mean much more work for the software developer and – hard to avoid – much lower performance. By contrast, I can append code at the exact line of code I wish. It’s fast, and it’s also predictable.

The process of adding a feature (or extending an existing one) then boils down to this:

1. I place the entire source distribution into one folder – currently, _distribution-2.2.2, then make a duplicate of it in the same folder, named after the feature I wish to add – in the above example, irc-notify.
2. I modify the duplicate to reflect how I wish to change the source code.
3. I run ipbdiff on it to write the changes into a patch, in this case: ipbdiff _distribution-2.2.2 irc-notify > irc-notify.patch. ipbdiff is just an alias, as defined in my bash-compatible .profile: alias ipbdiff='diff -dw --unified=0 -x "\.DS_Store" -r. -d avoids too large patches, -w ignores whitespace changes, --unified=0 uses the unified format (just like Subversion does by default) while leaving zero lines of context, thus avoiding sharing code from IPB itself, -x "\.DS_Store" removes Mac OS X-specific metadata that would have no use in the source code, and -r recurses the entire source trees, comparing everything in between.
4. I review the resulting patch. I use TextMate for this, although there are certainly far better viewers for graphically inspecting diffs, but this is generally good enough.
5. I commit the patch as a file in the MYSTlore Google Code repository. As a result, Subversion comes up with the funny diff-of-a-diff, as shown above.
6. I upload the patch to a live IPB installation, then install it with patch, e.g.: patch -p1 --verbose < irc-notify.patch.

This method has helped me greatly for streamlining the IPB upgrade process even further. With a new IPB release, I can now upgrade, upload the patches I want, and just run patch -p1 --verbose < *.patch to have all of them applied. I've only recently started with this, so I unfortunately haven't had a chance to see yet how this behaves with newer versions, but even if it were to spell much trouble, it would still only be a matter of updating the patch accordingly. Certainly worth the effort.

The road to IPB 2.2.x, therefore, hasn't been anywhere near as a bumpy one as previous upgrades have been (this despite the fact that, this time, we're also upgrading our own custom skin for the first time, courtesy of Tay), and one major person to blame is myself; I could have started this practice a lot earlier. A sure case of misplaced laziness – such preparatory measures may seem tedious at first, but in the long run actually saves you lots of time and effort.

And in a way, I can even say that I'm looking forward to having an IPB 2.2-powered MC going public. Maybe that's because there's more stuff coming in the not-so-far future. MYSTcommunity usage numbers have been down, and in the recent weeks, my excitement over Uru has been as well. But my interest in working with fellow people among the Myst fandom is still alive and kicking.