Big Website Projects Can Go Awry
One of the things that decision-makers in nonprofits fear most when embarking on a major website project is that they’ll sink their team’s limited time, energy, focus, and funding into a project and come out the other side with a site that doesn’t serve anyone’s needs, that will need to be scrapped and rebuilt again within a few years.
As nonprofit technologists, we have seen this happen over and over again. Organizations come to us with sites that may be just a year or two old, but are difficult for staff editors to use, fragile to maintain, aren’t meeting audiences’ needs, or all of the above.
This diversion of funds and energy away from mission work is almost always preventable. We aim to minimize this needless risk in several ways: one of them is by building collaboratively in open source software.
Why Open Source Software?
What’s great about the Content Management Systems (CMS) Drupal and WordPress is that their code is open source; it’s free to download, use, and modify. These are the two most widely-used CMS platforms in the world.
This means that an organization with a WordPress or Drupal site will have company on their website journey in the form of a vast community of peer organizations who are also using the same software, and a healthy ecosystem of possible vendors who can help them with it. If folks in the organization have questions, there are colleagues to ask. If they need something fixed or added to their site, there are many developers who could help them. There are tips to trade, recipes to share, and a community of others to learn with and from.
The Road Most Taken
But simply choosing to build a site on an open-source CMS isn’t enough. How you build it matters.
One way to build sites that last a long time, and remain flexible for future iterations, is to build with a strategic eye on the “open source superhighway”.
When a website platform is used by so many people across the globe, patterns and best practices emerge. Developers who participate in the Drupal and WordPress communities usually have a sense of what paths to take when building things using the “core” of Drupal or WordPress (before you add any plugins or modules).
When it’s time to add functionality via plugins or modules, developers close to these open-source communities know which ones are the best and most heavily used. Because in open source, the more heavily used something is, the more people have tested it on live websites with real-life editors and end-users.
These well-used paths become sort of a superhighway; they are the roads most traveled by the highest number of users. Usually, these roads are the best documented, too – they’re mapped. And when these superhighways inevitably shift and change to accommodate changes in user behavior and the tech landscape in general, these changes are the talk of the community. These are signs along the journey, alerting developers in the WordPress and Drupal communities that our travel plans will soon need to evolve.
Some may argue that these common pathways are boring, or aren’t “innovative”. But decades of experience in software development for nonprofits has shown us that, paradoxically, the stability of these superhighways fosters innovation. Codebases that are bespoke and fragile cut themselves off from future enhancements and integrations. While the road less traveled may seem more exciting, where it leads is less known, less tested, less documented, and less secure. If you’re working in an environment where you need to make the best use of limited resources, then the superhighway makes for a less risky and more collaborative journey.
When to Go “Off-Road”
Part of the appeal of open source software is its freedom! Unhindered by proprietary licenses, anyone can write custom code to alter the way an open source tool works. This is fantastic, but with great power comes great responsibility.
The more bespoke your website becomes, the more it requires highly specialized knowledge for maintenance. The developer who writes the custom code to solve a problem today may not be the one maintaining your website three years from now. They may pull in extra code libraries from outside of WordPress or Drupal that will incur additional technical debt. All of this can make your site more fragile and brittle. This can increase costs of maintenance and enhancements over the long term, and can greatly reduce the shelf-life of your website.
There are great use cases for custom code! A good developer will carefully vet a scenario to determine whether custom code is the best solution. Custom code for resource-constrained nonprofit websites is best when it avoids requiring the addition of large, complex external libraries for simple tasks.
As much as possible, it’s also important for Drupal and WordPress developers to write custom code to WordPress and Drupal community standards, and to document their code so that other developers (or, future-them!) will understand what that code is doing, and why.
If the custom code is solving a problem that other organizations also have, then a developer may opt to contribute that custom code they wrote for your site back to the Drupal or WordPress superhighway. And that’s where the open source community model really shines.
The Benefits of Traveling in Community
When code is too custom, and is kept private, we all miss out on the benefits of the community that comes with open source: the extra eyeballs, the extra brains, and the collaboration and iteration.
Nonprofits know the power of collaboration. Staying in community allows many more to benefit from the hard work of nonprofit tech. This is why, whenever possible, we opt for using and contributing to the superhighway over the thrill of the path less traveled.
Leave a comment