I just had lunch with Paul Hagen, so almost every thought in this piece is at least 50% his. Paul, thanks for letting me steal your thought leader-ishness for a while.

Today, one of our community members posted a message on the N-TEN discuss list. For those of you not subscribed, I've posted a copy of the message. There's been an interesting discussion in the wake of this message, and though no one has said it out loud yet, the reason I'm particularly interested in this conversation is that it all comes down to a simple question that the sector has been grappling with for a very long time: How do I get my technology tools to work together?

If you'll indulge me for a moment, I'd like to take a trip back in time.

About 6 or 7 years ago, the nonprofit software market started to really take off. Both the number and the kind of tools that were available began to increase exponentially. Even then, everyone realized that the power of these software tools was great, but would only reach full potential if the tools could work together. We all know that the more you know about your clients and stakeholders, the more effective you can be as an organization. But this requires that your various stores of information - your CMS, your blog, your member database, your advocacy tool, your warehousing software, etc. - can communicate with one another and help you build a complete picture of the community you are serving and the supporters who are helping it happen.

At that time, there were three schools of thought about how this could best be accomplished. The first school of thought advocated for "all in one" applications. Software that could be your member database AND your CMS AND your advocacy tool, etc. The problem with this school of thought is that the same package of tools is not going to work for every organization, and it's expensive for vendors to try to develop 5 different kinds of email tools based on the unique needs of various customers. So while 70% of a package might be perfect for a nonprofit, they would go find other tools to fill in the other 30% of the needs.

The second school of thought was that nonprofits should eschew this one size fits all approach and choose "best of breed" applications, then figure out how to make them "talk" to each other. This would be best facilitated by a set of "data standards" that the vendors should adopt to make that communication between applications much easier. The problem with the second school of thought is that vendors had been economically uninclined to make their software talk easily with any other software. The thought being that it would require a retooling of their platforms, which is expensive, and there was little clear economic incentive to undertake the effort. So getting best of breed applications to work together has been clunky and expensive for nonprofits.

The third school of thought came from the open source community. Their idea was that if nonprofits would adopt open source tools, none of this would be a problem because, since the tools were open source, nonprofits could modify them in anyway they wanted, making any open source application talk to another. The problem here was that, especially then, open source applications were nearly impossible for end-users (i.e. your development associate) to use. The user experience was geared towards geeks, unless you paid a good geek a lot of money to make something very useful out of it. It just didn't work out of the box as easily as it should.

Well, two amazing things have happened in the past couple of years:

1. Nonprofits are mad and they aren't going to take it anymore.
2. Salesforce has proven that the old economic rules no longer apply.

I was VERY surprised when I started work on the 2006 agenda to hear members of the community ask for sessions on data standards (OPX anyone?). I hadn't heard those words uttered in a long while. Turns out that, as the tools have gotten more affordable, and nonprofits have gotten more sophisticated, more and more organizations are struggling to make all of their software tools talk to each other. I had a conversation with a nearly hysterical Director of Development at a very large DC nonprofit who was irate because she couldn't get her activism data into the database with her donor data so that she could send out better appeals to her organization's activists.

So I knew that the issue was in play again. The option of all-in-one-applications hadn't panned out. Clearly, nonprofits have pursued the best of breed solutions. And those solutions, by and large, have been proprietary. In most cases, the open source offerings are still to un-user friendly to make up a large share of the market place (and I say this as a loyal CiviCRM user).

So what to do? We have a bunch of frustrated nonprofits who are wasting a lot of time pushing data around. I thought it might be time to pick up the data standards mantle again. But I see now that its the right solution in the wrong time. In other words, that would have been a fine answer 5 years ago, but one behemoth has changed the paradigm, and now the problem calls for a different solution entirely.

Enter SalesForce.

SalesForce flew in the face of conventional wisdom and opened its API, or Applications Programming Interface. (Yes, Google probably had the most influence here, but it's SalesForce who has applicable model for the sector here.) Turns out, lots of businesses were getting fed up with their myriad data sources as well, and Salesforce correctly guessed that it could capitalize on that frustration. The open API means that anyone who is designing a software tool can see the "map" of the SalesForce product and design their tool to communicate seamlessly with SalesForce. Because SalesForce already had a great list of clients, software developers were all to eager to re-develop existing applications or create new ones that would serve the unique needs of niche audiences, but communicate seamlessly with the core application, SalesForce. Consequently, SalesForce became even more valuable to its current clients, and even more attractive to its prospects. Need proof that the model works? Paul Hagen told me today that 50 to 60% of all calls to the SalesForce system are from outside applications.

So the winning answer isn't an all in one tool, best of breed tools with data standards, or open source software (although open API's would never have developed had it not been for the very robust Open Source community). It's a combination of the three. It's an open architecture that promotes the development of specialized tools to meet niche needs that can work together as seamlessly as an all in one tool.

There's still time for the major players in the nonprofit software space to catch on and make it happen. I'd love to see the day that a Drupal website can ping a Kintera database to display the names of the newest donors at an organization.