From: XXXXXXXX
Sent: Friday, April 22, 2011 8:47 PM
To: Jon Stahl
Subject: RE: XXXXXXXXXXXXXXXXXX

Jon: I have taken you from the list.

Thanks for suggestions, but I like sending to diverse strangers, in the field
of XXXXXX, especially gov people who live in a protected (idea) world. There
is to much time wasted, "talking to the converted".

Actually, I get very few complaints.

Best,
XXXXX

> XXXXXX-
>
> With all respect, we all really need you to stop putting your
> entire address book in the To/CC line of your emails.
>
> It is creating a huge amount of unwanted email, generating a
> "reply all" storm, and it's absolutely terrible online communications
> etiquette.  Please consider starting an email list (e.g. at
> http://npogroups.org or Google Groups) or using a simple email
> broadcasting service like http://mailchimp.com.
>
> Please remove me from your list, too.  Thanks.
>
> cheers,
> jon

Sometimes I wonder why I bother.

It’s in that spirit that my colleague Sam Knox has been doing some thinking about how email broadcasting platforms integrate with Salesforce.com and report their results back.  Short version: right now, most vendors’ integrations are extremely inefficient with scarce Salesforce storage space.  He thinks they can do a lot better, and has written an important blog post that describes (exactly) how.   If you use Salesforce integrated email broadcasting services such as VerticalResponse, ExactTarget or MailChimp or are an email broadcasting vendor that designs your integration, I urge you to give it a read and share your thoughts.

MailChimp has a very slick email broadcasting system, and a very aggressive price point.  They claim to have a Salesforce integration, and so I logged in today and played around with a bit.

While much of the tool is really solid, the Salesforce integration is so rudimentary that it is actually completely, totally useless to us and our clients.

MailChimp can only import ALL of the contacts from your Salesforce account — no support for campaigns, reports, or getting any kind of targeted subset of your contacts. That’s bad, but I had somewhat expected it.

What’s worse is that MailChimp can ONLY import the following fields from Salesforce:

• first
• last
• email
• salesforce ID
• city/state/zip

That’s it. No custom fields. Zilch. I confirmed this with their tech support, who were very helpful.

Unfortunately, a Salesforce integration this limited is essentially useless for any serious organizational use.  Very disappointing.

The only glimmer of hope is that the tech support person told me the Salesforce integration is scheduled for an overhaul in early 2010, but didn’t have any details on the substance. So we will have to keep on waiting.

Bottom line: I had been hoping that we could recommend MailChimp as a solid, low-end, integrated-with-Salesforce email broadcasting solution.  But unfortunately the answer is, “Nope, not yet.”

While the article provides a pretty good overview of the space, it leaves out a few supporting details that I think are worth noting:

• Idealware’s article mentions that many CMS platforms have some email discussion list support, including Democracy In Action, Convio, Kintera, Drupal and Joomla, but neglects to mention that Plone also has such features, through its add-on product Listen.
• Idealware’s article mentions the great folks at Electric Embers, DGroups and OnlineGroups as nonprofit-oriented discussion list providers, but neglects to also mention the team at The Open Planning Project, whose OpenPlans service offers a very powerful, user-friendly web-and-email discussion list experience.
• Idealware’s article gives rather short shrift to several powerful open-source email discussion list solutions that enable more sophisticated groups to take control of their own discussion list hosting. Sympa and Mailman are probably the two leaders.  Idealware dismisses Mailman in passing, saying it and (unnamed) similar tools “aren’t as easy to use as many others, and don’t include features like archives or online groups. They can also make it difficult to view or export a file of the list of subscribers.”While it’s true that Mailman and Sympa don’t have the polished usability of some commercial discussion tools, they do include web-based archives and offer simple subscriber views and one-click export of the subscriber list.  Some hosting providers may disable archiving, but that’s not the software’s fault. The host-it-yourself path is not for everyone, since it does require some technical expertise to configure and maintain, but that’s also true of many of the solutions Idealware does mention.

Overall, good article, worth a read.   I hope Idealware will consider incorporating some of these additional details to round it out a bit more.

The core of the argument goes like this:

• Missions are serviced only by engaging constituents to action
• Engagement activities aren’t unique to nonprofits, so the tools aren’t either
• The best way to build software for nonprofits is to find tools that successfully addresses most of your needs and then add the nonprofit-specific functionality
• Software targeted at a larger market than nonprofits will improve faster than software specifically for the nonprofit market
• Software that has open Application Programming Interfaces makes the “build-on-top” model work
• There is a market for nonprofit-specific software that serves a defined function and is accessible via robust APIs

Go read the whole thing.

(The article supports comments, so you can leave them there if you like)

UPDATE: changed “effective” to “ineffective” thanks to eagle-eyed reader T.B.

I’m just saying.

Now for the constructive part: it’s better to send a highly compressed JPEG in the body of the message.  And even better to send legible text and/or HTML.

I think that the next few years are going to bring tremendous challenges for applications that do not easily communicate with other applications that are “outside their platform” i.e are written using a different language/framework, run on a different server, etc.

I think the most powerful path forward over the long haul is internet-based integration between great applications that were designed from the ground up to allow for it.  In other words, web services APIs are going to become increasingly more important, and the particular application frameworks less so.  This the “small pieces, loosely joined” model, to echo the phrase that others have appropriated from Dave Weinberger’s influential book. There are some great communities and significant resources behind very cool projects that provide great functionality that I really want to be able to tap. I don’t want to have either persuade them all to develop in a single platform (it’s just not going to happen) or try to duplicate all of their functions in whatever platform I’m most comfortable in. (Which, truth be told, is “none of them.”)

My colleagues here at ONE/Northwest and I would much rather focus on integrating best-of-breed applications that have strong web services APIs and are designed around the assumption that external applications are first-class citizens of their ecosystems. (Damn, that’s a lot of buzzwords.)

At the end of the day, why should I have to care if an application is based on Python, Zope, PHP, Rails, Django, or some technology I’ve never heard of? Why should I have to run all my applications off a single server? That’s not scalable. We now have a whole set of standards and technologies to let applications communicate with each other over the internet.

“Web services” is one of those complex, slippery terms that means lots of different things to lots of different people. To me, in this context, it means applications that share data with other applications over the internet. The more of your application’s guts it can expose to the outside world, the more powerful your web services API.

Some applications that I think are really moving in the right direction with web services support are:

• Democracy In Action — powerful API, alas, not yet well documented. Little known fact: the smart guys at Enfold Systems have releaesd a Python wrapper for the Democracy in Action API, which (supposedly) makes integration with Plone possible. Haven’t tried it yet myself. But I’m looking forward to it.
• Salesforce.com. Holy cow, these folks really get it. I’ve heard that half of their traffic is through their web services API. This is how a relationship management database should be — accessible by most any external application.
• WhatCounts. These guys do our email blasting. Lots of folks do email blasting, some probably just as well as WhatCounts. But what sets WhatCounts apart from the pack fo us is the fact that they have strong APIs. This lets us do cool stuff like pull in names from Salesforce, or inject new subscribers from Plone, or pull in content from a Plone site. (Well, technically pulling in content from the outside doesn’t use their web services API. But the point is that WhatCounts can pull in data from outside and let other apps push data in.)
• Another, less strictly “web services” example is Plone’s new PlonePAS framework. Basically, it’s a framework for authenticating users and retrieving user data from any old data source you’d care to write a plugin for. We’re going to try to use it to integrate Salesforce.com and Plone.
• The whole open-source GIS software ecosystem, most especially including MapServer. My next-door neighbor, Chris Davis of CommEn Space, has shown me some really mindblowing stuff with maps that dynamically draw in data from all over the internet, thanks to open data standards and web services.

Can you see an advocacy software ecosystem here yet? I can.

And let’s not forget all the “Web 2.0″ applications out there that are getting so much hype these days. One important thing about the most exciting of these tools such as Flickr and Del.icio.us is that they can be written to and read from by outside applications via web services APIs.  (Amazon has done amazing stuff here, too, albeit without getting much “Web 2.0″ credit for it.) This is where it starts to get cool. The days of monolithic application stacks that try to do everything are fading fast. A new “network-centric” software ecosystem is starting to bloom.

And the best part: nobody has to “deeply partner” or adopt a single platform to make it work. They just have to focus on building great web services APIs so that other applications can meet them halfway. That’s not easy, but it’s surely easier than getting everyone to adopt the same platform.

Some software tools that I really hope build strong web services APIs as they roll out their next releases include:

• Green Media Toolshed
• CiviCRM (their web services API work seems to have stalled out in favor work on a PHP API that only talks to a PHP application (like Drupal) installed on the same server. Hopefully their focus will soon return to playing with the outside world, too.)
• Custard Melt
• Advokit
• All of those nonprofit online donation tools that I am too tired to list right now. You know who you are.
• And, yes, Drupal, too.

I’m probably overlooking some other apps that ought to be listed here. Feel free to suggest them. It’s late.

Real-life fact: email drives traffic and participations. Implications:

1. Stop stressing about your website. Yes, it should have regularly updated content and look halfway professional. But it shouldn’t drive your strategy, it should be driven by your strategy.
2. Figure out what organizations have big lists and befriend them. In DC, this might mean MoveOn or Democracy for America. If you’re running a local organization, it might be your local Planned Parenthood or League of Conservation Voter chapter.
3. Always be growing. Constantly ask yourself “How can I make this into a list-growth activity?” Tell your list to tell a friend. Do campaigns that encourage signups. Partner with other organizations.
4. Write decent emails. Just follow a simple principle: write emails as if you’re talking to a friend. There are a couple of points that go along with this.
   • Your emails should be from human beings, not organizations. Put the name of a person in the subject line. The candidate, the campaign manager, whoever.
   • I try to do a “term paper check” a few hours after writing my first draft, where I go through and figure out which sentences sound like they belong in a political science paper, and delete them.
   • No email newsletters! People have very, very short attention spans. Figure out the action you want the email to focus on, and write the email around that link. Paragraph, link, paragraph, link, paragraph, link, signature. PS: link. Even though you also want to include a link to the photo gallery, and the front page, and the campaign you did last week, and the event calendar…don’t do it! Just pick one. Just pick ONE.
   • Write out the link. This sounds petty, but it makes such a huge difference that I would be remiss in not mentioning it. Do not make “click here” into a link. do not make the name of your campaign into a link. Write the whole thing out, with the http://www. for each one. People like to know where they’re going when they click.