p.1

Nonprofit 911 – April 7, 2009

What Should a Website Cost?

with Allen “Gunner” Gunn

Sponsored by Network for Good

The MP3 audio transcript can be found at

www.fundraising123.org or www.Nonprofit911.org

Rebecca Higman: I am thrilled to introduce our speaker, Allen Gunn, also know as Gunner. Gunner is the executive director of Aspiration, which is a nonprofit that works to see better software tools created to support other nonprofits working towards a better world.

He has more than 20 years of software development, senior management, and capacity building expertise, and has spent the last 15 years exploring how technology can most effectively empower and support social justice causes.

So drawing on engineering, teaching, and volunteer experiences, Gunner is a strategist and facilitator in both the nonprofit and corporate sectors, and he is passionate about helping nonprofits and NGOs make better use of technology.

He currently sits on the boards of the Ruckus Society, Global Exchange, and Idealware, and he is a firm believer in melding hard work with serious fun, which we can relate to around here. So without further ado, here is Gunner.

Allen Gunn (Gunner): Great. Thank you so much, Rebecca. It is a pleasure to be with you all today. I think I will start with just a quick humanist reflection at how surreal it is to have the privilege of talking to hundreds of faceless ears on this very high-tech conference call infrastructure. So as we kick things off, I would encourage everyone to have a smile and a deep breath and reflect musingly on how technology connects our social justice causes.

That said, if you are playing along at home with your SlideWare, I am looking at the slides also that are used for this call, and I just want to talk about some of the things I'm hoping to get done in the next 45 or 50 minutes.

First and foremost, this is a gossip session, and I am going to share some hearsay. It's all anecdotal; there are no universal norms, but I am going to talk to you about what we see for rates and costs of sites and unpack that a little bit and talk about what we think you might want to be thinking are appropriate price boundaries as you do your work in nonprofit web design or redesign. From there, I will segue into some sweeping generalizations and passionate arm-waving.

Having done this for as long as I have, I just have some generalizations that I think are worth sharing about patterns of mistakes that organizations make, and better yet, steps

p.2

and processes that organizations can take to insulate themselves against cost overruns and unhappy budgetary realities.

So I will talk about those project suggestions and some guidelines for dealing with what I lovingly call implementors, which are individuals or a group of people that can help you put together your website. And last but not least, it would not be an Aspiration call if I did not do a shameless shout-out to our ecosystem.

I just want to tell you the people that do website implementation that we work with, it's a highly biased list of people that we deeply love, and I'll say a little bit more about that when we get there, but just folks that I encourage you to consider as you are exploring this world because they are honest and they are sweet and they are fun to hang out with.

That said, I can't see any of your eyes, so I am going to move on down to the very next slide.

Briefly more about Aspiration. We exist to see better software created for the nonprofit sector and we do that by really trying to work with all of the stakeholders in the production process. So we work with the vendors and the software developers, we work with the integrators and consultants that specify, configured, install and otherwise train nonprofits in the use of these software packages. And most importantly, we work with the nonprofit organizations and with the individual users. So really here what's frustrating them, what they are not getting and how these tools could better serve them in their work as opposed to dictating them the way that they do their work.

How do we do that? We work with the actual software products and do strategic consulting. We offer a number of community strategy and product management services to help people figure out how to target their products and how to frame them appropriately for the nonprofit sector.

On the flip side, on the consumer or demand side, we work with organizations on sustainable technology processes. If you are going to redo your website, if you are, heaven forbid, going to write a piece of software, how do you do that in a sustainable way?

We love to train vendor organizations in effective use of the tools. And by effective, we really focus on organizational processes that are inclusive and transparent so that you don't run into the high priest/high priestess pathology within small organizations.

We also track the universe of available nonprofit software at socialsourcecommons.org. If you are curious to see about 3, 000 tools nicely tagged and categorized and cross-linked, socialsourcecommons.org is I dare say the largest inventory of nonprofit relevant software out there.

And last but not least, our passion and our strength in the brand is that we run technology events for the nonprofit sector where we actually invite developers to stop talking so geeky and listen to users, listen to the people that are using your stuff and really let their questions and their challenges inform how you prioritize development working forward.

p.3

You can find out more about us at our www.aspirationtech.org website and that's the end of this self-indulgent "about us" message.

Moving on to the good stuff. Hey, assertion number one, "Websites are not pizzas." "Hmm...not pizzas you say, Gunner, what meanest thou?" Many people that we've worked with have this mentality that a website is something you order, it gets delivered and in the same way with the pizza it's there, you are happy with it and then you don't have to think about it again.

The websites should just be something that shows up and works for perpetuity at all time. And so we encourage people not to think about websites as a pizza delivery paradigm, but instead, moving to the next slide. Websites are more like vegetable gardens.

Now what I mean by that is they take a little bit of planning. You need to know what you are trying to get out of that endeavor and as you are working with that project, you need to give it ongoing care and attention. And in the same way the vegetable gardens need water and weeding and fertilizing and pest control, websites need analogous care in regard to fresh content, all kinds of attention to the contributions that are not appropriate, and just a general sense of attentiveness.

And so I mention this as a framing part, because I think if you are going to keep your costs down on your website, the first thing you should model it as is a more garden-like endeavor and not a phone out for delivery and expect it to magically show up on budget and on cost.

I would opine, moving to the next slide, that that does -- to use a technical term -- kind of "suck," but we will talk about some ways that you can try to manage complexity of websites' processes and keep the costs in the pot with the lid on.

So, what should a website cost? I'm going to consider what I'd call a typical entry level nonprofit website and this is where we focus on the grassroots end of the market. So this is for a small nonprofit, a 5%, a 10%, a 20% non-profit as opposed to a United Way or a Red Cross who have their internal IT departments and fantastic technology resources at their disposal.

For our typical grassroots nonprofit site, we presume that a free or open source software -- that is the cost there -- a free or open source software content management system is being used so that licensing costs are zero and the costs involved are in labor and other consulting services.

We assume that this website will be updatable by organization staff so that you aren't having to call up an external party to make changes to the content on the site. We are going to assume that it's based on one or two page templates. And those are the frames or the containers into which content goes, it includes the banner, the top of the page, the footer at the bottom of the page and what's called the global navigation, the link that show up where you are.

p.4

Simple sites have a single template that works across the site, more sophisticated sites might have a second template for second level pages. We are modeling for a site that's 25 to 50 pages when it launches and the only interactive features it has, email signup, so that visitors can give you their email address and see what you are doing moving forward because you email them and tell them. And a site that takes online donations.

We lovingly refer to such a configuration as brochure ware with a growth path. And that is to say because it is an industry standard content management system -- oops there is a transmission in my acronym -- because it is an open source content management system, these platforms are extensible platforms like Drupal and Joomla! And WordPress and Plone are extensible. And so you are able over time to integrate more interactivity and more functionality, but for the time being this snapshot is what I would like to share some costing basic about.

