Home  |   Reports and Articles  |   Online Seminars  |   Donate  |   Blog  |   About Us

Monday, February 15, 2010

Supported Open Source

by Johanna Bates

I’m at an interesting intersection in my career path. I just concluded eight years at a small, statewide health care reform nonprofit in Massachusetts called Community Partners. I was Technology & Strategy Director there. Like so many orgs around us, we went under a month ago due to the bad economy. Though I am sad to lose my wonderful co-workers, it was coming for a long time, so I was somewhat prepared. A long time ago, other organizations and foundations started asking me lots of technology questions. This has naturally parlayed into consulting.

At this juncture where I have a sense of what it's like to work in a small org and am also looking at and helping larger orgs and foundations to make decisions about tech and use it in smart ways, I’m thinking a lot about something I call "supported open source."

"How do I choose a CMS?" is one of the most frequent questions I get. "Should I go with a closed but well-supported system or should I venture out into the Badlands of Open Source?" There is another way! That is supported open source.

The perception is often that if you choose open source—even if you hire additional expertise to initially build your site—you have to have skills in-house to keep it going after launch. I think the perception that you're on your own with open source is one of the barriers to its adoption for many businesses and nonprofits. But there are companies and consultants that will stick around, long after your site is launched, to give you the help and support you need. And there are different ways of doing this based on your org's budget.

At Community Partners, we ran things on a shoestring. I build web sites, but I don't write custom PHP code. When we wanted to use a profile module to collect contact information from users on our Drupal site and sync it with our Access mailing list database (yes, I know... Old Skool...), I found the module. It didn't work right. This functionality was a priority for us, though. Luckily, we maintained a contractual relationship with a Drupal consultant who would help us out with our site when our budget allowed. We only paid him to help us when something was broken, or when we wanted a new feature we couldn't implement ourselves and we had the funds to do it.

Having someone you can pay to give you support only when you need it is clearly cheapest way to go. If you're rolling in money, however, having a company on-call 24-7 to support you with anything you need is the other end of the spectrum. And everything in between exists. I want to disclose here that at present, I have a paid relationship with a consulting firm called OpenIssue LLC, which offers a spectrum of services for open source CMS platforms. I am working with them because I am becoming increasingly convinced that supported open source is has some serious advantages for our sector.

I am dogmatic about not being dogmatic, and the needs and mission of an org should always determine what technology they choose, not the other way around. You're never married to a piece of software and you should change platforms if and whenever it serves you. But particularly during this time of economic uncertainty, there is something comforting to me about software that's being developed by a worldwide brain trust. Open source software can't be yanked out from under you if funds (temporarily) disappear, or if a contract expires, because we all own it.

Though this community code base can be messy, open source development specialists know how to clean it up for you. So you get that worldwide scope of innovation, plus the focused attention on your org's particular needs. For orgs that want to stay innovative but don't always have cash flow, this can be a great solution. Ongoing support can be stopped and re-started as needed when there are budget troubles.

I know of a few companies out there that explicitly offer ongoing support for open source platforms. My fave among these is PICnet. Non-Profit Soapbox is designed to be an affordable, fully hosted, software-as-a-service (SaaS) way for nonprofits to build sites quickly and easily in the Joomla! CMS. PICnet has been around for a long time, and honestly I don't know why more companies aren't offering open source SaaS for nonprofits. Seems like a great idea to me. Here are a couple more companies that offer ongoing support:

I predict more of these companies will emerge in the coming year, and I think it will be a great leap forward for our sector. Do you know of a company or a consultant that offers ongoing support for open source software platforms? If so, I'd love to know about them. Please add them in the comments.

Labels: , , , , , , , , ,

Monday, October 05, 2009

Drupal 101

by Peter Campbell

I've been doing a lot of work with the open source content management system Drupal lately, and thought I'd share some thoughts on how to get a new site up and running. Drupal, you might recall, got high ratings in Idealware's March '09 report comparing open source content management systems. Despite it's popularity, there are some detractors who make good points, but I find Drupal to be flexible, powerful and customizable enough to meet a lot of my web development needs.

