What if we could remove the complexity of technology as an obstacle to social good? What if a nonprofit could become dramatically more efficient by using on demand, Internet delivered services? Looking at the current landscape of nonprofit technology products and services, this seems like a timely conversation.
The Code
Open Source
Open API's
Closed system
Service (or software) Delivery
On Demand / Web 2.0
ASP
Shrink Wrapped
The Specifics
Office Suite
Collaboration/Groupware
Graphic and multimedia production
Telephony
Hard Copies
The Code
The first grouping is interesting to the extent that there is a unique ability of the "software" to bend to the specific context of a nonprofit organization and/or the nonprofit sector as a whole. Open Source software can be focused specifically at the nonprofit sector (ie CivicSpace, CiviCRM...) or an individual nonprofit can customize an open source project to fit their particular needs. Experience shows the latter option to be the most problematic as the customization is usually costly or kludgey and quickly siloed. The current movement of rapidly maturing open source projects built specifically for the nonprofit sector seems to me to be very promising.
The piece that is missing is hosting (this is the Democracy In Action model). The goal here is to remove IT burden and complexity from nonprofits. To my mind, a reasonable goal is to remove all "servers" from inside the nonprofit and replace them with trusted "services". (Probably a thorny issue best moved to another thread?). So, the ability to connect/integrate multiple services becomes critical.
This is the domain of Open API's (Application Program Interface). API's are relevant to specific applications. An API is a collection of “commands” that can be leveraged by users to augment or enhance how an application is used. API's are used to create mashups or to build new custom functionality. The "open" in this case refers to the existence/availability of the API not to the legalities of accessing the API's. Additionally, Open Source is not Open API. If the source code is open (as in Open Source) then, theoretically, one could write an API and make it available for anyone to use (ie, make the API open).
The idea here is that any one who has full access to a service could use the Open API to create connectors to any other service. The classic example is Google Maps and something else that's online but we could see some more interesting integrations soon like CMS, CRM, e-commerce, groupware and even completely virtual computing environments.
Closed systems are dead and we don't really need to talk about them. Ask any of the closed system vendors. They are all trying to figure out how to be provided by an ASP (Application Service Provider) or how to provide a robust Open API. Their customers are demanding it.
Service (or software) Delivery
There is clearly a trend towards the Internet as a platform for services delivery. There are at least two distinct flavors, On demand and ASP. While this is a subtle difference, it is a critical distinction to pay attention to when trying to choose a service. On Demand is a term that I am choosing, somewhat at random, to represent an application that is built from the ground up to be provided via the Internet (ie salesforce.com, the corporation part of the corporate foundation that employs me) as opposed to a traditional client-server environment that is offered via the Internet by an Application Service Provider. The distinction speaks to the services ability to scale on the Internet as a delivery platform.
As for shrink wrap. It's dead too. It will just take a long time for it to die. The first stage is purchasing software on line to be downloaded and installed on a local workstation our LAN server. The second will be a move toward virtual computing environments where the Internet, as a platform, hosts tasks like word processing (writely.com, ajaxwrite.com) and spreadsheets(numsum.com).
It looks like the ondemandnpo wiki got hit with massive amounts of comment spam. So here are some quick thoughts that I would have posted on the wiki:
- More robust office suite & WYSIWYG/WYSIWYP ("what you see is what you print"). I think these are coming along. I'm excited about the potential of Buzzworm (from Virtual Ubiquity/Adobe) to tackle the WYSIWYP issue.
- Disability/alternative access issues. We have several staff at our organization who regularly use voice dictation software (Dragon NaturallySpeaking). The current state of Dragon is that it is *much* better optimized to work with Outlook and MS Office than it is to working via a browser. It does work with Internet Explorer, but it's harder to use Dragon to work with Google Docs than it is with MS Word. Hopefully there will be innovations down the road to reduce this disparity, but it is an obstacle for total on-demand adoption for a percentage of users out there.
Posted by: Seth Schneider | October 23, 2007 at 11:30 AM