Countless nonprofits flocked to Ning to create social networks. Since I’m not a social media guru, I’ve generally kept my opinions about this to myself. But now that Ning isn’t free anymore, I’m going to carp some.
I think over the course of lo this last few years, I have blogged or tweeted about this very phenomenon what feels like countless times. Nonprofits find services for free. They start depending on them. The free services disappear, for business reasons. The nonprofit community gets up in arms. Lather, rinse, repeat.
There is nothing wrong with software or services that don’t cost anything. Nothing at all. But if you are going to bet the farm, make sure you know what the risks are. Using free services is fine, but know why they are free. Are they free because the company behind them is an ad revenue machine and uber profitable (Google)? Is it free because it’s open source (Drupal, Elgg, Word Press)? Is it free because it is a profitable company that has a clear and well defined donation program (Salesforce.com)? Or is it free because it is a start up in search for a business model (Ning)?
There is an effort afloat (and a petition) to get Ning to make nonprofit and educational accounts free. I’m not holding my breath. They eliminated 40% of their staff. They are feeling pinched, and need to stop their burn rate. I don’t know how charitable this will make them feel. And even if they do, there is no guarantee that Ning will even survive.
Anyway, if you’re looking for a great social network management system that won’t get pulled out from under you, try Elgg. It’s open source, and out of the box, it does just about everything Ning does, without the need for the deep setup required to set up Drupal like Ning. It has an active developer community, and is growing.
Or, if you look for another free service, make sure you understand the risks, and be prepared for possible disaster if it’s a startup in search of a business model.
Tagged as:
nptech,
opensource,
socialmedia
Lobo’s comment on my post yesterday prompted me to complete this blog entry that I’ve been ruminating on for a while. I wrote a blog entry a while back on the state of Drupal/Salesforce integration. What I didn’t say is that a number of shops that have done Drupal/SF integration for production sites chose not to use the contributed modules – they built (or are building) their own custom Salesforce/Drupal integration modules.
A few months ago, in preparation for a couple of projects, and a big push into this area for our company, I was faced with a strategic choice – go it alone, and build our own integration module for client projects, or plunge into using and working with the contributed salesforce modules. Truth is, it wasn’t really a choice for me – I’ve got using and contributing back to open source projects in my DNA somehow. Although we certainly could have chosen, like others, to go our own way, we have committed ourselves to using, and contributing to the modules on drupal.org.
What we lose:
- Complete control over development process and direction
- Not having to fix other people’s bugs in order for stuff to work
What we gain:
- Not having to reinvent a number of wheels
- An easier upgrade path
- Build on the work of others
- Collaborate and learn
The work done so far on the modules is really solid – and it’s getting better. There is a great new maintainer, and increasing activity and contributions. There are also a number of other module integrations (like Ubercart, Webform, and FeedAPI) that are moving forward. Integrations with Views and Actions are also moving being considered (it’s instructive to look at the issues queue). This is stuff that would be hard to match, and makes building integrations for different kinds of sites easier.
So beyond just my own personal preference, I think that there is much benefit, both for our clients, and for us as a company, in hitching our wagon to theses contributed modules instead of going it alone.
Tagged as:
CMS,
drupal,
opensource,
salesforce
As most of you know, I’m a very long time veteran of web application building. I’ve been involved in web application development basically since they started – when a cgi-bin folder with some perl scripts to process simple forms was the norm. Until just a few years ago, there was very little sophistication about the user experience in web applications – what mattered most was functionality. and to make sure there weren’t too many errors when users did unexpected things.
I’ve considered myself pretty successful at both helping clients navigate the tough waters of web development projects, as well as accomplishing web projects for them. Recently, though, I had two projects that ended up, for wont of a better term, clusterfracks. And I’ve spent a lot of time lately trying to figure out what lessons I need to learn from those projects – what can I take away from them so I don’t make the same mistakes again. They were both custom web applications, both projects that I was a strategic, rather than engineering, partner on. Both projects were attempting to accomplish pretty sophisticated database functionality (such as case management). Functionality I knew how to get done, because I’d accomplished it before – so I had a very good feeling for what kind of code it would take to accomplish the task (and, ergo cost and time.) But what I hadn’t taken into consideration is how slick, AJAXy, easy to navigate, and easy to understand user interfaces people have gotten used to in the last few years. And, frankly, have come to expect. And how unwilling people are to sacrifice that for raw functionality.
I did a lot of self-examination: where did I go wrong? What could I have done differently? Was it the client? The developers? Me? I realized a fairly simple truth. It was all three. In reality, I should have looked at the budgets of those projects, and looked at the clients straight in the eye and said, “double, or triple the budget at least, or don’t do the project.” And walked away if they insisted. The vendors should have bid triple what they did, and had more user interface expertise on board. The clients should not have expected to get slick 2009 functionality for a mid 5-figure budget.
The easier a user interface is to use, the more money and time it took to create. It’s that simple. What most nonprofit decision makers don’t completely realize is that the interfaces they work in every day when they shop, or tweet and facebook, or use other online tools, are the product of millions and millions of dollars of venture capital, or, in some cases, hundreds of thousands of person hours of work in open source projects (or some combination of both.) Ground-up custom applications, even when written in great frameworks like Ruby on Rails or CakePHP, which save all sorts of development time, just are not going to have the user experience people are getting more and more used to without very serious investment of time and expertise. In addition, most small development shops don’t have the user interface expertise on hand to accomplish that task, even with a hefty budget.
So the lessons:
1) If you are embarking on a custom development project (such as a case management, for example) exhaust every possible option of using and customizing/modifying existing tools (Salesforce, CiviCRM, SugarCRM, other open source tools) before you begin to consider custom development from scratch.
2) If you have a budget of less than $100,000, go back, and stay, at step 1. I know this is high, but I’m serious. Obviously, simpler projects won’t need a budget of this sort. But simpler projects generally don’t need custom databases.
3) If you’ve got the cash to spend, and have exhausted all other options, when choosing a vendor, make sure the vendor you choose has UE expertise on hand. Look at other custom database work they’ve done. Dig in. Make sure it has the ease of user experience that you are expecting.
4) Remember the mantra: the easier it is to use, the more expensive it is to build.
Tagged as:
Consulting,
Development,
opensource,
user experience
I’ve been doing a bit of playing around with Drupal 7 in my copious spare time (not a whole lot of that!) I’ve also been keeping track, a bit of how the development process is going, and what things will look like. One thing to say – it feels like as big an improvement as Drupal 6 was to Drupal 5.
Of course, mostly, Drupal is only as good as it’s contributed modules (that’s a bit more of a stretch, now, because many of the key contributed modules, like CCK, are now in core Drupal.) So when folks like us, who build sites that depend on Drupal 7 can start using it is a bit up in the air, although there is a movement to get many modules ready for Drupal 7 at it’s release. But some may well not make it. We’re guessing that we’ll start building production sites in Drupal 7 starting in late summer, early fall, depending on requirements.
A note: the standard process for deprecation of old Drupal versions is that when a new version of core comes out, the one two versions back stops being officially supported. So Drupal 5 will no longer get security updates and the like. Already, many module developers have stopped supporting versions of their modules that work on Drupal 5. (The salesforce module maintainers recently made that decision, as have others.) So certainly a site running Drupal 5 won’t stop working, but it will become vulnerable without security updates to core or modules, and it will get increasingly difficult to maintain and add features to. So it might be a good idea to budget the time and money to upgrade as soon as possible if you are on Drupal 5. If you are on Drupal 6, you’ve got a while yet, but Drupal 7 certainly has some great advantages, particularly in user experience, to look at.
Tagged as:
CMS,
drupal,
opensource
I’m warning you – this is snarky.
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.
Tagged as:
nptech,
opensource,
openstandards,
socialnetworks
Yesterday, I spent the day in Manhattan, at the UNICEF building, with a bunch of folks passionate about the technology in mobile phones, and the ways to use that technology for good. I’ve been a very long time cell phone user (had one since 1998), but I haven’t been involved in implementing a mobile system for an organization, so I had a lot to learn.
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.
Tagged as:
civicrm,
CRM,
Mobile,
nptech,
opensource
Any consulting shop that does significant amounts of implementation and development (as we do) needs a project management and ticketing tool. Basecamp seems to be a standard that many people have reached for. We were using Intervals for a while, which is really a fabulous tool if you do a lot of hourly consulting. We also have been using Google spreadsheets for some elements of project management.
All tools have their strengths and weaknesses. And, in addition, the best tool does nothing without good human project management skills using it. As a shop that practices Agile development (we use an adaptation of scrum methodology that seems to work for a shop that does multiple projects with small teams,) finding a good tool that facilitates instead of hobbles Agile was critical for us.
We found, and have chosen to use Redmine for our project management/ticketing system. You can think of it as a multi-project version of Trac, which is a fabulous ticketing/wiki system that we were initially going to go with. Redmine has the elements of Trac that we liked, with the added ability to track multiple projects. Like Basecamp, Redmine has document storage and messaging systems. It doesn’t have milestones per se, but it does allow you to see tasks in calendar and Gantt views, which is very helpful. Unlike Basecamp, you can add custom fields to tickets, users and other features. Having spent many hours in Basecamp, I actually like Redmine much better. It does even do time tracking, which we won’t use, but is nice to know is there. And the wiki is nice. Basecamp’s Writeboards seem so much more like an add on than integrated.
It’s a Ruby on Rails application, and that was actually kind of fun to finally get to install and play with RoR a tiny bit. And it’s great that it’s free and open source. Although that wasn’t an absolute requirement for us, it is most definitely a plus, given so much of our work is implementing open source web tools. And it’s nice to save a few bucks per month.
Tagged as:
nptech,
opensource,
tools,
web
As you can tell, I haven’t had much time to blog lately. Here are some great links I’ve come across that I thought were worth sharing:
Tagged as:
nptech,
opensource
I got to spend one day at CiviCRM developer camp this week. Unfortunately, it came after 4 long days of conferencing, after many exhausting days of work, so I wasn’t at my peak. But I learned a lot, and thought I’d share some of what I took away from that day.
First, the core team shared some of the new stuff coming out in version 2.3, and it is awe-some. One of the major reasons CiviCRM gets dinged as a CRM/DMS is that it doesn’t have reports. Well, that problem is about to go away with the release of CiviReport in 2.3. There will be a number of canned reports, and some really nice ways to create reports. Plus charts! Yay! There were some pie charts, and regular bar charts. I don’t have the new svn trunk of CiviCRM installed, otherwise, I’d show some screenshots, but it looked really nice. (I’ll be installing CiviCRM from svn in the next week, and I’ll probably blog more as 2.3 develops.)
There are some really nice usability improvements coming up in 2.3 as well – to make the basic contact pages much easier to navigate. And there is a new menu system, which will make things a lot easier. And, for Drupal users, some sweet Views 2 and CCK integration.
CiviEvent is getting waiting lists, registration approval, and user-modifiable registrations, and some other improvements.
The Alpha of 2.3 should be out by July.
I also learned about CiviCase, which is actually present in 2.2. I saw the example of it used for the Physician Health Program in Canada. It’s quite good, and there are some useful docs to see it at work on the CiviCRM wiki. I’d love to find an organization, such as a small human services organization, in need of case management software, that could use CiviCase – it would be a great, and relatively inexpensive alternative to current offerings out there. And more organizations using CiviCRM for case management would help CiviCase get even better.
I also dug into some of the internals and code of CiviCRM, and feel better equipped to start contributing more than ideas and feedback to the project.
Tagged as:
civicrm,
CRM,
nptech,
opensource
I love Penguin Day. One of my favorite days of the year. Always comes right around NTC. This year, it’s before NTC, on Saturday, April 25. It’s a day dedicated to conversation and community around nonprofits and open source software. There’s some great stuff on the Agenda, like:
- Introduction to Free and Open Source Software
- Fundraising with all free software
- Free And Open Source Online Advocacy: Tools And Best Practices
- Making sense of Free and Open Source Content Management Systems
- Introduction to Blogging with Wordpress
- Intro and Advanced sessions on Joomla! and Drupal
- CiviCRM vs Salesforce.com: What Are the Differences?
- Mobile Volunteering: The ExtraOrdinaries Project
- Creative Commons And Open Content
- And many more…
You can register at Penguinday.org. Thanks to the generosity of Google, we’re delighted to grant fee waivers to anyone who needs one!
I look forward to seeing folks there.
Tagged as:
nptech,
ntc09,
opensource,
penguinday09