OpenPublic has gone through a fast Beta 9 (some build process problems) and a quick Beta 10 and 11 recently. Although these smaller, faster releases are great, the team wanted to take the time to reflect on the time between Beta 8 and 9, one of the longest periods between releases for OpenPublic. During Beta 9, the distribution was under more active development than ever before. We still have work to do, but this latest iteration was focused on hard-fought improvements to make OpenPublic better for it’s core purpose: building public sector sites.

We and others have built many sites on OpenPublic. Although OpenPublic is a huge leg up on development and is designed to be a great working site right out of the box, balancing the priorities of being an out-of-the-box product and a reasonable starting point for development is difficult. For example, the feature that provides demo content also needs to be easy to disable. The building blocks for custom calendar functionality can’t get in the way of people expecting all features to be complete (or get in the way of the developers who want to build an entirely different feature). In short, every convenience to a site builder is potentially a thing that can ruin a developer’s day (or worse) and vice-versa.

For the Beta 11 release of OpenPublic we took a big step back and focused entirely on the process of building sites with the distribution (see the release notes for Beta 10). To do this, we set up project teams not just to build regular sites, but platforms for building many, many sites–including highly custom specialty sites. This included about 50 agency sites and the unique GeorgiaGov as well as builds off a shared platform for the Department of Homeland Security: Ready.gov, FEMA.gov, and DHS.gov. We used multiple teams, ensuring that not just Phase2 developers familiar with OpenPublic were doing the work. I lovingly refer to these sites as OpenPublic++; they started as OpenPublic, but are wholly specific to their organization’s needs and took thousands of hours of design and development to be created.

The result of this process is the latest release of OpenPublic: It represents the feedback from those teams and those projects. There is always more work to do, but I’m proud of OpenPublic’s continued focus and commitment to being one of the best Drupal Distributions to build a custom site with, while retaining that out-of-box-ness that works for so many sites. We intend to stay focused on site building and continue refining the build experience for OpenPublic. That said, we are putting some features on our road map for the distribution itself, not just through apps.

 

A quick caveat: building a product roadmap for a distribution with dozens of contributed modules, a partner distribution, and a radically changing domain, the public sector, is important but also constantly shifting sand: don’t read timeline or order into this.

Our recent projects convinced us that OpenPublic has some core needs we could safely address without bloating the distribution:

  • Better back-end asset handling for content creators, namely making it easier to link (offsite), reference (onsite), or embed (either) content and multiple pieces of content everywhere
  • General structures (read “content types and field collections”) for grouping things: the public sector has lots of evergreen content, and creating groups or libraries of it–outside a menu–increases visitor discoverability and editor maintainability.
  • More promotion opportunities for evergreen content. OpenPublic already has multiple rotators and Editor’s Choice, but we’ve also got the core for boxes in the distribution, and we hope to show off how it can be used better

In addition, we’ve built a lot of custom functionality for sites using apps, and will continue to try to make marquee features optional for the distribution via that mechanism. We will not lose focus on keeping OpenPublic lean and mean, so anything we can move into an application, we will.

Of course, as OpenPublic is primarily for public sector sites, we’ll keep working on increasing accessibility, building security, and fixing bugs. If you’re interested in contributing, there are three things we can always use help with from the community after you download the distribution:

  • * Patch a module: Whether it’s a bug you fix or a feature you want, it helps the module maintainers and the distribution
  • Build a theme: Themes are important, and with OpenOmega in the distribution you have a great starting point to sub-theme from and contribute. If you have a good general theme based on Omega for OpenPublic, let us know, we’d love to help publicize it
  • Build an app: Many folks in the Drupal community have been using the app server the same as us, so it’s a general skill, and we’ve been making many improvements to make it easier to build apps
  • Thank you, in advance, for helping make Drupal better and making OpenPublic a great resource for the public sector. OpenPublic has come a long way thanks to the community, and we have a bright future ahead of us.