’nuff said.

I was only vaguely following the brou-ha-ha over Causes leaving Myspace. Only vaguely because I don’t really keep close track of the goings on in the Social Networking space: it’s not my passion. I use them a lot, both for work as well as for personal use. I know they are becoming an increasingly important tool for nonprofits in communicating with their constituents, and so I do keep them in my peripheral vision, for sure.

Anyway, in reading the varied reactions to this news, I had to just sigh, and then get annoyed. Sigh because of what feels to me to be the wasted energy that the nonprofit sector has spent over many years, using, hawking, and supporting proprietary tools and companies. Annoyed because it seems the nptech community hasn’t figured this out, even being hit over the head with this over, and over, and over again.

Make no mistake about it – Causes is a for profit company, and they are making what is, I’d bet, a decision based entirely on economics. If you’ve read any of the gloomy news from Silicon Valley, this is just the beginning. Social ventures will not be immune to the blowing winds of economic distress.

If we keep building our nonprofit toolsets on proprietary software and for-profit web services, even if they are free (for now) we are going to be bit by this over and over again. The only way we’re going to get out of this cycle is to channel this energy and resources into open software (including “open” source apps for proprietary web services), open standards, and open networks – things no one can take away.

I love to write blog entries about successful open source efforts – like CiviCRM, or the amazing stuff people are doing in the mobile space. Writing blog entries about for-profit web vendors that make economic decisions that hurt nonprofits because we depend on them too much is just not fun.

The place to find reports on what happend is on the wiki. Also, check out the twitter stream for the #omc09 hashtag.

I was especially interested in the issue of mobile data collection. (I was so interested, I facilitated a session.) And, even more specifically, I’m interested in how to leverage CiviCRM and mobile devices for a range of interesting applications. There are a number of ways to get data from mobile phones into a CRM – and all have advantages and disadvantages, depending on a lot of things.

• Globally, what you can basically depend on is SMS. Smartphones haven’t made it into most of the developing world, nor have 3G networks. So how do you get SMS data into a database system like CiviCRM? You need an SMS gateway, and systems such as RapidSMS to gather data
• Use J2ME to write applications for mobile phones, and send the data via SMS to a central database.
• A tool such as EpiCollect, which is an Android app.
• A slimmed-down, simplified webform to be used on mobile browsers.

One thing that would facilitate this would be a more robust API system in CiviCRM – access to the data via REST or JSON, which would allow CiviCRM to talk with some of the tools out there like Mesh4X.

I learned a ton. Thanks to MobileActive.org and the Open Mobile Consortium for a fabulous event.

• VideoPress — Quick and easy HD video sharing for WordPress
• Welcome to Aviary
• Mozilla Labs – Weave Sync :: Add-ons for Firefox
• How to Set Up an SMS System | MobileActive.org
• Your ShowtimeFu is Strong in Oakland, CA – ShowtimeFu.com
• Spicynodes : Home
• PowerBase
• Guide to CSS support in email clients – Articles & Tips – Campaign Monitor
• Intuit Developer Network Home
• MockFlow – Easy Wireframing for Software and Websites

Security Camera - Photo by Sirius Rust

Beth threw down the gauntlet, and I had to pick it up. I’m sort of surprised I hadn’t written about this before. I think a lot about both of these, not so much for myself, but for organizations that I work with whose work is fairly sensitive.

First off, some definitions – I think that these two terms do get mixed up quite often, and understanding what’s really being meant by them in a technical context is important.

Security, in this context, is the concept that your personal computing resources and data are safe from both prying eyes, as well as hijack by crackers and spammers who will use those resources and data for their nefarious ends. In the case of your computing resources and personal data inside that box you call your laptop, or protecting the whole of your home or office network, security is a matter of using specific tools that prevent unprivileged outsiders from getting in. Wifi passwords, firewalls, password protected fileshares, virus protection software, etc. are the tools of the trade here. Security of your private data that is “in the cloud” is largely at the mercy of the software developers who hold your data. Luckily, most of them take security quite seriously. (That said, your data “in the cloud” can be compromised by lack of security on your network or laptop – someone installs a key logger, for instance, and grabs all of your passwords.)