So first, let's talk about cost components. If you are doing a larger web project, you need system architecture work done. In the scenarios I'm discussing, we are assuming that is not immediate, no one needs to come in and create a big database model, no one needs to come in and talk about the big pieces of software that need to be integrated. This is basically a straight ahead website that stands on it own.

Creative design -- and I cannot emphasize this enough -- this is the largest cost variable in low-end websites. We've seen people that have paid nothing for design and gotten phenomenal work done by volunteers, interns and other well-intentioned contributors. We have seen organizations that have spent tens of thousands of dollars trying to get that anthem color balance just right with a new logo.

And so as you model the costing of your website, design investment is one of the things to make a decision early on about what you are able to allocate and really focus on sticking to that, because design costs are one of the components that tend to creep on the most as you do the tweaking and the iterative improvement.

The third cost component is the actual implementation and deployment of the website. That is the meat and potatoes, or tofu and seitan, of the actual web cost component rate. Content placement or content migration, sometimes you can have your implementer do that, other times and we recommend, if possible, have your staff or the people that will maintain the website long-term, do that work so that they are able to gain expertise in the functionality of the site.

And the final cost component, training and support. But sadly, very few people budget for and we encourage you as you cost out your website, to budget for training and support cost when the website is being created and once it goes live.

Moving to the next slide, here is the first bunch of gossip. I doubt these numbers are very surprising to people, but I thought I'd just say a few things about them. Where we live in the Bay Area in San Francisco and that's where we do most of our website consulting and support work.

p.5

We see a range of $75 to a $150 an hour with the people we work with. You have no problem in finding people that would love to charge you $200 or $300 an hour to sit in your meetings and to make their website special. Our personal belief is you can get anything excellent that you need done for $150 an hour or less.

I realize those are fighting words, but I personally have a real bias against anybody who is charging right now more than $150 hour because I personally think that's money taken away from mission and we encourage organizations to seek out market opportunity in that $75 to $150 range.

Aspiration personally, all of the consultants that we work with, as Rails developers, Drupal consultants and people doing any number of content and strategy work for us, we pay in the range $85 to $100 now, that's what our tolerance range is and we are extremely transparent. We tell all of our contractors what we say the other contractors just because we think that's a fair market thing to do.

$125 to $150 is what we expect to pay if we are asking for custom development. If we are asking for something special extending a Drupal or extending a Joomla!, the rate for that tends to be $125 to $150 an hour. And as I said above $150, you are often paying for style or somebody's reputation and that's not in anyway to sour those people, they are all fantastic folks, but we just believe there is phenomenal availability of lower-cost excellence in the sector.

Three things to say in parallel with those numbers. Hourly rate doesn't mean much until you know how many hours it is going to take. And so we always lean in the direction of paying the people that can do it in a lesser number of hours. If they are going to charge us more per hour, that's OK because the product of those two numbers tends to come out rather small.

How do we know what total hours are required for the job? We get estimates from the people that we work with and then we check references, check references and check references. So, we really talk about whether our estimates track to outcomes.

And I can't emphasize enough that fear of asking others for input is one of the places where people end up spending too much money. It is such a good idea as you do your web project to make sure you are talking to peer organizations, talking to people that have been down the path before you and getting their input.

Final point, it's a slightly cynical one: beware the very low hourly rate. If someone comes and says, I can do this for $25 an hour, they may be wonderful, they may be a really brilliant individual who can do that work at an excellent quality level and deliver for the hourly rate recording. Our experience tends to be people offering that kind of a rate haven't worked in the sector that long and don't understand longer term sustainability requirements.

So while we are not telling you to overpay, we are also telling you to be somewhat suspicious of people that are charging at the low end and again check references and make sure that they delivered other projects in a timely fashion at those rates. If they

p.6

have, work with them and don't tell anyone about them until you are all done with them - wink, wink. But otherwise think carefully about whether or not that is the sweet spot in your budget model.

And again, I am rambling on, apologies if my coffee baud rate is hurting your ears.

What should a website cost? As of today, 4/7/09, we pooled all of the vendors that we work with. I have called up all the peeps that we have sent work out to, because Aspirations does not ourselves implement websites. And I said, "Hey, what should a website cost?"

And I ran that scenario by them that I have just described to you, the typical grassroots nonprofit site, the 25 to 50 pages. The answers that we got range from $500 to $10,000. $500 will be for an ultra-simple WordPress site with an off-the-shelf prefabricated template and all the work involved was just a little bit of WordPress configuration and setup and some initial content entry.

The very consistent answer that we got from all of the vendors we talked to is that a typical and you will note that I put that in double quotes, which is my slide way of doing air quotes, a typical, because there is no such thing, Drupal or Joomla! Site runs $2,000 to $5,000 for the grassroots nonprofit implementers that we work with and for most of the grassroots nonprofits that we have gone through this process with.

The variable as mentioned earlier that can drive that number higher is design. If you are doing a rebranding, if you are extremely picky about the look and feel, if you are really trying to do something that is visually arresting and excellent, you can pay thousands of dollars for that and that is your organizational decision, sort of what your budgetary threshold is.

But the consensus and I was struck by how absolutely consistent the consensus was, was that you should be firing off budgetary red flags if you are getting a quote above $10,000 for that "typical website" that I have just described.

In addition to that $500 to $10,000 additional cost, your hosting will probably run you 10 to $20 a month, $50 a month will be at the high end and the only people we know paying $50 a month to host a simple website are folks who get a large amount of traffic and just need a more responsive server, but for the most part for most grassroots organizations, say on the order that see 5,000 to 10,000 visitors per month, a $10 or $20 package will always get that done.

There are free options like Dreamhost. Dreamhost gives free hosting to nonprofits. My experience is that it is the not the fastest hosting in the world, especially on the backend, but it is an excellent opportunity to explore if $10 or $20 is a budget constraint for you.

The other costs to factor in when wondering what your website will actually cost is any hosted tools you plan to integrate it with, if you have a constituent relationship management system, if you are paying for an e-newsletter like Constant Contact, if you are paying for action tools such as those provided by Democracy in Action. Those are

p.7

obviously additional costs that are not covered inside of this very simple costing framework.

Moving to the next slide: cost escalators. How do you do things that make this typical grassroots nonprofit website cost above $10,000? The most consistent feedback we hear from all our implementers is that integration is the most rapid cost escalator. So if you are saying, "Hey, I want to do this new website, but I want to integrate it with this third-party application or this custom application that's being built by a sister or other allied organization," all bets are off about what that's going to cost.

I will still give you a boundary at the bottom of this slide, but the integration costs are always time and material and the nature of integration is such that no generalizations can be made. It just depends on what you are trying to integrate.

