PublicScript

MeatballWiki | RecentChanges | Random Page | Indices | Categories

This is a general idea; the specialization to wikis is talked about on CommunityProgrammableWiki.

One of the differences between the site proprietor and the rest of the community is that the proprietor has total control of the technology. This creates many social problems because the script is very powerful. The script is more than just a constitution, and it's more than just architecture. It's the combination of the two that gives the script its strength. The law is both what's written and what's enforced. In civil society, the enforcement is separated from what's written because it requires an executor, like the PoliceForce, to enact it. Online, the law embodied in code is both written and enacted simultaneously. This gives the proprietor unreasonable powers, the ability to "bend reality with her thoughts," thus making her into a GodKing.

Even a BenevolentDictator isn't adequate, as a NegligentLeader? quickly becomes malfeasant when upgrades to the script are required. Excellent examples abound amongst OpenSource projects, including UseModWiki and MeatballWiki. Leaving the control of the script in the hands of one person or a small number people makes it much more difficult to make necessary changes once those people stop caring.

The solution to this seems simple just by applying the Principle of DevolvePower: give control of the script to the community. For instance, give control of it to a NonProfit corporation. More in line with the WikiWay, make the script publicly editable, say by using FileReplacement. However, in practice it isn't that easy. For the same reasons we don't have a RawHtmlWiki, it would be quite dubious to allow people to edit the script. Any number of problems might arise.

The most obvious problem is security. People might make changes to the script that cause damage to either the server or the users or even the network at large. Adequate PeerReview would alleviate this risk, of course, provided the community has a suitable number of technically trained people reading over the changes. Another security risk is the release of sensitive information, like passwords or file locations. Solving this perfectly requires some complicated cryptonautic maneuvers. Of course, the simplest solution would just to keep the sensitive information in a separate file, such as a small, private "loader" script that wrapped the PublicScript.

A much more dangerous problem, however, is a catastrophic error. A buggy script may blow away the database. A merely broken script won't even run, preventing access to the entire site, thereby "crashing the universe" so to speak. Either of these scenarios is fatal, but fortunately we know how to deal with fatal errors. The database can be protected by regular back ups. Once again, the script could be wrapped in a "loader" that, on event of a crash, would allow the user to replace the script with the last known good version. e.g.

: Error 501. Total universe implosion. Please click here to revert the script to the last known good version.

It would be also very advisable to use a two-pass system whereby the development script is first tested on a dummy site before being adopted for the mainstream site.

Another problem is that, unlike English, code is highly sensitive to changes. Bugs are much more severe than poor writing, and they are much harder for a PeerReviewer to catch by eye. A good CommunityExpectation to maintain would be to write strong Wiki:UnitTests for every change.

The final problem is probably the hardest to solve. Many webhosting services would probably not appreciate having a site with a PublicScript because they would be afraid it might damage their system. This is not unreasonable, of course, but if you want to try this, it's up to you to convince them it's safe. In fact, it may be a good impetus to check and double check the robustness of your strategy.

If you're not willing to be this radical, at least publish the script openly. A little OpenProcess goes a long way. Just consider how the Case of Badvogato would be alleviated by publishing the back-end script.

Publishing the script also solves that pesky OpenSource dilemma for WebApplication?s: how can the users have access to the source, if the source is hidden away on the server. While it's arguable that the actual user of the script is the site proprietor, that's not really very important. It would be a nice thing to do to allow the users access to the script running their community.

PublicScriptStrings?, recently implemented by MediaWiki, is a middle way between a full-blown PublicScript (with attendant problems) and a traditional PrivateScript?. All strings used in the script are taken from specific wiki pages. So you can change the checkbox from "This change is a minor edit" to "This modification is trivial" if you like. MediaWiki uses AccessLevels and SecurityByObscurity to protect those strings from vandalism, but one might equally use simple DelayAction.

CategoryWebTechnology CategoryWikiTechnology

PublicScript

Discussion