As someone who's spent 25 years designing applications, mostly database backed, my snap
reaction to this is "wow, a lot of people are gonna waste a whole lot of time -- theirs and
other people's -- before they figure out that there's no practical way to do this."
The problem is that applications need, at the very least, to be under one adminstrative span
of control, if not the hand of a single architect.
We have enough problems with the (theoretically) useful concept of object/module reuse -- have
you ever worked with any sufficiently complex application that depends on enough other
packages? I have, and let me tell you, dependency hell is *not* enjoyable. I can think of at
least a couple projects that deal with the issue by bringing along their own copies of every
other package they use, because the cross-dependencies are complex enough to make trying to
maintain everything impractical, never mind what happens if your auto-update utility bumps
something.
And now you want to let $RANDOMs in to write code against your datastore?
Hee. This will be fun to watch.
Posted Dec 16, 2008 12:34 UTC (Tue) by erikpukinskis (guest, #55615)
[Link]
For what it's worth, I expect most applications designed for Forkolator would be separated into a web service and a front end. Despite your apparent fear of such a thing, sites from flickr to facebook already let $RANDOMs write code against their datastore.
For the reasons you cite, people who fork the web service end of things, would have strong incentives to get their changes merged in upstream. And upstream maintainers have incentives to merge them: more active developers.
Front-end forks, on the other hand, could live a long time, and stray quite far from the parent, since there is a clean interface between them and the data store.
Anyway, "This will be fun to watch" is probably enough reason to give it a shot. I'm certainly not doing it because I think it will be easy.