A variance on that, legacy databases, legacy systems, if you have got parts of your old website that you don't want to rewrite and instead want to integrate it with your new website, that's also a cost escalator. The most common cost escalator is the quintessential additional features.

If you are trying to connect to Democracy in Action or Salesforce or say with CRM, if you want add forums or chat or a web registration or Google Docs and Google Mail, integrate it with your site, these are all additional features that will drive up the overall cost of delivering your "typical" nonprofit grassroots website.

But the consensus with all the people we work with is again red flag should be filing if that budget goes over $20,000. Does that mean that over $20,000 is invalid? It just means that you are moving into the high end of what a "grassroots" website should cost. I say this because we have talked to a number of organizations that have dropped $40,000 or $60,000 or $100,000 on a website that really wasn't much more than what I have described here.

If I lived for anything in this life, it is to not see any more nonprofits pay those extra tens of thousands of dollars for what is really an off-the-shelf website functionality suite. So that's my passion in this regard. That's why I am doing this call. That's why Aspirations loves it when you call up rep and say, "Hey, what should we do about figuring out what our website should cost?" We love to coach folks on those kinds of questions.

Hey, let me make some sweeping clumsy generalizations on the next slide. The first is that one of the ways I see nonprofits driving the cost up is that they get the developers and the implementers involved too early in the process. Our simple advice to nonprofits is make sure you have a concrete vision of what you want before you go to the implementer.

There are caveats to that. You can do things in parallel, interviewing implementers as you are figuring out revision never hurts, but in general you don't want to go on the clock and start paying hourly until you know what you want. I will say more about the phrase "what you want" on the next slide.

p.8

Nonprofits should not the implementers for what I lovingly call "group therapy" or what might be more constructively called organizational development. So many times, the website process pieces out blockages, competitions and dysfunction in the organization. Will the fundraising department run the website? Will the communications department run the website? Will the campaign part of the organization have adequate input and ability to update the website?

These are not things that you want to be paying somebody $75 or $125 an hour to sit and listen to you work through. If you want external help, name it and get it as an organizational development intervention and not as a website development intervention because website developers, with all due respect to our loving colleagues, don't tend to have the most massive organizational and group therapy chops.

And so what ends up happening is you are on the clock working through who is going to control the website, who is going to own the website and so forth, when in fact you could have worked that out before you went and got the developers and implementers involved.

Last but not least, good design is critical, expensive design is not. And so for instance, the shop that we think is sort of the gold standard in cost-effective design out in the Bay area, Design Action, does fantastic designs for extremely reasonable rates.

There are number of other excellent design shops out there, but if a design shop comes in and says the baseline job is $10,000, raise one or both eyebrows and consider the possibility of investigating other options, because while I have no doubt they will deliver highly excellent and valuable look for the $10,000 they are quoting you, that's a lot of money to pay somebody just to make your website look pretty.

So, moving to the next slide. So I just thought I would lay down the Readers Digest version of the web process that we advocate people go through to control costs and maintain control of the overall web process. So first, as I have said already, don't even think about engaging implementers before you and your organization have agreed on the following.

What are your specific and concrete goals for the site? What is it actually trying to get done, put that in writing and make sure all the stakeholders, fundraising, communications, executive staff, campaigners, janitorial. Make sure all stakeholders that want input have some consensus on the concrete goals for the site you are creating before you start talking to external partners.

Secondly, know who you are developing the website for. One of the fastest paths to cost overruns in website development is the answer, "Everyone," when queried, "Who are you trying to develop your website for?"

"Everyone" is a simple answer, and statistically it probably makes people think that more people would give you donations if "everyone" was coming to the site. But sites designed for everyone end up serving virtually no one, and sit there as very inert brochure-ware online without really addressing the needs of the people who do want to come specifically to your site.

p.9

To that point, we encourage you as you identify your audiences and prioritize them, to talk about what value you want the website to deliver to each of those audiences. And that's a paradigm shift for a lot of nonprofit folks, especially in the campaigning and communications spaces.

Websites are not large megaphones that have infinite global reach. Websites should be modeled as very powerful two-way communications that allow you to interact with online constituencies that either want to obtain information from you or want to offer you resources and input.

And to the extent that you design your website with specific audiences in mind and a sense of the value that you are trying to deliver to those audiences, you will have a much better handle on costs and a much more concrete set of proposals coming your way for the implementation that you're asking third-party vendors to do for you.

Finally - and it's the most important in a way, but I put it last on purpose. What takeaways do you want visitors to leave your site with? As people come to your website, what it is that you want them to think? What is the "a-ha" or the learning or the meme that you want stuck in their head as they head on down the information highway?

Once you've worked through these four issues, then actually go to the trouble of sketching out what content you think might be required to support all of the above. I'm not talking about getting a finished website product with every page designed and the entire global navigation concretized, but if you go to implementers having had these conversations and having a disposition on these issues, even if it is still a work in progress, you will save yourself angst, you will save yourself cost overruns, and you will save yourself the inefficiency of going around in circles trying to describe these things as you're working with the implementer.

A mantra that we strongly encourage organizations to repeat in the shower, at the coffee break, and during meals and conference calls: technology lasts. So many organization are like, "I've heard we should do a Drupal website, so that's what we're going to do." Our advice is, move to the technology discussion after you know what you want, after you know what you're going to do to serve your audiences, and after you know what your overall functionality goals are for the site.

Because at that point you can make an informed decision about what particular technologies make sense for your site. The exception to that is if you need to do research, especially around integration, it's OK to be doing that technology research earlier in the game, but you don't want to be picking your technologies until you really know what you're building. That's the way you keep costs under control.

Hey! Let's talk about other aspects of the process. A lot of organization fail to actually engage target users, people who actually represent the audiences that they are trying to serve. We strongly recommend that you find actual warm human bodies that are willing to be part of your design process, serve in an advisory group, and verify that your vision for what the site should offer matches what they want and how they want to be served.

p.10

Secondly, we are huge fans of designing in low-tech way. Simple sketched on napkins are not the worst thing in the world, and a nice middle ground is to design in Photoshop, to make graphic images of what you want your website to look like before you ever pay anyone to write any actual running code.

The term "codotyping" refers to iterative designing your website by paying someone to write code that mirrors the functionality you want. That is a very expensive and very inefficient way to get to website functionality. Photoshop is a very easy thing to iterate on and revise. And when you get to something that you think you want, take that to the folks that write to code and ask them what it looks like to put that into an animated state.

To that extent, again, finalize your design before you take it down to the implementers and you will avoid chasing your tail and getting into that somewhat vicious cycle of, "Oh, we think we know what we want. Oh, now that it's being coded we changed our minds. Oh, let's go back to the beginning and start more design."

