Who Really Owns Your Nonprofit’s Website?

The internet used to feel like the wild west. Websites sprung up like homesteads, built by an enterprising range of people using all sorts of source code. If you worked in the nonprofit sector in the 1990s, the odds are good that your organization built its first site in a proprietary system using custom-built code for which your organization owned the intellectual property rights.

Over time, the Frontierland of nonprofit websites got settled and more developed. Today, there’s a wide range of tools you can use to build a site, from plug-and-play templates like SquareSpace to extremely customizable and flexible options like Drupal. You can do-it-yourself or hire a sophisticated team that will help you plan and design your site, conducting user experience and information architecture testing and more, all before they start coding. The range of decisions that a communications professional without a digital background has to make can be dizzying and distracting. 

But one guiding principle that many organizations still overlook is ownership, both legally (as in “intellectual property rights”), and presumed (as in, “I can change it however I need to”). Odds are good that your website is owned or restricted by the people who built it for your organization or restricted in some way by the technology they used to build it.

To find out who owns your organization’s website, ask these questions:

Who owns the design?

While your organization likely owns the rights to its logo, photography, and other visual aspects of your brand, some designers retain the rights to the websites they design. Double-check that the people you’re working with don’t restrict the rights to the final designs so you can avoid conflict, expenses, or even lawsuits when you elect to change them. 

Who owns the code? 

Many agencies claim a site is built in a standard system like WordPress without making it clear that there are other layers of code that will make it impossible for another vendor to take over the site. I’ve seen several nonprofits have their websites held hostage when they find out they can’t actually fire that agency and work with someone else without rebuilding the site entirely. 

Read the fine print carefully for the systems you’ve selected and the vendors you’re working with. There are many free and low-cost tools to build websites, some of which use open source code bases (such as Drupal) that will allow you to modify code without infringing on someone else’s intellectual property. Others can’t be modified without permission. There are also custom-built modules, plug-ins, and other tools that help different systems talk to each other — ensuring that your fundraising database syncs seamlessly with your website and email system, for example. Be sure you’re clear who owns these plug-ins and that you can continue to use the essential ones if you chose to work with different people or tech. 

Sometimes losing freedom is worth the trade. You might select a donation processing platform that you can’t easily modify, for example, but does its job well.  Just be sure that you’re not trading away something you didn’t expect. Is the proprietary vendor selling/misusing the data of your constituents? Will you be able to export your data out of the system if you ever need to? Be confident you’re using best-of-class systems and partners. 

Is the code clean? 

Most people assume that if a site is built in a particular CMS or platform (e.g., WordPress, Drupal, Craft), then anyone who is competent in that coding language can work on it. Not so. Many of these sites were built with non-standard or poorly written code that only the developer who created it understands, leading to rebuilding expenses or reliance on people you may want to move away from. 

There are a few reasons sites are frequently built with problematic code. Here are some of the biggest:

  • The developer builds in a system they aren’t expert in. They’re figuring out how to make things work — not always in the simplest, cleanest ways. You’ll either have to keep working with them until it collapses or rebuild it with someone else. Make sure you’re hiring pros — not people learning on your project who may end up costing you more in the long run.  
  • They layer proprietary code on top of open source. This effectively holds your website hostage because you can’t work with anyone else. 
  • They took coding shortcuts that made the site faster to build but limit its flexibility. Developers who build websites with fixed scopes and fixed budgets can look for ways to get to the finish line quickly. The modules they build may lack the ability to be adjusted and expanded as your needs change. 

All of this can be pretty frustrating for a communications person who just wants the ability to maintain their own website as easily and successfully as possible. But avoiding these challenges and ensuring your organization owns its own website — both the intellectual property rights and the ability to modify it at will — is possible with some up-front due diligence.

How to ensure your organization owns its own website.

First, read the fine print for everyone you hire and the software you select. The terms and conditions of the code base you select, the plug-ins you use, and developers you hire carefully should outline what they control and any intellectual property (IP) restrictions. Ask your legal team to review if you’re not sure. 

Secondly, ask for references from any individuals or firms you hire, and probe the people you speak with for these issues. Clean code built by experts stands the test of time. You’ll want to partner with developers and software companies who have long-standing relationships with their clients who have built websites that are easy to change, move, and adjust. If you’re really not sure, consider hiring an objective, trustworthy independent technology expert to take a look “under the hood” of your site and share their impressions.

Ensure your organization’s website is built with tools you can easily modify, migrate, and build on — not held hostage by a developer or tech company. After all, your website is your organization’s most visible and visited home.