Hi there,
I'm a longtime Zope (and sometime Plone) developer with an active interest in both the social dynamics of open source development and application of technology for social change.
I work with Mapunity (.in), an organisation that can be described as Bangalore's version of The Open Planning Project. We build technology solutions for social causes, with a particular interest in traffic management and community mapping (and hence the name). I found Mark Gorton's message on your site, on the dual commitment to activism and technology particularly inspiring.
This evening Akash and I got talking about his implementation of OpenCore for the Headstart Network, and in the process I got the impression that keeping up that dual commitment may be far harder than it looks.
I'm curious because I've noticed this exact problem in the projects I've been involved with. When some technology is built for a purpose that is not inherently dependent on the technology for its existence, the quality of the technology is always lesser priority than its impact on the application space, and consequently, the technology platform's own growth tends to be stunted.
Take for instance OpenCore's assembly of components from Plone to WordPress, and the continued dependence on ZODB when everyone including you guys have decided it's too problematic in the long run. It suggests to me -- speaking purely as an external observer -- that OpenCore got built the way it did because your greater priority was in enabling the collaboration space than in doing it elegantly, and that now that it's up and in use, redoing it in a future-proof way is even less of a priority.
Do let me know if I'm way off mark here.
I've been grappling with this problem for about a year now. As someone who's a technologist first and a social activist only a distant second, it strikes me as being _economically_ inefficient to not give the technology side of it greater priority. Code is far more expensive to maintain than to create. Custom written code may be an asset in the short term, because it has IP value and because it enables a desired intervention in the social space, but the same code turns into a maintenance liability in due course. This is true of pretty much all code; the only way to lower that cost is by distributing that liability -- which is exactly what open source achieves, especially an open source platform or library that is widely adopted.
There are factors governing growth of an open source component's userbase, and key among them are the timing of its appearance on the landscape, and the usability of the code: of how much effort it takes for someone to pick it up and build on top of it. Granted the first is usually a lucky accident. The second however, is a conscious act of whoever supported the effort (apart from being an outcome of their technical ability). Given it is a factor reasonably within one's control, and one that is very important to keeping the long term maintenance cost low (for the individual user), surely it is something that needs greater attention at the very beginning?
I'll accept that the folks who initiate such projects tend to be technocrats attempting to make an impact in a non-technical domain, with no particular interest in the details of how the technology works, and that oftentimes they too are constrained by upstream funders; that the chain of constraints is such that no single person can be held accountable for why some software became a liability in the long term.
Perhaps someone should write a paper examining this space and making recommendations for how to manage technology projects for social change; something that could be used to argue for more efficient prioritisation. If done well, it could even hope to achieve the same sort of impact in this space that the flurry of papers explaining open source achieved a decade ago.
What do you think? Would your experiences suggest a similar problem with prioritisation? I'd love to know if you think this is worth exploring.
I left my last (very hectic and socially motivated) job at Comat (.com) in November and since then have been on a self-funded sabbatical trying to make up my mind where to go next. I'm testing the waters with Mapunity because I identify with the social causes they target, but feel there isn't enough understanding of how the technology side should be handled and want to look at that instead. You guys have been doing it for far longer and more openly, so surely you know a lot more about this.
Take for instance OpenCore's assembly of components from Plone to WordPress, and the continued dependence on ZODB when everyone including you guys have decided it's too problematic in the long run. It suggests to me -- speaking purely as an external observer -- that OpenCore got built the way it did because your greater priority was in enabling the collaboration space than in doing it elegantly, and that now that it's up and in use, redoing it in a future-proof way is even less of a priority. Do let me know if I'm way off mark here.
I think there's a strategic importance to the "assembly of components from Plone to WordPress" which is to make use of existing best-of-breed tools in their domains, provided they are open source and community-driven. The idea is that this is a way to maximize the application's surface area for collaboration; to lessen the maintenance risk on the custom application's developers; and to open the door for a sustainable economic model where the development of the composite application (OpenCore) is funded in part through contracts on the underlying components.
Maybe I should unpack that last statement. The idea is that if OpenCore is stitched together out of customized configurations of well-known open source applications for blogging, task management, wiki, HTML WYSIWYG editor, theming engine, mailing lists, and so on .. the OpenCore development team can develop its customizations of those platforms as reusable libraries/plugins/themes and release them to the upstream communities. We'd then be benefitting (in the "given enough eyeballs" sense) from other people's parallel use of these modules; we'd be building up our reputation and expertise in those application platforms we're using; and we could then leverage that reputation and expertise to take on short-term commercial contracts in those areas, which could then fund further development of our platform (OpenCore). I also believe this is a highly scalable model -- if we end up having a very high volume of contract work coming in for one of the components, we can try to farm some of it out to the community (as a sort of investment in the community itself) and/or spin off a semi-autonomous team dedicated to development on that component.
I began to strongly push for this development model when I became a manager at TOPP in 2008. It did begin to show some promise while I was there -- we did begin to get opportunities for paid work on the Trac task management system and the Xinha WYSIWYG editor. (We were not using Trac as a component of OpenCore itself but we were using it heavily for our internal process.) But unfortunately I never got a real chance to see whether the idea had merit, because TOPP's commitment to the OpenCore project was already wavering by then. This was precisely because of the issues you identified: a deep organization tension between the social commitment and the technical commitment, or between realizing short-term implementations and aiming at long-term goals. The fact was that TOPP's "immediate client," the Livable Streets initiaive, needed polished tools immediately, and TOPP's leadership decided (not unreasonably, but, to me, terribly disappointingly) to scale back the long-term ambitions of sustainable open-source models in favor of building what the client needed right away -- installing some WordPress sites and a few bespoke applications for one-off initiatives.
So Jackie and I both left TOPP in January 2009, deciding we would rather try to do OpenCore on our own than abandon it. I've been working on it in my spare time over the past year. Obviously it needs a tremendous amount of work even just to get to the point where we *could* seriously try out our sustainable-growth ideas for it. (For example, I want to throw out our custom-built task management system in favor of a Trac integration if possible; I want to throw out WordPress in favor of a blog app like Zine that is written in Python; etc, etc, etc, etc, etc....) I'm hopeful that we'll be able to move faster on it soon -- we've been speaking with TOPP recently and are in the final stages of an arrangement where TOPP will provide the hosting funds for Coactivate.org for a year or two and will otherwise hand the site over to us entirely. I see that as essential to moving the ideas forward for a number of reasons. So we'll see.
Anyway, let me try to get back on point. What is interesting -- and so challenging -- about the model I am describing is that it can only possibly work if the software's high-level design and low-level code are elegant, useable, and modular. In fact I have come to think that good large-scale software design, sustainable economic models for development and growth, and maximization of "open-source-ness" (code sharing and reuse, community-building, etc, etc) are all actually one and the same thing.
I also think that this is a reusable pattern which could be applied to any initiative that wants to address a social problem with technology -- and, in fact, I think this pattern *must* be applied to any social-technology initiative that wants to avoid the twin traps of short-term solutions -- which, over time, seems to generally mean complete dependence on short-term grant funding and donations and at most a linear return on all investments -- and .. well, being bought out by for-profit corporations and pretty much sacrificing the social objectives.
(Meta-aside: well, it seems pretty unlikely that this is the *only* such pattern that could work in this sphere. I would be very interested to hear of other patterns that might succeed. I would also love to figure out the pattern of these patterns! -- what is the form of the problem that they seek to address, and what are the factors that a successful solution-pattern must have?)
Anyway, this email is long enough now. :) I would love to talk more with you guys about this topic in general. I share your suspicion that this is a topic that *must* be studied, and that has the potential for huge impact.
Developments in the tech world over the past year or two have, frankly, depressed me -- it seems that everybody these days is talking about "technology for social change" and "open source as an asset" (not to mention "sustainable initiatives") but the true practice of those things, and the understanding of what they truly mean, is lagging far behind, and is in danger of being drowned out entirely by buzz.