Last but not least, don't have the "keep in the lab until it's perfect" mentality. Have the "show it to anyone who's interested as soon as there's anything to see" mentality, so that you're getting feedback early on so that you can identify issues and address them while the overall site work fluid and is not, as I say, "ossified" into a final calcified site of website template architecture.

Moving on down the line: cost control. Another pathology that we see is a lot of folks think they know what their audiences want and they're like, "We're going to build a library of resources with ten gazillion excellent resources," and they haven't actually looked at their website traffic to see if anybody is looking at their current resources page. Or more generally, what people are actually looking at on their site.

And so as you're going to redesign a site, we passionately beg people to think about looking at your website traffic over time, gaining an understanding of the value that people are gaining from your site by knowing which pages are most popular, who is driving traffic to you - that is to say which sites are referring traffic to your website -- and what Google and other search engine keywords are also driving traffic to your site.

Those three data points give you a very clear idea of the value that people are trying to get from your site, and it is with that information that you should prioritize new features on your site so that you don't build things for which people are not going to be looking.

Secondly, and this is just something I am so passionate about I don't know how to convey it without you seeing the funny look on my face. Don't write custom code if at all possible. I personally believe, as a recovering software developer, that each line of code you pay someone else to write is a stone around your organizational ankle.

If you are using existing code as Drupal or Joomla! Or Plone or WordPress, it's somebody else's problem to maintain that codebase and to maintain the modules and the extensions that give you the functionality you want.

p.11

The minute you decide, "Oh, there's nothing out there like what we need, " and pay a developer to create it, you have just adopted a baby/child codebase, and it's going to need a lot of tender loving care. It's going to need security patches, it's going to need bug fixes. And as other aspects of the system, such as the main content management system, get updated to new versions, you're going to have to pay somebody to make sure your piece gets upgraded in parallel with that.

To the extent that software development is rarely a core competency of the nonprofit organizations, we humbly invite individuals in the nonprofit website design realm to learn to use off-the-shelf features, because maintenance does cost, and often it costs something close to dearly.

Dramatic pause, as I click to move to the next slide. Which technology selection, I just wanted to point out that there are different technology stacks. And by stack, I'm referring to the collection of the database technology, the website page technology, the web server technology, and so forth.

In the nonprofit sector, PHP is the people's language. It is the lingua franca of nonprofit website development. It is not a tricky or elegant language, but it is the most cost-effective language. There is a rich supply of PHP talent, and the market prices are fairly stable and well-defined.

For other stacks, such the Ruby On Rails stack, or the Plone/Python/Zope stack, there's just less implementers out there focused on the nonprofit space. And in classic supply/demand dynamics, that means higher costs for those people doing that work in general.

Secondly, we totally encourage you to be curious and nosy. Ask other organizations, ask your allies. What are they using? How are they publishing their website? What do they like about it? What don't they like about their website tools?

Learn that, it's great, great coffee pot conversations when you're at one of those conferences where there's nothing else to talk about. Ask people what they're using for their website and what they think about it.

A thing that has happened, a brilliant and wonderful thing that has transpired in the last nine months, the WordPress content management system, which is historically thought of as blogging software, has actually matured to the point, both in terms of usability and features, to be a very, very good low-end content management system.

There are plenty of things it does not do, plenty of things that you need a Drupal or Joomla! To do for you, but for a lot of organizations just starting out, WordPress is an extremely cost-effective way to do that 25 to five page website, and in the process gain experience with web publishing and gain an attitude about what you actually want in a future website - a two- or three-years out website - if you don't want lay those big bucks down now.

p.12

It's not always the right call. Nobody wants to do a website twice. But our experience is that a lot of orgs that started out on the WordPress level were able to ride that for a pretty good distance and if they ever needed to migrate to Drupal or Joomla!, there are well-defined migration paths to get you that way.

Moving right along, implementer selection. One of my favorite topics. When you are picking the people that are going to do your website, here are some guidelines, more sweeping, clumsy generalizations from Uncle Gunner.

Select relationships, not platforms. As I mentioned earlier, we talk to so many people like, "We decided to use Drupal." And we are like, "Well, who is going to do that for you?" Like, "We don't know. We're just going to find a Drupal shop."

Our advice is no. Actually try and see if you can find an implementing group that has worked with other people like you, that has worked with people so that they understand how you operate, and go with them and let them help you define the technology that makes the most sense for the needs that you have identified.

By extension, we strongly encourage you to select organizations as opposed to individuals. In the tech world, many people know the metaphor called "hit by the bus" phenomenon.

If you are working with an individual, a sole contributor, and they don't have a little bit of organizational infrastructure around the, if they get hit by a bus, if they get captured by aliens, or if, more likely, they get bored and go to Australia to surf for a while, you are in an awkward situation.

Organizations can offer a little bit more sustainability and accountability than independent consultants, and we say that with no disrespect to the excellent independent consultants that we love to work with all the time.

A really important part of implementer selection: don't be their first date. So many people will be like, "I know how to code websites, and I've really wanted to work with nonprofits for a long time." Our advice is that is not probably going to be the most fruitful relationship.

Work with somebody who has experience with nonprofits and has dealt with orgs hopefully somewhat like you. That is a critical difference maker in both the success of the project and control of the costs.

And last but not least, there is a universal insecurity in the nonprofit world. People come to us all the time in a confessional mode, and they are like, "I just don't know what any of this tech stuff means, and I just don't feel like we can talk to anyone about our website."

Our advice to you is assert your right to speak in programmatic language and work with an implementer that is willing to converse with you in your programmatic language, where you can talk about donors and you can talk about campaigns and you can talk

p.13

about programs, instead of talking about PHP and MySQL and Postgres and intrinsic code, this, that, and the other.

Whilst that will need to come up at points along the way, a good implementer keeps the dialogue in your vocabulary for as much of the time as possible and explains the technical details on a need to know basis, when you are ready to understand those pieces.

Let's go on ahead. Process stuff: when in doubt, leave it out. We really believe that small, effective websites are the way to go.

While a lot of people have the home run mentality when they do websites, we encourage you to think: what is the minimal set of functionality with which we can launch the website, start soliciting feedback to start analyzing traffic on the site, and to have an informed idea of where to push subsequent resources to.

Part of the beauty of working with one of the freer open source content management systems that I mentioned earlier is that those are all highly extensible, and the fact that you don't have all your features running when you first launch your site is by no means a bad thing.

Those platforms are designed to phase in new functionality over time. And while I am in no way implying that that is a simple process, it is certainly a very doable process that we encourage people to consider.

In particular, as the website is being implemented, resist the temptation to incrementally suggest minor enhancements. That creates a moving target of a deliverable and is guaranteed to drive up your costs.

One other somewhat technical point: know the difference between templates and content when you are developing a website. What you are paying your implementers to do is to get your templates and the overall container of your content fully functional.