Privacy, in this context, is that you can control, in a granular sense, what information about you is exposed to whom. Privacy is, as Beth says, primarily a matter of human behavior, but there are very interesting intersections with technology and security. In some instances, services have default privacy settings that are a lot less private than someone might like – and it takes some know-how to figure out how to correct those settings. Privacy is, also, a set of decisions that get made – sometimes in haste, or without much consideration. Your drunken decision to post that picture of you (or a co-worker) dancing in your underwear on a table at a party, the cat is out of the bag, and may never be able to be put back.

Security and privacy in the context of online communities, as Beth points out, are different beasts. The software that drives online communities (such as Drupal, phpBB, and others) have options to allow for varied levels of security. You might need to have a password to see anything. Or you might just need a password to make comments. You might not be able to just register for an account – you might need to go through an admin. These days, most software driving communities have roles you can assign people to, with specific privileges granted per role.

But privacy is made up of policy (the policy of the organization running the community) as well as the behavior of the members – their collective agreement that “what happens in Vegas, stays in Vegas.”

1. painstaking manual entry
2. painstaking export/import processes
3. tools written by the same vendor designed to talk to each other (which meant that they were generally exceedingly expensive)

Although many nonprofit organizations still find themselves in this situation, there are increasing numbers of tools available to help them out of it. And as more and more organizational processes become web-based (whether “in the cloud” or self-hosted), and as more and more nonprofit-focused software includes open APIs (with some unfortunate exceptions,) nonprofit data is looking less and less siloed, and more and more like an ecosystem – many different software parts talking to others.

NTEN is trying to get a bit of a handle on this with the Data Ecosystem Survey.

I’m very much looking forward to the result – looking to see where this new set of tools that can talk freely to each other is working … and where it isn’t – where there is still work to be done. Please take time to fill it out!

“Over the past four years we have been shifting from evaluation for proof or accountability (“Did the program work?”) to evaluation for program improvement (“What did we learn that can help us make the program better?”).”

In some ways, it’s a subtle shift – but as she says, the latter leads to “real time” evaluation – something that happens as one moves through projects, not just at the end.

Nonprofit organizations often have their feet to the fire to evaluate their programs and projects, because funders and contributors often demand proof that their programs work. And there has been an overall movement in the sector in the direction of increased evaluation and learning.  The community I’m a part of, the group of for-profit (”for-little-profit” as is often said – we’re small and lean)  companies that serve the technical needs of nonprofits, evaluation is generally not part of the process of the work we do. But it should be.

I’ve talked about this before. A lot. In a variety of different contexts. To me, evaluation, both internal (”how could we have done this process better?” “”How could we have worked together as a team better?”) as well as externally with the client (”How did we do?” “What could we have done better?” “How could we have communicated better?”) is a critical part of the work we do.

It’s a tough balance. We’re geeks, often busy deep in the command-line, SQL and code. We’re often extremely busy, juggling lots of projects and demands at once. The bottom line, of course, for us, is always a measure of how well we are doing, but I don’t think that’s enough. As our sector as a whole moves further and further along the path of a commitment to evaluation and learning, I think it behooves us to follow.

So, you ask, what are good strategies to start with? I can give you what we try to do. Some of it is well worked out, and some is nascent. All of these we aim to do, but it’s easy to miss the target. Evaluation is a learning process, like anything else, and the most important thing is an intention and commitment to being a learning organization. The rest will eventually follow over time.

1. Spend time at the beginning of each project outlining evaluation steps and process for the project.
2. Spend time at the end of every project asking internally “what worked, and what didn’t work?”
3. Ask clients at the end of the project a set of questions about the process and the result.
4. If its an ongoing engagement, ask periodically (we aim for every 6 months or so) for an evaluation meeting or call with the client.
5. Write a report at the end of each project with lessons learned.
6. When a proposal isn’t accepted, ask a few questions, both internally and externally, and write up a short report with lessons learned.
7. Ask internally how earlier lessons learned, are being applied to current projects.
8. Always be open to learning how to make things better.