While you can put together a very sophisticated online community and/or website with it, you can also use it for pretty simple things. For example, the nptech aggregator at nptech,info uses Drupal's excellent RSS aggregation functions extensively, and not much else. No blog, no forums. But, having installed and tried standalone RSS aggregators like Gregarius, it became clear that Drupal was just as good an aggregator and, if desired, much, much more. Similarly, when co-workers were looking for a site to share documents with optional commenting (to replace an FTP repository), Drupal was a good choice to support a simple task without locking out growth possibilities.

Installation

Installing Drupal can be a three click process or a unix command line nightmare, depending on your circumstances. These days, there are simple options. If you are using a web host, check to see if your site management console is the popular CPanel, and, if so, if it includes the Fantastico utility. Fantastico offers automated installs for many popular open source CMSes, blogs and utilities.

Absent Fantastico, your host might have something similar, or you can download the Drupal source and follow the instructions. Required skills include the ability to modify text files, change file and folder permissions, and create a MySQL database. At a minimum, FTP access to your server, or a good, web-based file manager, will be required.

If you're installing on your own server, things to be aware of are that you'll need to have PHP, MySQL and a decent web server, such as Apache installed (these are generally installed by default on Linux, but not on Windows). If you use Linux, consumer-focused Linux variants like Ubuntu and Fedora will have current versions of these applications, properly configured. More robust Linux distributions, like Redhat Enterprise, sometimes suffer from their cautious approach by including software versions that are obsolete. I'm a big fan of Centos, the free version of Red Hat Enterprise, but I'm frustrated that it comes with an older, insecure version of PHP and only very annoying ways to remedy that.

Up and Running

Once installed, Drupal advises you to configure and customize your web site. There are some key decisions to be made, and the success of the configuration process will be better assured if you have a solid idea as to what your web site is going to be used for. With that clearly defined, you can configure the functionality, metadata, site structure, and look and feel of your web site.

  1. Install and enable Modules. Which of the core modules (the ones included in the Drupal pacckage) need to be enabled, and what additional modules are required in order to build your site? This is the first place I go.


  2. Define the site Taxonomy. While you can build a site without a taxonomy, you should only do so for a simple site. A well structured taxonomy helps you make your site navigable; enhances searching; and provides a great tool for pyramid-style content management, with broad topics on one level and the ability to refine and dig deeper intuitively built into the site.


  3. Structure your site with Blocks. You can define blocks, assign them to regions on a page (such as the sidebars or header) and restrict them to certain pages. On the theory that a good web site navigates the user through the site intelligently, based on what they click, the ability to dynamically highlight different content on different pages is one of Drupal's real strengths.


  4. Theme your web site. Don't settle for the default themes -- there are hundreds (or thousands) to choose from. Go to Drupal Theme Garden and find one that meets your needs, then tweak it. You can do a lot with a good theme and the built in thee design tools, or, if you're a web developer, you can modify your themes PHP and CSS to create something completely unique. Just be sure that you followed the installation suggestions as to where to store themes and modules so that they won't get overwritten by an upgrade.


This just brushes the surface, so I'll do some deeper dives into Drupal configuration over the next few weeks.

Labels: , , , ,

Wednesday, October 08, 2008

Build vs. Buy

by Michelle Murrain

I keep being surprised by how frequently I hear clients tell me that a vendor has suggested they "build them a CMS," or by proposals from vendors that include custom building a CMS. I hear people suggesting building their own social networking website. I even occasionally still hear tell of organizations who want custom CRMs.