We strongly recommend that if you can possibly do it in-house, have your own staff or the person or people that are going to maintain your site do a lot of the content work because a, they gain familiarity with how the system works and can give feedback to developers early in the process, and b, because it is awful expensive to pay people $75-$125 an hour to copy and paste text into pages.

So we strongly encourage you to understand that which is code and does need the implementer to focus on and finish and deliver, versus that which is content and you, the org, can take ownership of and learn to smith from a very early stage in the website deployment, and in so doing, lower costs of delivery and lower costs of maintenance by having that experience. And I don't think I need to say anything more about that.

Moving right along, almost done with this whirlwind set of sweeping generalization.

Financial stuff. One of the most pervasive cost overrun pathologies is the poorly-defined change order process. You should, when you start a web project, have a written document

p.14

that you sign a contract around. It says what is getting delivered, how much money is getting delivered for that and document how additions to the deliverable will be handled.

In particular, verbal is a bad way to go. So many organizations call up their implementers and say, "Hey, could you add a page that has this on it, and then link it to a page that has that on it?" You just asked the implementer to do more work. They are going to charge you additional money for that. It is a bad practice not to ask for an estimate on how much additional time and money is involved in those incremental new features.

Do ask, do tell. Ask for estimates on any new or changed work, so that you have a clear understanding of how your original cost profile is tracking.

One thing that we see a lot of is organizations not realizing they have a right to do -- website implementation can take months, ask for granular billing. This is to say detailed billing. Instead of 75 hours web development, ask the bill to tell you five hours is spent on the fund-raising page, seven hours is spent of the forums page, three hours was spent on the dot-arc pages and so forth.

Get granular billing information from your implementer and have them invoice you regularly, as opposed to at the end of the project. So, you know what you're getting billed for as it's happening and not at the end. Because, the at-the-end bill can be awful, awful, indigestion-inducing.

Hey, I'm on to the shameless shout-outs for the people that we work with, implementers that we love and adore. Radical Designs are based in the San Francisco Bay area. I really think Radical Designs does the best-of-breed campaign, event and social media websites.

They have their own platform, the Activist Mobilization platform, and they have just done phenomenal sites for people like Step It Up, who did a national day of action to raise awareness about climate situations. They've also worked with a number of other different other types of campaigns. They are able to mount campaign strategy with Red Delivery.

FloatLeft, they do our website. Courtney Miller is the founder of FloatLeft. They are, in our opinion, the consummate Drupal professionals. They are very popular and often booked months in advance, but we absolutely adore them.

PICNet, Ryan Ozimek and his covey of passionate Joomla! Implementers do fantastic work in San Francisco and DC. They have a platform called the Nonprofit Soapbox that very beautifully integrates Joomla! With Democracy in Action. You get both the benefits of an open source content management system and a very powerful online action center. This allows you to run events, have people take online actions and otherwise send communications to media and elected officials.

Moving on the second page of our love-bugs, Happy Snowman is a small shop in the Bay Area that we think the world of. Kathryn Benedicto runs that and she is fantastic. OpenFlows, based in New York City, does phenomenal Drupal and CiviCRM work. We love it anytime we get to hang out with them. And in the Midwest, Chicago Tech

p.15

Cooperative does really, really good Drupal and CiviCRM work. We love to break bread and share beverages in their presence, not to mention collaborate with them.

So, folks, I've been rambling on. You can probably tell that I've had more than one coffee today. But that pretty much is the end of my diatribe about what a website should cost and how you can control the very same.

Takeaways. I have you at least agree ever so slightly more that you can, in fact, control your web destiny and costs by following a few best practices and philosophies. We really encourage you to know what you want before getting the implementers involved. It's the main way of keeping costs under control. It doesn't mean that you know everything that you need to know, but it means that you come in with a vision and can work it a collaborative environment, instead of being at the mercy of people who walk you through a process that may be foreign to your org.

Whew, I just said the P word: process, process, process. Please have a plan for all aspects for the way that you do your website. That includes the things that I mentioned about the financials and the process stuff.

But in general, the mantra to repeat there is, "Do we have a process for this? Are we following a process in this regard of this project?" If the answer's no, raise and eyebrow and say, "Oh, perhaps there should be a process put in place here," and make this manageable and sustainable.

What is more, don't try to hit the homerun. Don't try to do the slam-dunk. Don't think in sports metaphors; they're kind of annoying. No, what you should do is, when in doubt, leave it out. Good web platforms are extensible and you can add stuff incrementally later, once you see what people are looking and wanting from you.

But get a smaller site online, and get your online audiences engaged and let your online audiences tell you what the website should do for them instead of deciding that and then pushing it their way.

Try to avoid moving targets, and that is to say make sure you have a fairly fixed idea of what you want before you start, and be very methodical as you change that vision to get written estimates and updates on how that will impact delivery dates and costs.

If you can possibly avoid writing new code, avoid writing new code. Use existing code; it will make you happy in the long run.

You will focus on your program and your mission and less on the nuances of PHP 4.1.2 versus PHP 6.7.2.1, which no longer respects the obfuscated MySQL operator. And if you don't know what I just said, apologies. That is why I am telling you use existing code. Wink, wink.

Finally: communication, communication, communication. Talk to folks. Talk to peer organizations. Talk to your online audiences. Talk to users of your site, and get input as you are going through all of this. It keeps costs down by helping you cue to the absolute

p.16

most focused set of goals and most focused set of value delivery to the people that you are building your website to serve and empower.

My friends, thank you for hanging in on this long, rambling run. I believe my co-host Rebecca might have a question or three queued up. I am delighted to take questions.

And if you want to follow up and have any questions for us, AsirationTech.org. We love talking about this stuff, we love helping people keep costs down, and we are always there. Don't be shy. Rebecca, over to you.

Rebecca: Wonderful. Thank you so much, Gunner. I know that I learned a lot, and the questions are indeed rolling in. So for those of you who do have questions and haven't written in yet, please feel free. We will get to as many as we can. The email address one more time is fundraising123@networkforgood.org.

All right, let's just hop right in. Before we get to some of the more strategic questions, we did have a good question that came in from a couple of folks. I'll read it the way Amy phrased it.

She says that in your presentation, you were discussing costs for implementers, but she is a little confused as to who falls under that implementer umbrella. Does that refer to design, system architecture, implementation, development? Can you define the term a little bit for our folks?

Gunner: Absolutely, and I apologize for using a vague term. It was my intention to be inclusive on a number of quotes. Implementers to me is distinct from designers, and so to the cost components I listed earlier in the slide deck, implementers to us are the people who know how to take your website design and translate that into a running web application, a running website on a free and open source content management system. So implementers are the FloatLefts reps the PICNets and the Radical Designs. They all tend to outsource their design. They tend to work with design partners or they tend to work with people that have had the design done by a third party.

