When we make new Internet communications systems, we should probably develop side systems first.
The “Main System” is a system that a SideSystem attaches to.
It could be something like the IRC infrastructure, or a wiki, or a scoop site, or an instant messaging infrastructure. Just “some system” that’s “out there.”
It probably has it’s own architecture, development process, collection of developers and documenters, the whole works.
A “Side System” is a system that latches on, like a monsterous bloodsucking parasite, to a MainSystem.
You’re probably writing a “side system” if you are taking advantage of:
Side systems are easy to make, and to attach to stuff. (Get permission, though, if it’s going to be a big strain on a main system.)
You don’t have to work with the MainSystem. You don’t have to take part in a formal development process. You don’t have to get what you write integrated into the system. You just write your hack code, and you’re off and running.
The big disadvantages is that the side system is extremely vulnerable to changes in the main system. For example, if the devs of the main system change a protocol, and the side system happened to be listening to the wire, suddenly the side system breaks, and needs to be adjusted or rewritten. Yuck.
I have come to believe that when we want to extend a public communications technology, we should adopt the strategy of SideSystemsFirst:
If the SideSystem is good, it is likely to become popular.
At that point, the SideSystem effort is no longer necessary.
If you have an idea for how to grow a major public communications technology, these seem to be your options:
Working in the main system means that you have to convince hoards of developers, who already have their own ideas about what they are doing, and what’s important, that what you are proposing is a good idea. The main system may actually be a collection of many systems (for example, if you are implementing InterWiki tech, then you have many wiki engines to work with), and then not only do you have to convince one development efforts, but a ton of development efforts. All of which have their own ideas about what’s important, what’s worth doing, etc., etc.,.
Or, you could try to create a completely new system. But then you have problems even getting people to use your new system, which is likely immature, and radically different than existing systems.
In these situations, you can make a SideSystem. You will be able to get it up and running usefully, relatively quickly, and then as people come to rely on the system, it will be worked into, (hopefully,) the MainSystem.
I was able to hack MoinMoin to send notification, but hadn’t a chance at getting ThomasWaldmann to make it a permanent feature of MoinMoin. Developers are busy. They have things to do. While they may like the idea of the PersonalLogServer, other things seem more important.
I stumbled across a project called IntComm:CIA. I was amazed at how they were able to collect so much data, from so many sources, to make such a useful tool. “How did they do it??!” I asked myself. I studied the pages, and discovered that they relied on SideSystems?.
I now believe that if I had worked on the PersonalLogServer as a side system, that it would have been much more useful and interesting. The efforts spent on trying to get it integrated with main systems could have been much better spent working on collecting data by side systems.
Subversion (SVN) managed to completely rework CVS, from the ground up.
However, people hated CVS so much, that people were really eager to see SVN..
Even so, SVN worked hard to have a similar UserInterface to CVS, so that people wouldn’t resist it.
I like this page
As you might have predicted, I very much agree with the page! Thanks for writing this page.
Jon Udell talks about “Streetwise Librarians and the Revolution in Libraries.” and “ad-hoc integration” http://www.xml.com/pub/a/2004/03/17/udell.html . The tool he wrote is definitely a side-system. He complains about the few systems (“non-RESTful systems”) that are unfriendly to such side-systems.
The whole anti-non-REST stuff is totally bogus.
But that’s not what I came here to say--
I just wanted to say: I’ve been strongly questioning SideSystemsFirst lately. I think I have a good critique. I just don’t have time to make it right now. D’oh!
There; It’s now up: PlatformsFirst.
If you want to build infrastructure, you can’t do it at the edge of the network.
The main flaw with SideSystemsFirst is the time that it takes to move the new infrastructure into the center- it takes too much time and it is unavoidably political. It’s cheaper to just make a new platform.
Or, minor clarification- by making it part of a new system, by making it part of a new platform, that you have some control over.
I’ve been thinking of this analogy recently:
A mashup is like a collection of utensils (a fork, a knife, and a spoon): A mashup has parts distributed over several web servers. If one part breaks, you can still use the other parts while the broken one gets fixed. It’s easy to add just one more thing to the collection. You can mix-and-match the best parts from independent organizations. However, the more servers it is distributed over, the more likely it is that at least one server is broken.
A platform is more like a swiss army knife. All the parts are bolted together into one unit, so that you can be assured that all the parts are compatible with each other. If someone comes up with some improvement in one part that requires a specific version of the other parts, it’s easy to swap the whole thing out. Also, as long as you have it in your pocket, you know that you have all its parts – no need to keep track of all the pieces seperately.
Is my bias obvious?