I wish I had known about it...

In nonprofit technology we have a knowledge problem. Britt Bravo is the community organizer for Techsoup's Netsquared project. She pulled together an email list of "builders" for the Netsquared community with a Yahoo Group.

My first reaction was why didn't they use NPOGroups? Britt hadn't even realized the service exists.

This highlights the basic question of capacity building. Technology is just a tool... so pick the tool that works... why worry about whether it builds the capacity of the nonprofit technology sector?

BUT as we imagine a world of web services and central databases of constitutents, the question becomes will Yahoo respond to nonprofit needs? Probably not... they don't represent a powerful customer base. Compumentor will not be able to use the information on Netsquared builders for future initiatives without some fancy import/export work.

In reality, we have a definition problem... what does capacity in nonprofit technology mean? The ecosystem that supports the nonprofit community as a matter of mission isn't particularly strong. In the nonprofit technology arena, it is almost exclusively vendors driven by profit as a primary motivator. In no way am I suggesting that nonprofit technology vendors aren't good folks, but they certainly aren't comitted to universal technology access for any nonprofit that wants to use technology tools.

I like to call the general negative reaction I get when I propose there should be more mission-focused nonprofit technology players the "sounds like socialism"problem. It's pretty clear that funders aren't going to bankroll the mission-driven nonprofit technology ecosystem, but there is no reason the sector itself can't fund a more grassroots, micro-enterprise, open sourcey community of companies, nonprofits and intermediaries.

Why support Yahoo when you can support three guys at Electric Embers that work every day for nonprofits to have better access to technology? Not sure there is a clear answer, but it's a good question.

[1/27 update]
Not that this happens alot at Yahoo Groups, but Nancy White highlights one groups the lost their yahoo group. Wouldn't it be better if you knew and trusted the actual humans with names providing your technology?

Technorati Tags: net2, nptech, nonprofit

Small Nonprofits and Technology Planning

Michael Gilbert makes a solid point... we ask the wrong questions of nonprofits in the technology planning process. We ask technology-centric questions, rather than asking mission centric questions and then connecting them to appropriate technologies. As an illustration, he looks at TechAtlas and Techsoup.

Laura Adler defends TechAltas and Techsoup a little, arguing "Providing these folks with a means to less-than-horrible technology decisions is a worthwhile and even honorable goal."

I think there is another point in here. When I buy a car, I ask how far am I going to drive, what saftey rating do I need, am I going to spend a lot of time in the snow? These are the consumer equivalent of mission questions. But the end-point are "pre-packaged" solutions-- a truck, a car, etc.

What we haven't done in nonprofit technology is focus on assembling, building and providing the prepackaged solutions. Once those are in place, you can ask mission-focused questions and realistically connect them to technologies that will meet nonprofits' needs.

Laura says, "But in looking at the possibilities, we need to be sure to account for the nonprofits who can’t afford to hire us." If everyone has to assemble unique solutions from component building blocks to meet mission-needs, then nonprofits who can't afford to hire people to assemble these solutions are simply out of luck.

tags technorati : nptech civicrm net2

CiviCRM 1.3 Released

CiviCRM 1.3 is has been released including CiviContribute (Donor management and accepting online donations) and CiviMail (improved developer release of broadcast mailer with open and click tracking). 1.4 is around the corner. What do you think needs to be in 1.5?

Read the release announcement.

Where is the nonprofit API traffic?

Salesforce.com reports:

And from our modest beginnings with Sforce 1.0, we've seen the Sforce Web service API grow to account for over 40% of all of salesforce.com's total traffic. Think about that for a minute - the API is almost as heavily used as the salesforce.com Web application.

In the nonprofit sector, where is the API traffic? Do you access Convio, Kintera & Get Active via API? Can you build simple connectors to web applications like Steve Anderson does for the ONE/Northwest database consulting practice?

The issue, I think, is that we have yet to establish valid business reasons in the nonprofit sector for heavy use of APIs. Steve's use of APIs is primarily to get around the inherent limitations of the Salesforce.com salesforce automation software when used as a nonprofit database.

The big reasons for APIs are:
(1) Connect best of breed solutions. This tends to be at odds with most nonprofit software vendors' approach of being a "one stop shop".
(2) Create custom, technology-enabled business processes. Not sure the nonprofit sector is doing quite as much innovation to serve the homeless more effectively or run food banks more effectively as it perhaps should.
(3) Central data repository. Not sure the broad nonprofit sector really "gets" this basic concept of CRM.

What does the future look like?
(1) Vendors will be pushed to opening up their functionality. Nonprofits should be comfortable demanding that they be able to knit together a Kintera feature with a Get Active feature and have it all backed by a CiviCRM database (or any other combination that meets their needs).
(2) Nonprofits will become educated about what CRM can do for them.
(3) Smaller nonprofits will get access to affordable consulting and software services. (cause the APIs are really for the consultants)

Surmounting the barriers to using Technology to support Social Change

Jim Fruchterman of Benetech writes about four barriers that prevent web-based technology from producing social change. We think that the CiviCRM/ Social Source Foundation approach, based on the lessons of open source communities, is the best strategy for surmounting all four barriers.

What’s the great barrier to producing social change in general? Funding availability, especially to the most capable and dynamic groups. The web-based modifier doesn’t change that fact.

In a social source ecosystem, the vast majority of the money is generated in a commercial market. Firms and individuals selling services related to CiviCRM can generate sufficient resources to fix bugs, innovate, market the platform and generally "keep the lights on" in the community. Sure there are issues... free riders, commercial interests at odds with social change, but we believe they are surmountable.

A second issue is the difficulty in designing effective software for the social sector. The sector is reasonably balkanized, and market incentives don’t provide enough push to make better software, with a few exceptions (i.e., fund raising software). Plus, the users are not developers, and so it’s hard to understand what mission-critical tasks the software can effectively assist with.

In a social source ecosystem, users, intermediaries and developers are part of a community. They communicate through mailing lists, forums, events, and consultants. By increasing the number and frequency of communication channels, users can have access to ideas of "what is possible" in a language they understand, developers are specialized and focused on meeting nonprofit needs (and have a slightly better chance at understanding mission critical tasks), but the intermediaries are the key. That is why we spend a lot of time recruiting intermediaries into our ecosystem.

Distribution in the broadest sense is the third big barrier. Building it doesn’t make them come, generally. Marketing doesn’t come naturally to most social change groups.

Again, bring in the folks with the incentive to market. Small progressive organizations, for example, are often served by small consultants. Make ir easy for them to do their job and let them so the marketing for the ecosystem. Larger consulting firms spread the word to larger players. Here again, intermediaries are critical.

IP rights are the fourth significant barrier. When the money is not there, owners of intellectual property believe they cannot afford to go after socially oriented applications.

Which begs the question, why would anyone license software for social change under ANYTHING but an open source license (an aguement I've made before), preferably a viral one that actively ensures that innovations are shared with the community. It has yet to be demonstrated that innovation is stifled by open source licenses. In fact, as long as people can sell services, open source is a way to grow markets at the same time one reduces the cost of the item. Software becomes a commodity. Its cheap and there is an aweful lot of it... keep in mind there is big business in sand, lumber, coal, and other comodities. But buying some coal to heat your home is not particularly expensive.