So implementers to us are the people that go from the design website to the functioning website and make it run and train you and support you as you keep it running.

Rebecca: Excellent. Thank you for defining that for us. All right, we have a great question from Vicki, and Vicki writes in and says, "Are there any tools that I can use to help define what my organization wants from our new website? I need to get feedback from staff, board, and constituents, and it would help to have some questions to start with."

Gunner: That, Vicki, is a superb question, and sadly there aren't many great ones, but I will tell you the one that I use that I think is pretty effective in this regard, and that is the online project management tool Base Camp. And what you can do in Base Camp is that you can track requests. Base Camp has a simple little feature called a To Do List, and I will create to do lists for different stakeholder groups in a project.

p.17

So if I am talking to my fundraising team, if I am talking to my communications group, if I am talking to my campaigners, I will put their wish lists individually into separate to do lists. I will invite them to prioritize those wish items so that they tell me what are the most essential things versus the would be nice versus the "I know I'm probably not going to get it but I'm telling you I want it anyway" category.

A tool like Base Camp is fantastic on two levels. It is a simple user interface, so most anyone in your organization can use it and not be intimidated by it, and it is a great transparency mechanism, because anyone that you give access to that Base Camp website can see what everybody else is saying, can directly contribute, and otherwise update the wish lists and other feature requests.

As you synthesize those feature requests, you can then turn those into other lists or documents within the base to reflect what you think you're going to do, what are the primary goals, and what are the primary functionalities.

So, net-net, Base Camp is not a web design tool per se, but to my experience it is a very excellent general-purpose tool that does give you a project management component of trying to solicit, manage, and track all that input, but also make that available to all the other stakeholders.

Rebecca: Excellent. Our next question comes from Amanda, and Amanda actually has two quick questions. First, and I understand that this is probably going to be pretty general, but what is the average amount of time it takes to update a website? The second question -- I think we'll throw that one out first and then I can follow up with the second question.

Gunner: Cool. I'm going to say I'm not clear on what's meant by "update a website," but if you just mean actually changing what's on the home page, or editing the content of a page on the site, that should be extremely quick. One thing that I probably implied but did not state: the era of Dreamweaver has largely passed. It used to be, back in the Dark Ages, when I was on the Internet dot-com front, that Dreamweaver was state-of-the-art, and you edited pages on your local machine and then uploaded them to a server to be live on the Net.

Content management systems make Dreamweaver a much more vestigial tool. Dreamweaver can still be used early in the design process, but you actually do your website updates in a way that is similar to using webmail.

So in the same way that you would go to a Hotmail or a Gmail and say "compose new message," type in a subject and content of the message body, with content-managed systems like Drupal, Joomla!, Plone, and WordPress, you're able to log into the website as an administrator and say, "I want to edit this page, " at which point the content within the page becomes directly editable.

You make your changes and then you hit update, submit, or whatever the button says. To your question, that's as quick as you need it to be. Our recommended best practice there

p.18

is have copy-pastable text ready to go onto the website as opposed to composing in the content management system.

Get whoever is responsible for writing that content to write it in a word processing tool, and then have that content ready to be copy-pasted into the website page that you're editing. If you follow that process, the actual act of updating the pages is measured in minutes, not hours.

If I didn't answer your question, I'll invite you to submit a follow-up clarifying question in that regard.

Rebecca: Excellent. Well, I'll give you her second question, which might help us update the first one just a little bit, because maybe she means the whole process. Amanda's other question says, "I'm working with a board-driven task force to develop and design. They are rather tentative to do anything. Do most nonprofits depend on a board-driven site, or should it be an operational procedure?"

Gunner: Those are phenomenal questions! I don't want to offend any board types on this call, but I think it's usually a bad idea for the board to drive the website process. I am a customer satisfaction paradigm believer. That is to say, I think that you way that you make a great website is to really have the people that are on the ground with your constituents, directly in contact with your online audiences, doing the programmatic day-to-day work of your organization... Those people need to be driving or having central input to the web design or redesign process.

Who owns that process can vary from org to org. It might be your communications team. It might be fundraising. It might be the executive staff. But you absolutely want a good web process to be driven from within the org, because unless you've got an organization where the board actually is day-to-day on the ground doing work in the office, they're not going to have that immediacy with your online audiences, and the odds of a successful project in the client opinion are substantially lower.

As far as how much time might that take? The amount of time it takes to get to that set of vision pieces I talked about: who your audience is, what are they looking for and what value are you delivering to them, what are your objectives for their time spent on your site. There is no fixed amount of time that I would tell you that takes.

It can be slow. It can be arduous. It can be quick and not so painful, if you are a well-aligned organization with good communications channels and good transparency. But our advice is to model that as the large, cumbersome time chunk and get to that shared sense of who you're building this website for, what the goals of the site are, what the value delivered is, and then move to the website deployment and implementation phase.

If you're looking for a time estimate there, there is the unknown of when your implementer, when your actual website deliverer, can start working. But once they start working, if they are paying full attention to you, or consistent attention to you, most

p.19

websites can be delivered in one to three months. Again when I say most, I'm talking about these "typical" 25 to 50 page websites.

All the cost escalators I mentioned make what I just said meaningless and irrelevant. But if you have an implementer, they're good to do, you have a 25 to 50 page site, and you've got the inputs that I've described, then one to three months is a very reasonable timeframe to go from design into running a site. But there are so many variables, that I don't feel confident giving declarative timeframes.

Rebecca: Got you. No, that makes perfect sense. All right, we have a question from Janet; this is an interesting one. "What about web host companies that provide all types of features and functions? Anyone could create it, because they use scripts that are easy, they are WYSIWYG - what you see is what you get - and have more than 100 templates to get you started? For example, sites like HostGator, JustHost.com, HostMonster, et cetera? They cost around $8 to $14 a month, which would only amount to about $140 to $180 a year. Are those web-working companies better? What are the pros and cons of using companies like that which provide everything?"

Gunner: Boy, is that a great question. It makes me realize that I left a critical bullet off my slide deck. So, let me start with my missing bullet and then answer your great question. One of the things that we counsel people in all aspects of nonprofit technology, not just your website but also all of your database stage, newsletter things or anything that you're depending on technologically, as part of entering into any technology relationship, you want to have what we somewhat humorously call the break-up discussion. You want to know what your migration options when the tool you've selected no longer suits your needs.

I would lovingly opine, with all due respect to the HostGators off the world, that they are in my estimation something tantamount to benevolent crack dealers. They want you hooked on their platform so that you'll keep coming to them. It is not in their best interests to make the migration and export of your content easy.

