2009-11-19

Win-win

Thought leadership that does not translate to leverage through exclusive ownership is an excellent paradigm for success and creating value.

Creating environments where as many as possible win as much as possible, is a more general and even more widely applicable truth super set of the above one, but it offers less useful and easy to apply cues, clues and information.

Google does a great job of that in the field of web search, marrying users seeking information on topic X and commercial entities selling topic X centric information and solutions.

The web does a great job of creating a publicly accessible place to convey, create and consume information and many aspects and sorts of culture and entertainment, largely without middle-men and gate- keepers, at least for the technically minded portion of the creative class.

Palm seem to be making a good attempt at bringing this to the mobile industry, that has been very far behind the game in those respects, so far.

Apple has traditionally been making good efforts at creating an environment where the user, the developer, and Apple, win, in their computer and to some extent music industry ma ouvers. They are doing a terrible job with their mobile app store.

Mozilla.org has made a valiant attempt at making web users and web developers win, by opening up the web browser as a platform subject to evolution without central governace and vested interest gate-keeping, but have to date done a similarly bad job with addons.mozilla.org, which has a loud primary imperative of making mozilla.org not lose, likely in some US law centric contorted version of liability. This very likely applies equally to the Apple app store.

User scripts (via Greasemonkey in Firefox and other Mozilla derivates, user javascript in Opera and Google Chrome, Greasekit in Safari and other Webkit derivates, IE7 pro, Trixie and others in Internet Explorer), aim for and to varying degrees manage to open up web content to being improved, recontextualized and made more available and easy to access to users, where formerly gate-kept by web site owners.

This post would be better contained by ending here, but I feel I want to diverge a bit into a side track about a project close to heart to me -- Greasemonkey -- and how its politics relate to the above, and what has been going on there, recently; feel most encouraged to break off reading here, if disinterested.

As a Greasemonkey maintainer, I effectively in part act a gate-keeper for what goes into Greasemonkey and (somewhat stream-linedly) all web browsers of those running it in their web browser. That does not mean I want to remove from user scripting the element of being subject to the un-gate-kept evolution, but it does mean that I have an agenda about to what extent the project and product named Greasemonkey subjects its users to security hazards, complexity of usage and opportunities for sabotage (whether through any ill intent, or merely unfortunate accidents made possible through ill-thought-through or ill-conveyed design) and irrevocable breakage.

The actual codebase of Greasemonkey explicitly does not come with that agenda, though (it is MIT licensed, which I'd say roughly translates to "take it apart, borrow or evolve parts or all of it pretty much any which way you choose, with or without attribution, but don't pass it on to others under the guise of carrying the same guarantees or governance Greasemonkey did -- such as by attempting to claim and market and redistribute it under the same name, logo and the like"), and I know I speak for both myself and Anthony when I note that we put it up on Github with the express purpose of making it easy to fork off and improve on with as little friction and gate-keeping as possible.

Github makes it very easy to do so, which is good. It is a fantastic place for rapid evolution where everybody are naturally cooperating with each other.

We're a bit sad that it unfortunately (so far, at least) does not come with enough controls and measures to bound ill effects of people that do neither cooperate nor take constructive input, but does whatever they themselves decide best. The codebase we host is protected from ill effects like that, but the wiki is not, which makes it very easy for anyone to poison projects on Github, through poking about in a project's wiki pages, under stealth guise and semblance of project officiality. This wiki can be hidden, but not turned off, and anyone following the project will get news of the latest stream of edits and spammage.

We have one or two (might be the same person, might not -- it's not important) self-appointed wiki editors doing this, disregarding from input from us maintainers, wreaking some havoc with taking the official Greasemonkey wiki's content (after having been banned there, for the same reason), reworking it and adding disinformation here and there. Very likely just from failing to realize that it is wrong, but the end effect to readerships is bad, whatever the reason.

All the good annotation support (the wiki, of commits, in tickets, on lines of source code in the repository itself, and so on) thus becomes unmanageable, when a busy agitator spams it with venomous attitude and tone, setting a example for collaboration by poisoning the well for us. The lesson in it for us may be that if we want to set a friendly tone and maintain the cooperative but guided evolution we prefer, we need to self host the repository and all of the channels we operate, though the only thing we really care about is the project itself and how our efforts in that direction don't get wasted on administrativia and baby-sitting unlistening back seat drivers.

I think this is a plea to Github to make more people win, by letting poisonous people lose.