Sandy blogged about Forkolator, which is a project to make forking web applications easy. There isn’t yet a lot of documentation on Forkolator, but from what I can glean from the web site and a glance at the source code, the idea is basically that each web application (Wikipedia, GMail, Forkolator itself) would include an IDE for forking the app.
Apps as platforms
In Marc Andreessen’s categorization, that would make Forkolator-using applications level 3 platforms – the hardest to create.
Sandy paraphrases Erik saying:
Erik believes that the data layer of the app would probably have to be well-defined and untouchable by forkers.
That makes things easier (though still far from easy), but we should consider that it also limits what you can implement in your fork. For example, I don’t see how you could realistically implement a label system for your mail app without the ability to add new database tables or the equivalent.
Writing web apps is just hard
Aside from the whole freedom aspect, one thing that we should note is that writing web applications is generally very hard, period. It requires a lot of expertise to do even passably well. Depending on the application of course; an online stopwatch is a little bit easier than eBay. Is there work on making writing web apps easier that could be leveraged to also improve forking apps?
Incentive
One angle that seems critical to any effort like this is creating an incentive for the application maintainer to support these changes.
Levels of modification and APIs
If the goal is “chrome” level modifications, an entirely different approach would be Greasemonkey-style client changes. From what I understand (though I haven’t looked myself), GMail effectively has a JavaScript API one can code to, and this lets things like Better GMail work in a maintainable way. Of course though, it’s usually not going to be straightforward for a web application author to fold a Greasemonkey script back into the site.
So to make a system maintainable there have to be defined APIs. As Andreessen says, a level 3 platform requires all of the level 1 and 2 work. I don’t see how something like Forkolator could work without them. If you want to make say a modification to Wikipedia that makes editing more collaborative, it would need to hook into the APIs for modifying pages, etc.
Some attempt at a conclusion
I’m not sure I’d completely agree with the assertion that “web apps are killing free software”; Free Software use on both the client and the server is growing (at least it appears so to me). Now, web apps are definitely killing certain types of software, Free or not. The challenge is to preserve the spirit of Free Software through a computing shift.
I think that while we don’t really have a shared “free/open/principled” service definition yet, there’s a general consensus around some points like data access APIs and source code availability. So it will make sense to continue evaluating services in that context – if they support a Forkolator-style approach, that’s even better.