So while I would not blanket condemn those services, I would say that in general we don't recommend them. Because, we absolutely see situations where people start using a premade template and some real cool services and put a site together. Then at the point that it hits growth limits or at the point where that vendor goes out of business or starts having really slow servers, you don't have an easy migration strategy. So, always know what your migration path is.

An excellent middle ground to do what you're describing for the costs that you're describing, WordPress.com is a hosted version of WordPress where you can point your domain at your account. So, you can have myorganization.org and point it to a WordPress instance. They have a really nice setup there, where you can install some plugins that WordPress supports. You can't install all of them; they have to be approved by the WordPress team.

p.20

But WordPress.com is a great place to get a low-cost prefab website that has the cost numbers you're talking about, between zero and $20 per month. And they have phenomenal export features.

So anytime you decide that you want to take your toys and go to some other server, you can export that WordPress account. It will come down to your local machine. And you can import that WordPress data into a WordPress instance running on a different server, or that data can also import into Drupal, Joomla! Or some of the other platforms.

So, Janet, on your question, I tend to be skeptical of those services, because the exit costs are high. And in general they tend to be kind of gimmicky and not really have the philosophy of nonprofits. Anybody who has strong counter-examples, I humbly invite you to email gunner@aspirationtech.org. I would love to know about plug-and-play, sort of easy, configurable websites that you think would really be neat nonprofit aids.

The heuristic I always apply is, "Can you migrate and get away when you need to?" That's why we so passionately recommend Drupal, Joomla!, Plone, WordPress and open source tools. Because, you always have a really rich set of migration options.

A final point on that is you always want to control your technology destiny when you're a nonprofit. What I mean by that is you want to have a very strong leverage over the server where your site is hosted. You don't have that with those free services.

Any time you're getting something for free, you have zero ability to complain and zero ability to escalate your issues. If you're paying $9 or $20 a month for hosting, you have someone to call; you have some resolution path to follow. That's really, really important even if it's painful to be paying that $9 or $20 a month.

It really changes the game, and we really encourage people to have that financial accountability with server vendors and to have that control where you can say, "Hey, we want to point our domain at a different server. We want to point our domain at a different service, because we're no longer getting what we need from our current web-hosting service." And have that operation - that migration - be a straightforward exercise not a painful, wrenching, technological divorce. I've seen too many of those, and it would make for great techno soap opera.

Rebecca: Haslett writes in and says, "What's the best way to request and compare bids from companies?" And then, Mary Ellen said, "What about people who want to be paid up front for all of the costs?"

Gunner: Two excellent questions. I'm going to kind of punt on the first one. Anybody who watches the NP-Tech mailing lists - the Intend Discuss, 501 lists, the Lighters list and so forth - know that people are always fishing for RFP templates. So it is honestly an unsolved problem of the dev realm. There aren't, in my opinion, any really good, tsunomical RFP formats. That's in part because I haven't spent enough time doing the homework there. So to that question, I would say the following. We strongly advise and ask nonprofits not to put the implementers through rigorous RFP processes. A lot of organizations demand a 40-page response to an RFP. We think that's kind of hateful. The

p.21

vendors - the implementors - if they're going to do that in earnest have to put a lot of time in, not knowing whether they're going to get their money back.

To your question about comparing RFPs, our answer is, have a really pretty straightforward and simple RFP format. If you're looking for those, you can actually Google and look for RFP formats. Depending on how friendly you are, searching the archives of the listservs that I mentioned, including the ones on Intend, there is plenty of discussion about templates for RFPs for different types of online projects.

My advice, in terms of making them comparable, is to keep them simple. Keep them short and try to figure out exactly what you need to know from the vendor in order to compare what they're saying with what's coming out the same. My general advice is: RFPs are an important part of the equation. But the most important thing to be comparing is references.

So, if somebody is giving you an RFP, what you really want to do is take that RFP, see if they can give you client referrals, client references and people that they've worked with and finished deliverables for and talk to those people. And say, "Hey, I've got this RFP, does match your experience?" Because, if the RFP matches the experience, that's the data that you need to know. Because it's actually worth comparing to other RFPs.

So I don't really have a really clean or tight answer, but hopefully that's some useful input. Then, Rebecca, I've already forgotten the following question.

Rebecca: The other question was, in terms of when you do start to get bids back, how do you feel about contacting implementers who wants to have set rate set out and get all of their money beforehand?

Gunner: Don't do it. Do not do that. I think it is extremely reasonable for an implementer to ask for some amount of money up front. It is a show of good faith. The percentage varies but, in general, you need to hold your cash on your side of the line, until you get the value delivered. If you give them all the money up front you have no leverage to get the job done. What we recommend as a payment schedule, is to figure out in partnership with your implementing entity - whatever person or group is doing your website for you - a set of payment milestones. Payment milestones could include design and finalize. It could include project management system is installed and basic template is configured.

Come up with some basic payment milestones. Then deliver out-payment in proportion to the milestones. You want to be, in my opinion -- and I'm just pulling these numbers off the top of my head -- I'd say that you want to be holding on the order of 25%, maybe even 33%, of your money in your pocket until close to the end of your project. And you don't want to give away that last 10% or 20% percent of the cash until everything about the project is finished.

Because it's sad but true, but once all of the money is in the bank on the other side, you're just not really going to be as attractive a social option as you were back when you still had some payment to make.

p.22

So I encourage you to meet in the middle. Feel free to give 10% or 20% up front. In certain situations for smaller projects, I think 50% is fine.

So if you're doing a $2,000 web project and someone asks for $1,000 up front and they've got good references, I think that's a reasonable ask. But I sure wouldn't be giving them the other $1, 000 until we were pretty much done with the project.

So long story short, do not pay all up front, but tying incremental payments to milestones is a very nice way to meet in the middle.

Rebecca: Excellent. That's a great suggestion. All right, let's see. This is a great one from Robert. Robert says, "What are some ways to get our management to think beyond redesigning the website for 'everyone'?"

Gunner: Damn good question. There's no simple answer, but the first thing to do is to really, really - I think there's a simple argument that I find gets traction with everybody. And that is there's this term that I find annoying but accurate, and that is the metaphor of the attention economy. As we move ever more into the virtual Internet realm of existential operation, we're dealing in a situation where there are billions of websites, and the competition for your attention, the competition for the attention of anybody's eyeballs, is extreme.

So if you design a website for "everyone," you are increasing the likelihood that it will be compelling to no one. So if you instead if you have an articulated vision of who your website is serving and what value - emphasis on value - your website is delivering to those audiences, you have a much higher probability of drawing traffic and a much higher probability of engaging your online audiences and getting input from about how you can increase the value you are delivering or evolve your website to be responsive to their needs.

If you are trying to design for everyone, you're going to fail by vagueness and you're going to fail by mediocrity, as crass as that might sound. So I think it's really important just to talk about the opportunity costs of not having a clear sense of who the website is for.

