Notes from BADCamp 2015 Nonprofit Summit

It's that time of year again, when Drupal developers from far and wide come to take advantage of the lingering California summer and revel in Drupal nirvana at the Bay Area Drupal Camp (aka "BADCamp").

Since all of our founders worked with nonprofit groups before kindling the flame of Kalamuna, the BADCamp Nonprofit Summit is a favorite. We've been proud to host the BADCamp organizing sessions in our office for the last two years, and seeing the summit being formed from scattered conversations to a world-class gathering of nonprofit organizations is thrilling. Here are some insights from the conversations we participated in at the summit.

Web Strategy Choices for Smaller Nonprofits

Daniel from Giant Rabit believes that, in making technology decisions, your guiding principal should be to use software "for what it's for." Find the raison d'etre behind software. Don't be afraid of data silos: it's usually better to use another tool than to try to stretch one tool (like Drupal) to fulfill all your needs.

Challenges of a Small Nonprofit

Small organizations have big eyes. They need the same things as large organizations, but have a fraction of the resources. Clearly some prioritization of options is necessary. Focus on tools that are not only practical for your budget, but your available time and skill level as well.

"Content First" and Personas: Useful Strategies for Technology Decisions

In the context of a website, one way to get traction on the project and force certain decisions is by creating content first. This helps all stakeholders see the reality of the web project before major technology investments need to be made.

Personas were also mentioned as an effective tool for deciding priorities. Personas create an imaginary amalgam of various stakeholder's needs; for example, a food justice organization might have a stakeholder of "Fred Foodie," an affluent, middle-aged, highly educated professional who loves locally grown foods and cuisine. Various tech decisions can be framed around these personas: would Fred rather interact with our organization on a self-hosted social platform, or on Twitter, where he's already active?

Conclusions

Technology decisions should be democratized. Anyone can evaluate technology; there is no magic, the most important thing is to dive-in, actually use the software as a trial, and keep in mind the real needs of your organization.

Decoupled Drupal Break-out Session

"Decoupled" architecture sees Drupal providing "content as a service" via APIs to other systems which are in charge of displaying the content instead of Drupal's default theming system. As Dustin from Four Kitchens puts it, "Drupal has spent 14+ years dealing with content...but the front-end can be lacking." Let Drupal focus on what it's good at and choose the ideal front-end technology to resolve this conflict.

Saucier: A Decoupled Solution from Four Kitchens

Dustin and Jeff from Four Kitchens described a solution they made for client TWiT.tv. When they first started working with TWiT, many users were scraping the TWiT site to use their info. Using the RESTful Drupal module, Four Kitchens was able to quickly create clean APIs for consumption.

For front-end presentation, Four Kitchens created Saucier. Instead of thinking of the front-end from an "app-y" perspective, they wanted to make sure that web users were thought of as first-class citizens. Hence the decision to not rely on a JS-driven solution (like Angular or React) and instead use Dust.js, a dynamic templating system which renders templates with content as static HTML files.

Advantages of Decoupled Architectures

Session participants noted several potential strengths and promises of decoupled architecture:

• Four Kitchens noted that it helps escape Drupal's "cul desac" of technology, allowing devs to experiment with other tech
• Ryan from the Corning Museum of Glass noted that having separate development cycles for front/back-end could lead to less pressure for finding specialists and certain points
• Kalamuna's Alec Reynolds noted that decoupled solutions can be good for high-security scenarios (HIPAA compliance in particular), so a design-focused firm can create an entire web experience while letting security specialists define a secure API that handles data storage, authentication, and authorization

Disadvantages of Decoupled Architectures

• Upgrading multiple technologies and keeping them in-sync can become more difficult
• Supporting multiple technologies presents similar challenges
• Content editors may need to accept less direct control (this can have some advantages as well)

Useful Tools for Decoupled Projects

• Apiary.io: Both Four Kitchens and Kalamuna have used this for API design
• RESTful 2.0: Will extend upon success of the RESTful module and add HATEOS support