The web software landscape has changed dramatically over the years. Five years ago, it was full of custom built systems of all sorts - and the "build vs. buy" decision was, I think, more difficult, because the available software to buy was fairly cruddy. (And, for the purposes of this post, I'm using "buy" exceedingly loosely - including purchasing proprietary software, installing open source, or using SaaS.)

But the landscape is different now, and I think that, in some senses, the "build vs. buy" decision is much more straightforward. First, the software available, whether it be open source, SaaS, or proprietary, is much better all round. There are new types of software being developed all the time (like, for instance, the new crop of "Social Network Management Systems" both open source and SaaS, like Ning.)

In addition, the increasing openness of software, whether it be open source, or open platforms like Salesforce.com, means that customizing software to your needs, or integrating different pieces is much more straightforward, meaning it's a lot easier to create exactly what you need by integration or customization, rather than building from scratch.

This is not to say that there is no role for custom built applications. I'm in the process of working with two organizations to create just that. But they are both for quite highly specialized functions. And I've also been involved in projects to create interesting and customized web functionality - but those are being done with adding custom modules to an open source CMS.

From my perspective, exhaust all of the "buy" options: open source/proprietary/SaaS out-of-the-box, customized open source/SaaS, or integration of already existing components, or building modules on top of open source tools, before you take on building something new from the ground up. You'll save money and time, as well as be able to take advantage of an upgrade path as web software changes and improves, meaning you won't have to build whole systems again.

Labels: , , ,

Tuesday, September 16, 2008

website software dilemmas

by steve backman

Is it just me, or is everyone redoing their web site all of a sudden? This summer, we had a rash of requests to talk about web site options. I am writing this after a neighbor who has never previously talked tech with me literally stopped me in the street about her organization’s site.

Here’s the problem. A redesign today isn’t that different than it was five years ago. The process is about the same. The time commitment, designer hours, and cost is about the same. Many people still think that’s what they need. Liven up the design, get new content up, and show you have a pulse.

OK, everyone today also wants easier changes to their site. Nonprofits held captive to board members or the founder’s niece for every little change is so 1990s. If you redo your site with Adobe Dreamweaver, at least get set up for easy page maintenance with companion product Contribute. Inexpensive (from TechSoup), easy to learn, and no web designer needed for adding content and keeping up to date.

But these days, it’s really a makeover plus. Once you get talking, most folks want more.

You soon cross a threshold where the choice to just update the site conflicts with the things you really want to do, if not now, then soon. Better cataloging of material; “members only” special content; commenting, tags, ratings, news feeds, tell-a-friend, printer friendly pages, and all the rest to make your site easy to use.

And it’s not just click- to-donate anymore. It is event registration; Analytics; blogging; internal planning, discussion and organizing; community calendar; newsletter signup and on.

If you are not doing a lot interactive yet, you can definitely tackle a couple of new things as add-on services for now. There’s lots of great, free or inexpensive pay-as-you go a la carte services for blogging, events, calendars and more. A la carte often means different visual looks and no shared contact information.

Much better to move to a content management system, such as the big Open Source ones frequently mentioned here--Drupal (our favorite), Joomla and sometimes Plone, as well as the pricey commercial ones like Kintera and Convio, and the many lesser commercial ones discussed on idealware and techsoup. Yet the leap to a full installation of one of the content management/web development systems, including a strong visual design “theme,” and all your content, will cost substantially costly than just updating the site in Dreamweaver.

It is truly worth it because you will now be on a modern platform that can and will continue to evolve as your needs evolve. What’s tough and unexpected for many small organizations is justifying the additional cost to get there, if you haven’t planned on it. These are hard choices for folks with small budgets.

When I have these conversations and it looks like it’s going to go in the direction of a traditional Dreamweaver facelift, I find myself musing on Rick’s words to Ilsa in the final scene in Casablanca. I think to myself, if your new web site takes flight in 2008 or 09, and it’s not on a CMS, then “you’ll regret it, maybe not today, maybe not tomorrow, but soon, and for the rest of your life.” Well, maybe not the rest of your life, but Bogart’s Rick is a lot tougher than me.

It’s hard telling people they should wait. There’s certainly lots to do to prepare for a full blown web upgrade. Focus on your email newsletter so you know your constituents; see how hard or easy its going to be to get new stories on your home page regularly; start a linked blog; study your Analytics; focus on evaluating your contact management.

And there are ways to experiment. Google Sites, Wordpress, wikis and Ning all come up for us as alternative to full blown CMS-driven systems. These are easy, lively, even fun. And they can be done with not just less budget, but less planning time from organizations than building a full Drupal or Joomla site. They may suffice or they could be experimental before committing to bigger project. There’s no universal truth on this matter, and it’s a great time to move forward.

Labels: , , ,

The Idealware Blog

Thoughts and resources to help nonprofits choose software, from:

Subscribe to This Blog


Recent Posts


Archives