The concrete way to do that is to get a look at your analytics. I mention in my slides Google Analytics. Google Analytics is a phenomenal tool that is free to look at who's coming to your website. I have fundamental concerns with it because Google is the Big Brother of our generation, and if you are working in anything within the edgy or, heaven forbid, political context, you don't necessarily want all your visitor data sitting in a corporate server that can be subpoenaed by the Patriot Act at any time.

That said, a tool like Google Analytics will tell you what pages people are looking on, what patterns they are following to your site, and who is sending you traffic. That is a really great set of data to take to your senior management and say, "Look, the parts of our site that are getting traffic are this and this. That probably tells us that our audiences care about this and this. And that should be important in what we prioritize as we redesign the site so that we continue to draw that traffic even as we build on that."

p.23

Rebecca: Excellent. All right, great. We have a question, and I think this would relate to a fair number of our organizations. We have a question from Bethany, who says, "First, thank you for providing all this information. My question is, we have to produce our website in four languages including Arabic. How much should we expect this to increase the complexity and cost of developing a content management system? And are there any CMS you feel are particularly adaptable to a website like this?"

Gunner: Right on. Well, first of all, thanks for the kind words. Glad to know this is useful. Boy, you just hit a sweet spot of Aspirations programmatic passion. That answer is that right now there aren't any good content management solutions, certainly in the free and open source software space that really do that multilingual thing well. I will annoy some allies of mine by telling you to call them. There is a fantastic group called Project 350, and they are currently working on a multilingual website around climate change. I have spoken with them and I think they're doing incredibly savvy work on multilingual and they are handling - for those on the call that don't know the subtlety of this, handling Asian and Arabic character sets is really complicated because among other things, they read right to left as opposed to the Western left to right. And in addition, the character sets themselves are much more complicated than our humble 256 character English character set.

So folks like Project 350, if you have any interest in actually just going to their website and calling them up and apologizing to them that they've got a set of calls from people dealing with multilingual websites, they're the kind of people I think you should go to talk to. Because I think what they're doing is really, to my mind, at the cutting edge of solving that problem.

To your question about the platforms, Drupal and Joomla have conventions, and that is to say ways of supporting multilingual content, but they don't have really rigid support for multilingual websites yet. Rumor is that they will both have much better support for multilingual websites in the future.

Take that with a grain of salt, but I think it's a true statement. In fact, I know it's a true statement. The grain of salt is about what future means. Is that three months from now 30 months from now? That's the tougher nut there to actually get your arms around.

Advice I would give you in this regard is the following: the conversation you should have as you are trying to decide on you particular solution is, what is the process by which the multilingual content is contained? This is includes what is the process by which the content is translated, because that is a separate process from the publication process.

But once you get the multilingual content, once you get the content that is parallel in the four languages and want to put that up on your site, before you make a technology decision, before you start implementing, have a really thorough discussion about how that works in practice. Make sure that you can visualize yourself living with that practice moving forward, because it it's crazy and there's 74 steps and it involves calling the United Nations to verify this, that, and the other, you really want to ask yourself whether of not that's going to be a sustainable process.

p.24

And really before you pull the trigger on going that route, have a real gut-check conversation and make sure you think that model will actually work day-to-day for months on end.

All this to say, we are actually running an event in Amsterdam in June, the Open Translation Convergence 2009, to bring together the very people of whom I am referring to, the Joomla! Folks, the Drupal folks, as well as a number of other developers of free and open source translation tools to talk about these problems.

Because, honestly, they are unsolved. We will be publishing a book coming out of that event that talks about best practices for this kind of work, because that documentation does not exist. So while I realize it's not particularly friendly to say, "Wait 12 weeks and I'll have you an answer, " we are planning to put out documentation on that translation set of challenges and try to demystify some of this stuff.

But to your original excellent questions, that is a solution in process. There is nothing really good and ready to go. The one other point I would make is the Plone and Python stack has, to my knowledge, the best out-of-the-box multilingual support. And shops like One Northwest out of Seattle - who I cannot say enough loving, positive, and sort of aw-struck things about.

I think One Northwest is sort of the highest standard to which all website implementers should be held. They are doing incredible stuff with Plone. Plone is a really good multilingual web platform. One Northwest doesn't do general implementations. They're very focused on their constituency of environmental groups mostly in the Northwest.

But if you can go the Plone route, which means you're going to pay a little bit more and have a harder time finding consultants, Plone is probably your best free and open source platform for multilingual. Unless...you think you can get by with WordPress, because WordPress is certainly a pretty good low-end multilingual solution.

But again, there's a lot of assembly required, and a lot of by-hand work that you have to do to keep a multilingual WordPress site going. It is by no means built into the WordPress platform. And that is my long, rambling response to your excellent question about multilingual websites.

It's an area that Aspirations pays a lot of attention to, because the use case we're most passionate about is the bilingual website, organizations that are working with in Central Valley, California, that just want to publish English and Spanish, or English and Tagalog, or English and some other language.

It should be so much easier than it is to just maintain two parallel content sets. So that's my unsolved problem. If you're interested in learning more, please feel free to drop me an email afterwards and we'll make sure you know more as we know more.

Rebecca: Excellent. Thank you for your explanation of that. And we did have a comment come in that let us know that Grassroots.org also offers free access to a language translation tool for websites, and that's powered by Word Lingo. It supports 15

p.25

languages including Arabic. So that's Grassroots.org as another option to check out. We've already held you over for quite a while. It's now 2:15. So I think maybe we will wrap on up. I know we have some other pending questions and we'd love to follow up with folks after the call as well, so let's keep checking your email.

But we wanted to thank you again so much, Gunner. This has been great call. We've seen some of the highest question traffic that we've ever received. Thank you for being with us.

Gunner: Oh, thank you so much. I enjoyed it. Thank Network For Good for offering such a valuable format in which to share knowledge. And thank all of you silent listeners and tell all of you how much I'd love to sit across the beverage table with you at some point in the future. Hope to see a lot of you at the NTC. And if I can put in a plug: Penguin Day, San Francisco, coming at the day before the NTC on Saturday, April 25th in downtown San Francisco. Penguindday.org. If you want to come talk to a lot of website implementers and you're able to be in the Bay Area on the 25th of April, this month, we're going to have a lot of people there that can talk to you about getting a website delivered and talk to you about what a website should cost and teach you all about the things you need to know to stay in control - wink, wink - of your technological destiny.

I just want to thank you all again for listening. It's just an honor and pleasure. Thank you, Rebecca.

Rebecca: Wonderful, and thank you so much. Thank you all for joining us. We look forward to speaking with you on our next Nonprofit 911.

So, thank you again, Gunner, and have a great afternoon everyone.

Gunner: All right, have a good day.

Rebecca: Bye-bye.

Gunner: Bye.

Transcription by CastingWords