emerging: techstrategy.org - Designing for Civil Society: Top 10 Open Source Tools for eActivism. Weblog: emerging: techstrategy.org
Source: Designing for Civil Society: Top 10 Open Source Tools for eActivism
Link: http://techstrategy.typepad.com/emerging/2004/01/designing_for_c.html
I love the graph...
....though there are many more f/oss tools for e-activism out there. I am collecting....
I recently wrote a case study on ActionApps, the CMS developed by the Association for Progressive Communications (APC) that appears as #1 on the above-mentioned list. Here is it is, for everyone's edification. I am endlessly fascinated with how NGOs can take better advantage of the possibilities of Open Source development, in particular and am thinking about writing my thesis on the very topic--including what capacity the sector need to develop to pull this off. For a road map, Jonathan Peizer's piece comes to mind again.
Meanwhile: Case studies of NGOs undertaking f/oss development for mission-critical apps are welcome! And now to ActionApps....
Action Apps: What is It?
ActionApps is an open source content management system (CMS) developed by the Association for Progressive Communication (APC). APC is an international membership organization of civil society organizations focusing on the strategic use of technology and the Internet. Members include non-governmental ICT providers working on human rights, environment, peace, and social justice. The APC member groups are partly activist organizations and partly businesses offering alternative ISP and web development services to other NGOs in their respective countries.
ActionApps was specifically developed for this network to offer it as a service to their NGO clients in turn. Initial funding for the development of ActionApps was provided by the MacArthur Foundation, the Open Society Institute, and the Canadian Development Agency.
Technical Overview
There are two main components of the ActionApps platform: 1. simple web publishing, and 2. automated information sharing between sites.
Action Apps’ built-in content pooling functionality allows sharing between sites running on the same server, while cross-server networking tools allow sharing between servers. ActionApps can also share simple content with other applications using RSS. ActionApps is currently in version 2.4.
On the content management side, ActionApps has a forms-based interface for online publishing, incorporating tools such "Action Alerts" which allow new items to be sent to users by e-mail; a calendar function, message boards and a site management tool. ActionApps is also useful for distributed portals with information hosted on multiple servers to promote and increase traffic to online information as well as for information sharing between multiple sites hosted on the same server.
Specifically, ActionApps provides substantial support for collaborative information sharing, making it easy for local campaigns to share content widely through cross-site and server publishing permissions. Obviously, this solution makes a lot of sense for organizations that already have close associations, are part of a coalition, or run joint campaigns. The interface is multilingual with versions in English, Spanish, Czech, Romanian, German and Japanese. A French version is under development.
ActionApps is open source software, released under the GNU GPL. It is listed on sourceforge with a small group of developers providing the bulk of support and ongoing coding.
ActionApps runs PHP/MySQL. It plugs into existing web sites without imposing a fixed page layout or having to migrate existing sites, making it a relatively easily integrated tool. At the same time, however, because of ad hoc development described more below, ActionApps has over time grown a large and somewhat cumbersome application, less useful if the main functionality desired is simple content management rather than collaborative publishing and content sharing.
Who is Using It?
According to some estimates, ActionApps has been deployed by over 700 organizations. Since no one is keeping track of precisely who is using it and for what specific purpose, generalizations about how it is deployed are somewhat difficult to make.
Most of the APC member organizations use ActionApps and provide hosted Action Apps ASP services to NGOs in their respective countries. Many of these organizations also run portal sites that share content from different sources and client and partner organizations, an especially powerful feature of ActionApps. According to Michael deBeer, the former IT director of IGC, a currently dormant U.S. APC members, he has seen anecdotal evidence of an uptake in organizations installing and using Action Apps, though I could not get independent verification of this assertion. There are about 80+ organizations listed on the APC website as having been verified of actively using Action Apps.
A few examples of ActionApps use in civil society organizations include:
ChangeNet.SK
An online civil society portal including daily news and opinion articles, a calendar of events, and database of Slovak not-for-profit organizations.
ItrainOnline
An online clearinghouse of training resources, developed by six organizations working in ICTs for development.
Electronic Immigration Network (EIN)
A dynamic web site of legal information and resources on asylum and immigration.
Greenpeace: Solar Energy (Czech)
This specialized news page is managed entirely with ActionApps.
Canadian Partnership for Children’s Health and the Environment (CPCHE)
CPHE developed an "information ecosystem" that allows 10 Canadian CSOs to share content between their sites and feed into a central portal on children’s environmental health systems.
ed de Desarrollo Sostenible de Colombia - Sustainable Development Network Program of Colombia
Portal of the SDN of Colombia, made with 35 APC action applications slides, to manage information of news, events, users, job opportunities, etc.
What analysis was done before beginning work on the application? Was there a business case or plan?
APC operates very much as an association, offering services as needed and requested by members, and generating revenue through member dues (and foundation support).
The project plans for the development of Action Apps centered on the notion that APC member organizations needed additional service and product offerings to remain viable in what turned into a rather turbulent time for ISPs.
The business planning for Action Apps therefore focused on APC members being able to generate revenue through consulting and ASP services which, in turn, would lead to sharing of ongoing development costs.
However, Mark Surman, the original project manager for APC (now with the Commons Group), says that the notion of passing continued costs for the development of Action Apps to members turned out not to be a very solid sustainability model. As a result, continued development of Action Apps beyond the initial foundation support has been ad hoc and funded by customization requests of individual NGO clients.
Other planning and support for ongoing work was, in keeping with the organizational model of APC, more distributed and indirect but not insignificant. Since APC is only as strong as its members, it has always been interested in helping them stay viable as both activist organizations as well as small ISP and Internet service businesses. To that end, APC has put significant resources into helping members develop business plans. APC conducted, for example, a series of “mission driven” business planning workshops for its member in Mexico, Eastern Europe, and the UK in 2000 and 2001 that emphasized business planning for Action Apps.
In conjunction with these workshops, APC published a “Mission-Driven Business Planning Toolkit” for its members to provide new ways of thinking and hands-on tools for APC members to stay competitive, especially as the small ISP market has collapsed in the US and is rapidly changing now in other countries, especially the Balkans and South America. APC members in a number of countries such as Canada, Czech Republic, Bulgaria, Slovakia, Columbia, and the UK, among others, have made hosted versions of Action Apps part of their service offering.
Viable members meant continued--if intermittent-- development of the application. In reality, it was the more financially stable and well managed APC members such as Econnect that to this day provide the bulk of ongoing development, financed through their NGO clients that need specific functionality.
In fact, Econnect, as the recognized “expert” on Action Apps continued to get contracts with other organizations looking for customization or added functionality. APC has tried to support this ongoing development by publishing an “Action Apps Service Development Guide” more specifically geared towards helping APC members think though offering Action Apps within the context of their overall organization. Just recently, as part of a large conference in Ethiopia, there were several Action Apps service development workshops. Similar workshops were held also in late 2002 in Johannesburg, South Afica.
Overall, the business planning for Action Apps has been quite concerted with a good deal of resources behind it. Ongoing development has happened “on the periphery rather than the center,” according to Surman. He calls this an “artifact of APC’s structure which often emphasizes services to and by members over core development.”
Most recently, there has been some realization that there needs to be a new influx of money that is not client-driven, to reengineer the application’s architecture, improve usability, and make implementation easier. However, unless there is a strong business case made for ongoing development and use of Action Apps, strong project management, an organization taking this on as a lead, and increasing funder interest, it appears unlikely that there will be funds available for such a significant overhaul.
Development of ActionApps: Who and Why
ActionApps’ development is best understood in the context of the organizational history of APC. In the 1980s, the APC network utilized Usenet discussion forums as their publishing medium. For example, Usenet groups were used as a collective platform for press releases for local NGO end users. As the World Wide Web developed, this rich collective publishing platform gradually disappeared, making way for simple individual organization’s web sites that in no way resembled what had been an extensive pool of intellectual and activist knowledge. By 1997, initial conversations started within the network to develop better tools for publishing to recreate a collaborative medium for information sharing while allowing member organizations to keep their own identity through their individual web sites.
The initial project was aimed at updating the APC conferencing system and integrating it with publishing and other intranet components. Very quickly, however, developers realized that this was too ambitious a project without sufficient resources. APC decided to shelve the discussion fora and abandon the intranet components in favor of focusing on a collaborative content management system as a tangible service that APC members could offer to their NGO users in their respective countries. Mark Surman put it succinctly: “The question quickly became: What is the real thing we need and what are the resources to do it?”
In the initial ‘visioning’ and planning phase, APC in various council meetings and face-to-face presentations created a desired feature set and submitted a proposal to OSI and MacArthur for more detailed requirement gathering and actual development. However, while project managers under the direction of Mark Surman tried to be very thoughtful, he acknowledged that, at the time, they did not have a thorough grasp of software development methodology and, as a result, neglected to focus adequately on end-user requirements which hamper the usefulness of the application to this day. This, of course, was true for many others who had moved from basic web page creation into web application development in the late 1990s. The team also did not limit the scope of the project initially, resulting in delays as the scope was narrowed from a rather large software integration project as described above to one focused more narrowly on web publishing.
The Decision to ‘Go Open Source’
True to its decentralized function as a governing council of its member organizations, APC conducted the initial needs assessment through a collaborative process that was initially agnostic about using proprietary versus open source tools to build Action Apps. In fact, the assessment pointed towards using Lotus Domino Notes, attractive also since IBM had a charity program. However, as discussions ensued, this direction led to significant internal conflict with some APC member organizations that favored developing an open source solution.
In my conversations, I heard two primary reasons for why a proprietary platform for development was rejected: 1. APC members in developing countries objected to the IGC-proposed solution of Notes as “technologically imperialistic,” as well as 2. not appropriate for NGOs in developing countries. There was also an (incorrect) notion that Domino would have required large servers centrally controlled, anathema to the fiercely independent culture of the APC members. The proposed solution was also highly complex and would have required significant training that many of the smaller AC members did feel they could afford.
Surman says: “In the end, the ideologists were the most pragmatic. What looked at first very risky, turned out to be very brilliant. PHP was new then but it turns out that today it is the best, most practical route for what APC wanted in terms of functionality.” As Michael deBeer points out, it also resulted in Action Apps being relatively quickly and easily installed regardless of bandwidth and hence much more lightweight and portable.
APC ended up deciding in favor of using open source development tools as well as an open source development process primarily for ideological and cultural/political reasons under pressure from some of the more vocal member groups. Both Michael deBeer and Mark Surman argue that this was a smart solution in hindsight even though it was fraught with some conflict at the time.
Who was Involved in the Development?
Because of APC’s organizational structure where decisions were made by a representative governance council of member organizations, there were a number of groups and individuals from Europe, South America, and the United States closely involved in the overall development of the application from the beginning, even though Econnect was contracted with as the main developer.
As Jonathan Peizer of OSI points out, “the process resembled and represented the network, with all its strengths and weaknesses.” On the one hand, there was strength in this approach as the ability of the partners was able to be leveraged. Econnect in particular, a Technology Support Organization and ISP in the Czech Republic, was, as Mark Surman said, “the hero of the story,” by putting in extraordinary amounts of development work and focusing this work on functionality that was not effectively dealt with by commercial providers. In particular, according to one of the original developers, Marek Tichy, Econnect had a solid grasp on the business model of Action Apps that was based on APC members’ ability to offer their NGO clients dynamic sites. Econnect, which had already begun development of its own CMS system at the time and had investigated the space, focused the development of Action Apps to plug into existing sites without having to re-design entire sites from scratch.
Other specific projects such as the development of training and marketing materials, were distributed to APC members in sync with its governance structure. Because specific projects were undertaken by a far flung set of actors, project management became more complex and as contracts often were not clear enough in specifying timelines and deliverables, the process was drawn out and not as timely as it could have been.
Econnect continues to very much involved, with several staff people considered to be the respected and skilled lead developers for Action Apps. This, of course, is a key to sustainable Open Source projects where there is typically, contrary to popular myth, a small team of highly-respected programmers that provide leadership, continuity, and expertise.
Functional Evolution
Functionally, Action Apps evolved significantly and organically as members began using the application. Originally, Action Apps had been envisioned primarily as an ASP service where multiple NGOs would share a single software install on a server run by their local APC member. There also was a significant emphasis on content pooling originally as its main value added. However, content pooling did not take off as widely as APC had hoped. A variety of reasons were postulated for this: the technology was initially not stable and user-friendly enough, and this functionality was not marketed aggressively enough so many members never saw the value. There were also cultural and political impediments in that many NGOS were reluctant to share their valuable content with one another, though there are impressive examples of successful content sharing. These include Bulgarian environmental groups sharing news and information content (wws.see-environment.info) and a Canadian site that syndicates eight different organizations’ content using Web Networks (www.actew.ca).
Many of the APC members offer hosted Action Apps services as ASPs, partially a result of successful APC marketing and training on business development. One example is Web Networks in Canada that runs a successful Action Apps ASP business.
Action Apps continues to be a valuable tool for building dynamic web sites, content management, and content sharing. While many CMS systems are more user-friendly and flexible, Action Apps as a ‘content object’ system oscillates, according to Marek Tilchy, an Econnect programmer, between “a rapid application development platform that is quite powerful and a traditional CMS system.”
Because of the ongoing development that at times was project-driven and ad-hoc, only about one third of the code, according to Michael deBeer, is well designed, of high quality, well vetted, and well documented. These include the permission system and email notification system, for example. Other features added on over time are not as elegant. But there is continuous improvement: when the multi-lingual versions, for example, became too hard to organize and keep track off, Econnect reengineered the entire system from scratch to improve it significantly.
What are the Support Models and Continued Development?
As implied above already, individual APC members around the world offer and support Action Apps to their organizational end users. APC, in turn, supports the business operations of its members, provides resources such as manuals and development guides, and maintains the central Action Apps web site. APC members that sell hosted Action Apps services, provide hosting, consultation in setting up the application, training, customization, and continuous user support.
Today, there is of course, an open source community that extends beyond APC. Action Apps is listed on Source Forge and there is a normalized bug tracking, feature request, programming, and documenting process in place. APC is still part of the conversation in terms of feature and programming priorities but in terms of actual development, upgrades and new features, Econnect in the Czech Republic is the main hub that manages ongoing development. Documentation and FAQs are maintained mainly by committed volunteers such as Jason Diceman of the Canadian organizations The Commons Group.
What are Ongoing Issues and Challenges?
There have been a number of lessons learned and ongoing issues and challenges in different areas that are worth pointing out.
As Marc Surman said repeatedly, there were overall weaknesses in the development process. In the mid-90s when Action Apps was in its initial development, no one in the non-profit world thought about formal project management methodologies. User and technical requirements where developed by trial and error and there were a lot of misunderstandings initially about scope and goals of the applications – some of which are still not resolved to this day. Even though there was a project proposal and module-by-module descriptions, this was not enough for focusing goals and scope. More formal technical requirements gathering would have been useful. APC clearly has gotten more technical as time went on. What made the project work, despite its lack of clarity initially, was the strong social capital within the organization and its network that helped immensely in “working things out” in the heyday of development with a distributed team.
More importantly in the long run was one particular weakness: there was not enough user involvement and testing from a usability perspective. Surman calls it the “classical error” that would have been remedied had the UI development preceded and been separated from the actual coding. Additionally, as a result of ad-hoc coding and feature additions, the interface and implementation grew complicated as feature sets started to grow. Particularly back-end UI is a critical consideration that typically NGO developers do not want to spend money on but that ultimately will increase the effectiveness and adoption of the program.
Possibly as a result of the complex UI and difficult installation, adoption was slow, as Michael de Beer pointed out, only now picking up somewhat if anecdotal evidence holds true.
The overall market environment has changed as well. While Action Apps was one of the early Open Source content management systems, there are now hundreds in what has become an incredibly cluttered environment, making new uptake by other organizations less likely and marketing more challenging.
At the same time, Action Apps has some unique functionality that continues to make it attractive. Mark Surman put it well in an overview of content management systems
“Unlike all of the other software listed here, ActionApps lend themselves to both creating a large dynamic web site and dropping a small dynamic section into an existing site. The ability to drop an ActionApp into an existing site makes them perfect for site upgrades and for small organizations. It also makes them a good option for Web service providers wanting to set up ASP services.
The ability to share content between sites is the other major difference between the ActionApps and other services listed here. At present, complex content such as events, bibliographical records and even full articles can be easily and automatically shared between any number of ActionApp sites. Most of the other software listed above is limited to sharing headlines using RSS…”
(source: http://www.commonsgroup.com/ideas/fulltext.shtml?x=212, accessed 12/26/03)
On the other hand, Action Apps has a steep learning curve as it is a complex system to realize. It has its own syntax, the documentation is quite old, and many organizations experience frustrations initially trying to implement the system.
There is now a push to generate the next layer of resources, though less for a comprehensive redesign but for the development of additional applications that extend Action Apps, such as an encryption module, and a constituency engagement piece that different APC members are seeking support for.
The main challenge for the ActionApps application itself is fragmentation, mainly because of very customized, project-specific feature and functionality additions that are not ‘generic’ enough for the community at large using ActionApps. This is the draw-back of the current model of financing ongoing development through ad-hoc projects.
As Marek Tichy points out, developers originally planned to develop a system that “can do loads of things but it also simple to use and install.” He says: “We somehow believed we could do this, but then people started using it and asked from more and more features. End users wanted to publish content and webmasters wanted plug and build a site around it, and now you have a very powerful system that is also very complicated to set up.” He, as everyone I talked to, advocated for a redesign to clean up the code, re-architect, and update the documentation to make ActionApps more usable and adoptable to a wider range of organizations.
Changes in the Market
There are also other external factors that influenced the development and deployment of the ActionApps: The ISP business model that APC and its members had propagated fell apart in some places, like the U.S., where cheaper and more customer-focused commercial providers began undercutting the APC member ISP services, resulting in significant loss of revenues. IGC, one of the flagship APC ISPs, folded amidst significant internal turmoil, and others were struggling. While the ISP market consolidated a while ago in the U.S., it is now undergoing some of the same changes in the Balkans and South America.
As a result, APC members looked for other business opportunities to stay in business, such as hosted ASP and web development services, possibly explaining partially an observed increase in ActionApps adoption in the last year or so. This, interestingly, also circumvents the complexity of setting up ActionApps.
Summary:
In sum, Action Apps is a fascinating development to investigate, both in hindsight as well as in terms of its ongoing evolution as users continue to change and modify it according to their needs.
In relation to its original goals, it can be considered a reasonable success. It is used widely in the (admittedly small) APC network for which it was intended, used within that network for its core strength of content sharing and collaborative publishing, and is to this day continuously improved and developed. It is not widely adopted, of course, outside of the APC network, and has not taken any other market by storm, nor has it made anyone much money. But it has filled successfully the niche for which it was intended.
It may be important to think then, particularly in terms of Open Source development and the NGO sector in particular in more relative and specific terms about the ‘success’ of a software, especially once it is released and mature. Open Source software in particular in its ‘sustainability’ phase as mature software is much more in flux and not following a straight roadmap dictated by straightforward ‘business’ principles. But, as Robert X Cringely said in a recent column:
“The lack of a roadmap for Open Source means that there can be dozens of similar projects, some being born, some dying, and others forking into new identities. Since there is no single architect for Open Source, these projects all have to compete for manpower and user interest. Most Open Source projects die, but when they do, it is a death Darwin would understand. Every death improves the software bloodline.”
It may just be that this is something—even in an environment of scarcity—that funders and developers ought to thrive for in the NGO sector as well.
[PubSub: RSS]
10:56:55 AM 
|