• There’s a great new feature available for nonprofits on YouTube: annotations to external sites
• Some great ideas and advice on content strategy.
• The CiviCRM 3.0 beta process is well underway. Yay! Lots of great improvements in there.
• Idealware did a great article on HIPAA compliant software. Most organizations don’t need to think about it, but when you do, this is a great starting place.
• There is an interesting new online mockup/wireframing tool, called MockFlow.

The organization should be able to create several different kinds of events, and determine for each kind of event which detailed information will be taken. Those events can be displayed in a list or calendar format. Users can register for events, and pay using a credit card.

There are many ways to describe this story – it certainly can be a lot more detailed, but what’s clear is the result of this functionality. And, of course, user stories are great for agile development process.

Developers would determine how much this function would cost (based on our knowledge of the tools we use, and the time it takes using those tools to generate this sort of functionality), and clients would know exactly what they are getting from a functionality standpoint. When this functionality is complete, everyone is happy. The developers get reasonable compensation for a job well done, and the clients get the mission-based functionality they asked for.

And it would avoid a situation which I have become recently far too familiar with – vendors who underbid projects, and then feel the need to resort not to the intent of the contract, but the letter. Everyone knows it is utterly impossible to specify every detail in the letter of a contract – sometimes letter of the contract, unfortunately, details things like fields and queries, not functionality. The letter of a contract will be, almost by definition unless based on functionality, an inadequate representation of the final result needed. In this case, no one really wins. The clients either don’t get the functionality they expected, or they pay extra for it, and they leave the project with a bad taste in their mouth about the vendors, which will only come around to hurt the vendors later.

There has been, of course, a lot said about the fact that although women make up 20% of the tech field, they only are approximately 1.5% of open source communities. There have been long standing groups that have tried to address this, and new efforts as well. Some open source communities are more diverse than others. In her keynote, Kirrily talks about two open source projects, Archive of Our Own and Dreamwidth that have a majority of women involved, which is rather unusual.

A short twitter conversation I had with a colleague brought up the issue of whether or not this is just an exercise – will this actually lead to any lasting change? That’s a good question.

Kirrily has a set of really good guidelines for open source communities:

• Recruit diversity
• Say it, mean it
• Tools (Tools are easy)
• Transparency
• Don’t Stare
• Value all contributions
• Call people on their crap
• Pay Attention

As a long time open source user and advocate, even though I am someone who rarely finds people like me in open source projects (i.e other women of color), I’ve always seen the open source movement a potential avenue for the greater involvement of people other than white, straight, young men, because theoretically (this is the important part) one’s involvement in a community is pure meritocracy. But so many open source communities have so far to go when it comes to being welcoming. I’m reminded of sitting in Drupalcon in DC and hearing Dries talk about the “beard length” of the developers. And of course there was the huge brou-ha-ha around a presentation at a recent Ruby conference.

And, of course, there are other factors as well. There are far too few places like The Community Software Lab of Lowell, MA, who’s mission is:

We write, administer and maintain open source software to serve the underserved.
We use and improve the skills of people with underused skills
We work to make hacker sub culture values (transparency, meritocracy and generosity) the values of the entire culture and bring about the post scarcity society.
We work toward our mission by trying to achieve our short term goals transparently and generously while accumulating only necessary wealth.

So what will it take? Will this effort in the python community pan out? I think it’s a great start. I think the first step is definitely a focus on community environment. Is it friendly? Is it welcoming? Is it easy for new developers to start, and get deeper in? Are there good mentoring models? All of that makes a huge difference. And having a statement doesn’t at all guarantee anything, but it provides something people can point to and say “this is our goal.” Better than nothing, and a lot better than many open source communities are doing.