We've had various good efforts now at building mass provisioning solutions for Drupal. But too often we're building solutions in isolation, in competition, without enough resources to pull them off. We end up with duplication, half-finished products, privatized code. To put it mildly, it feels like we're not making the best use of the potential of open source.
I'm speaking from my own experience at CivicSpace, where I worked for a year and a half on enabling mass hosting. Through the process of wrestling with all the practical problems of producing a secure, high performance, flexible provisioning system, we got a tone of insight into what's needed and produced some creative and valuable solutions.
But they're not out there. They're not being used.
Looking e.g. at Hostmaster, it seems like a pretty similar story. A single company making a huge investment of talent and creativity into a codebase that ultimately may be a bigger task than they can support.
So I come out of this experience asking: how can we bring together the players here? How can we make the best use of what we've got in play--which is a lot, actually? Take just the pieces we produced at CivicSpace. Some of them aren't even open sourced as yet--specifically, the Taskmanager provisioning system and the Packages install profile system. But even those that are probably no one knows about. Like the Theme Factory project, http://drupal.org/project/themefactory. Here is an answer to a key mass hosting issue, how to provide powerful theme design tools without exposing the security issues of allowing clients PHP access. But who's there to even tell about it, let alone take on the (actually, I suspect, fairly minimal) work of shepherding it into something that can be broadly adopted?
And so I've been wondering, do we need something like a non-profit consortium? Call it "DropHost". A grouping that brings together the companies and other groups and leading individuals that are committed to solving the problems of mass hosting? Not to actually do the work of producing code. But to set the standards, to coordinate, to facilitate.
Does this make any sense?
Are there better ways to promote common solutions to the problems of mass provisioning, so we can confidently move forward? And maybe in the process actually get some broad value out of the significant pieces that have already been produced?
Comments
Sure
Added MayFirst/PeopleLink to your wiki on this, because their in it specifically to organize shared resources for social movements online.
Every Drupal shop, even those that do a few sites, heck Drupal power users could benefit from packaging and a lot of the stuff you talk about. I would be for coordination under most any auspices and I think the first step of releasing the code should be taken as soon as possible.
benjamin, Agaric Design Collective
benjamin, agaric
Coordination needed, yes
We do mass hosting where I presently work, as well. Our current production stack is using Bryght's Hostmaster (1st generation). We are currently building our new architecture systems, and are moving away from Hostmaster because of several reasons. One, a couple characteristics of hostmaster make it troublesome for our use. Two, it is rather specific to Bryght's business model, which in many ways is vastly different from ours, causing anachronisms and other challenges.
No doubt our business model will remain very different from virtually all other mass hosting organizations. But there are clearly many areas in the mass hosting effort where common tools can be used across many different business models. Thus, my hope for such a proposed organization would be that it remain cognizant of the large differences in needs and operational models that various mass hosting organizations will have. As a result, I would further hope that tools developed would keep an eye towards flexibility and modularity which would allow them to be used in a variety of business and operational models. Surely, some will be very specific to some kinds of mass hosting which will make them re-usable by organizations with similar business models, and yet not usable by others. That is ok. I would only hope for some significant subset of tools which would be widely usable.
A pair of examples: hostmaster 1 has the concept of clients and resellers. Presently, neither of these make any sense in our environment. Therefore, we never use those capabilities, and their added complexity makes our management a little bit more difficult. But hostmaster's ability to define several versions of software and multiple profiles is very valuable to us. Thus, the ability to segment such pieces into modules which can be used alone or mixed and matched would be a fantastic benefit.