How and why Los Angeles deployed open source and agile

Last week at DrupalCon, representatives from the city of Los Angeles, CivicActions and Acquia shared their development and project management process to begin migrating and consolidating websites across 40 agencies to a single instance using Acquia Cloud Site Factory.

The teams shared how they moved to the open source content management system Drupal, created a responsive web design theme, developed key features and integrated other services such as video and data.

The first sites included in the consolidation plan are lacity.org and lacityview.org.

The presentation also includes a retrospective on goals achieved, areas of improvement and lessons learned. The city’s LA team adopted agile development practices and, based on the success of the project, has been asked to train other agencies.

Project management and development tools used include SMACSS, Slack, Basecamp, GitHub, Google Hangouts and Jira.


White House opens huge opportunity for designers, developers to increase We the People engagement

Photo: Pete Souza/White House

Photo: Pete Souza/White House

The White House will soon open a limited beta test to developers on a new We the People Write API that allows third-party applications to submit information to official petitions.

“One of the things we’ve heard from the beginning is a strong desire from our users to be able to submit signatures and petitions from other sites — and still receive an official response. Up to this point, we haven’t had a way to accept signatures submitted from other sites, but that is about to change,” writes White House Associate Director of Online Engagement for the Office of Digital Strategy Ezra Mechaber.

According to the White House, more than 10 million users have signed nearly 300,000 petitions.

We the People was built in Drupal and the source code is available on GitHub.

The Read API was opened earlier this year (sample projects here).

While We the People is fairly intuitive and easy to use, there’s huge potential for great designers and developers to essentially build a truly innovative and engaging platform.

Apply to the We the People Write API Beta.

How Joomla is powering government

JoomlaWe’ve heard a lot about Drupal and WordPress in government, but not much about the open source platform Joomla. We asked Joomla External Communications Lead Sandra Ordonez to share how government is using it, its key features, how it compares to Drupal and WordPress and what governments are using it.

What is Joomla and why should government be interested?

Joomla is one of the world’s most popular open source CMS and its core product is free. It is used by individuals, small and medium-sized business, and large organizations worldwide, to easily create and build a variety of websites and Web-enabled applications. Approximately 2.7 percent of the Web currently runs on Joomla. Due to its power and elegance, it can be used by the most inexperienced website builder to the most seasoned Web developer. Since its inception in 2005, Joomla has been 100 percent community owned and operated, and its software has been downloaded more than 26 million times.

Joomla powers more than 2,900 government websites and you can find examples of those by going to http://docs.joomla.org/Government_Websites_Using_Joomla. We find that a majority of these government sites use Joomla because it is the only content management system that combines the ease of use and powerful extensibility necessary to meet the needs of a broad spectrum of users.

How does Joomla compare to other open source software options like Drupal or WordPress?

Whereas Joomla’s main competitors lack either ease of use or extensibility, Joomla takes the best of both worlds in one powerful and simple CMS. It is a product oriented community whereas other CMS’ are services oriented. What this means is that Joomla users expect the core and extensions to be finished products ready to use out of the box, and don’t require custom development to get ready. Many Joomla sites are deployed with little or no custom development work.

Another key differentiator for Joomla is the project’s focus surrounding security, a priority set by the leadership team. Joomla developers are focused on, and excel at, protecting their users. In fact, Joomla has set up the Joomla security center and strike team http://developer.joomla.org/security.html where security vulnerabilities can be reported on and taken action on instantly. The Joomla Security Strike Team pulls information from the thousands of people in the Joomla community working 24-7 around the world. Those members of the community are constantly probing Joomla and its extensions for the latest vulnerabilities and issues fixes to them as soon as possible. In addition to this specific security site and team, the nearly 500-thousand members in the Joomla forum are constantly informing Joomla members about the latest vulnerabilities as well.

What makes Joomla truly unique is it features the largest community of developers and third party extensions for a CMS (see more details below). The project is entirely community driven and operated with very little hierarchy, no questions asked. Joomla was developed as and continues to be a grassroots software project.

What are the top features governments are using?

It’s hard to pinpoint the top features that governments are using, but here are some of the “killer” Joomla features in our opinion (in no particular order):

  • Easy, one-click updates from version-to-version. The new built-in updater also handles updates for Joomla and Joomla extensions. This is a major enhancement improving upon the previous system of manually updating individual files on the server.
  • Access Control Levels. This gives sites managers control over who can manage and view content.
  • Multilingual capabilities allows site users to implement a multi-language site.
  • A separated framework for building apps (the Joomla platform). This means that a developer can use Joomla to build apps without having to make changes to the core CMS.
  • Huge, active community with over 8000 contributed addons better knows as extensions. You can find these extensions at http://extensions.joomla.org/.

How can interested public sector IT professionals learn more?

Go to www.joomla.org. They can also visit the Joomla! forum and get advice from one of our many volunteers: http://forum.joomla.org. Also, many tutorials exist on YouTube.

Local governments using Joomla

Learn more about government sites powered by Joomla at joomla.org at joomlagov.info.

Georgia.gov has Drupal on its mind

The next iteration of Georgia.gov will be built using the open source platform Drupal.

Phase2 Technology announced it was awarded a contract to replace, migrate and support an overhaul of the state’s website and content management system, which will be developed using Phase2’s Drupal distribution OpenPublic. The company will partner with Acquia and Mediacurrent to transition the current site from the Vignette CMS to Drupal.

“We are excited about the possibilities that Drupal brings to the state of Georgia,” said Georgia Chief Information Officer Calvin Rhodes. “This new platform will give us the flexibility to offer more online services to Georgians while making government more efficient and saving taxpayers money.”

Using Drupal as a prototyping tool

I was really happy to have Patrick Lajeunesse present about Agriculture Canada’s experience using Drupal as a prototyping tool. As you can see from his presentation, with a small team of communications staff they were able to set up both a Drupal and WordPress prototype to explore their needed functionality.

I wanted to focus a bit more on why this makes so much sense for so many organizations, but especially government agencies. The implementation of web tools has improved significantly over the last decade and it is no longer something that needs to be left to IT to model.

Defining the requirements is hard

Most folks who need a website haven’t had recent experience building them. It’s relatively easy to visualize what you want, but it’s quite different to be able to define it in a generic way that allows a developer to understand the technical functionality that is required. Often the usability/design requirements are barely defined in the initial proposal.

Websites can be very complicated. If you were defining the requirements for a car would you want to have paid for most of it’s creation before you could sit behind the wheel and see how it felt to drive around the lot?

Wish lists vs requirements

Without having an experienced project manager who has successfully lead a team through developing for the web, you’re likely to end up with a requirements document that largely contains people’s wish lists. It’s really great to have a list of potentials, but having a list of neat things that people find on other sites isn’t going to get your organization what they need.

It’s always easier for folks to focus on the glossy design elements that they’ve seen in other sites. I’ve seen way too many RFP‘s where people have talked generally about wanting many of the features that popular sites like Facebook and YouTube have without understanding the costs and complexity of successfully implementing it.

Taking a long time to define the requirements first is problematic

I think that When Failure Is Intolerable is right on when describing a very frustrating form of failure to be “when someone spent a lot of time and money researching something that could only be learned experientially.”

Many web projects fit this mould. Successful websites are always ones which are experimental and are reacting to the needs of its users after carefully watching their behaviour. Strangely, most web projects do not allow space for experimentation & adaptation.

Needs change faster than requirements

A good requirements document does take some time to establish, particularly if it is being developed by a team. Even if there are other models to work from, it can take quite a while in any government department to settle on the final requirements. After that it needs to be sent off to procurement officers to manage the contracting before any real work begins on the site.

The Internet is constantly changing. Most people’s expectations don’t change quite so quickly, but you don’t want to be launching a website a website which already looks and feels dated. Accommodating social media sites like Twitter and Facebook is the latest trend, but these sites are changing too.

Prototypes are better than wireframes

Having a rough stage where workflow is defined and broad paths are sketched out is very important for any large project, however there is nothing that can replace a quick, functional prototype for users to determine how they want it to work.

Given the flexibility of Drupal and the range of modules and themes that are already out there for this free software platform, most of a site’s functionality can be roughed out quickly to enable people the ability to get some understanding of how the site will work.

Most people need to be able to get a feel for what they are going to build before they commit to do it. In an age where non-architects can download a tool like Google’s SketchUp and create a 3D model of their cottage before building it, we can see the value of visualizing a plan.

Creating content is hard!

This won’t come as a surprise to communications folks, but producing content is difficult. Understanding how your content will fit within the structure of your site is important. No amount of time whiteboarding your site, developing requirements documents or wireframing your site will help prepare the content.

However, building a solid prototype will allow you to write up, critique and visualize how you want your visitors to actually use your site. You can experiment placement and organization of real content that you will be able to use to help your site go live as quickly as possible. We do know that some people still use Word documents to generate the content of their websites before it’s launched, but that’s really a waste of everyone’s time.

Patrick describes how his team in Agriculture Canada used this approach:

“One of the benefits to prototyping in Drupal for us was that we can put real content in and see how it flows from page to page. It also allowed us to use the prototype to do usability testing on that content. For example, you can have a test subject try to find a piece of information. This tests the whole site – the navigation and IA, link and button labels, and the actual content in the pages as well. That would be very difficult to do without a real representation of what the finished site would be, and while you could do that with static HTML or a dedicated prototyping tool, it’s just easier with a CMS like Drupal.”

To try to pull in another metaphor, it’s real estate agents generally will want to show a house that has furniture in it and art on the walls rather than one that’s completely empty. They do this because it’s much easier for everyone to understand how a house will function if you don’t have to imagine everything. The same idea applies to websites, most people need to see where the content fits & flows when they are navigating a site.

Prototyping doesn’t require IT support

Organizations may find that their communications teams have the skills required to set up Drupal or WordPress site to build a prototype before they take it to IT or send it out as an RFP.

Prototypes can be easy to set up. Using tools like Drupal, you can experiment with what you would like and work with your team to define what else you need. Open source tools like Drupal can empower communications teams to define and experiment with technology which is available to them (it can be set up on any desktop and doesn’t require special hardware or expensive software to run).

At the end of the prototyping phase a working example can be either handed over to IT to review before it goes live or used as a benchmark for them to develop in whatever technology they prefer. The communications team would also be left with a development environment which allows them to test out future phases or ideas for the site.

This approach would no doubt increase the effectiveness of any large web development projects.

Lockheed goes open source. Blankenhorn hates it.

I was really pleased to read the announcement that Lockheed Martin's social networking platform, EurekaStreams, was released as an open source project today. Lockheed is a very conservative company, and while they're happy to use open source internally and on projects for their customers, this is their first experiment with actually running a project themselves. I think it's a big deal, not just for Lockheed Martin, but for large corporations who are considering a more open, more innovative approach to software development. And yet, Dana Blankenhorn hates it:

I don’t see anything in Eureka Streams I can’t do in Drupal, or a number of other high-quality open source projects that have existed for years. Lockheed has reinvented the wheel — why?

So here's the nice thing about the open source community: competition. If I think I've come up with a better way to solve a problem, it can easily compete with the incumbents. Low barrier to entry, we say. Let the best ideas win. Unless, apparently, the best ideas come from a company I don't like.

Then things start going sideways:

The author of Eureka Streams, who goes by the name Sterlecki at Github, has left no previous tracks there. Linkedin lists the same picture as belonging to Steve Terlecki, a Lockheed software developer.

The stuff’s legit, so we’re left again with the question of motive. Is the military-industrial complex reaching out to open source, is this just proof of press reports showing our spy efforts have more bloat in them than a Macy’s Thanksgiving float, are we being co-opted, or am I just too suspicious?

Wait, what? Open source advocates have, for years, been trying to encourage more code to come out from behind corporate skirts. Where companies can build business models around governing and supporting open source projects, we want them to take the plunge. If more code is open, that makes everyone smarter. And that, my friends, is exactly what Lockheed Martin did today. Someone who probably never contributed code in their lives just gave the community a project they've been working on for months, or even years. I think that's amazing. In return, this brave developer gets painted as a nefarious secret agent out to steal our thoughts and bug our laptops. Or whatever.

So here's the great thing about open source: we can prove Blankenhorn wrong. They use the Apache license, and it's on Github. We can go through the code and find backdoors, secret plans, and mind-control rays. This reminds me very much of the reaction to the release of SELinux. Conspiracy theories everywhere, but code is auditable and now it's in the mainstream Linux kernel. Do we really want to throw out these contributions, when code doesn't lie? When it's so easy to ensure there's nothing nefarious inside?

You can feel however you like about Lockheed Martin or the US Department of Defense. You can choose to contribute to the project, or not. You can choose to use the software, or not. But is it in the community's interest to summarily dismiss contributions based on those preferences? Lockheed's thousands of developers are sending up a trial balloon. If they fail, we lose access to those developers forever.

I think this kind of fearmongering is exactly what prevents large corporations and government agencies from releasing their code. These knee-jerk reactions harm the open source community at large. We pride ourselves on our meritocracy. A 14-year-old in his mom's basement is the same as a 30-year-old Lockheed developer is the same as a UNIX graybeard. You are just as good as your contributions. We need to welcome Lockheed's contributions, not throw them back in their face. Whether the project is useful or not, they've enriched the open source community. Let them succeed or fail on their own merits. If they do fail, we hope that they'll do better next time. Maybe this is a Drupal-killer. Who knows? Let's give it a try.

A new model for public sector open source adoption using Drupal

The debate over whether (OSS) is good for government is over. A close look will reveal the discussion has moved on to one of two things: 1) the necessary, but subsequent implementation questions to be sorted out – security, regulation, procurement, etc. or 2) organizational confusion about how to take the first step. In either case, the precedent of value has been established both within government and elsewhere to allow us to now move on to the natural next set of issues.

Open source software is here to stay

So the discussion must turn from ‘whether to use’ open source to ‘how to make it work’ for government. These discussions should be especially welcome in the government IT environment – long dominated by IT projects that take too long, cost too much, and never seem to hit the mark by the time they are deployed. Corporate and non-profit organizations of all sizes have been able to demonstrate significant financial, operational and strategic value using open source. Also, we have the precedent and models set by the server stack – Linux has become the dominant operating system and Apache, the webserver for the majority of the world’s most important web servers.

The problem is that taking advantage of the open source opportunity at the application level creates paradoxes for government IT. Our system doesn’t know how to take advantage of free and open software at the application level – government is used to building everything custom or customizing products that already cost a ton to license – ‘there is a catch here somewhere for us’ goes the thinking about OSS.

Rather than move quickly to take advantage of affordable and innovative open solutions, government loses momentum and gets bogged down by concerns over whether it is practical or even ethical to use contributed code: Can we use something that is free? How can we procure it then? Can we use code contributions from the outside world? Will it be secure? Can we contribute our own code to the rest of the world?

Drupal works for open government needs

As if the argument to adopt open source needed more kindling, enter the administration’s unrelenting push for Open Government – with a huge online focus and component. Now we are seeking *new* ways to quickly establish mechanisms to promote transparency, participation, and collaboration in online dealings between the government and its citizens. Yet successful user collaboration solutions are already implemented on all kinds of sites.

The case for free, collaborative software which is developed, tested and vetted in the open by an efficient base of innovative developers has been clearly made when you consider the the open government mandate. These are use-cases made for a platform like Drupal – the ability for a user to respond to content and policy online through commenting, rating, sharing, voting, and an endless array of other social media integration is perfect.

As I have said in prior posts on this site “Drupal is up to this challenge”. This is what we use it for and where it performs best. At this week’s Gov2.0 Expo, a group of my colleagues will try to convince you of this point in a session entitled Drupal and Social Publishing Strategies for Meeting the Open Government Directive.

I realize that is going to take some time for government CIOs and web managers to be fully convinced – as it did with publishers, non-profit execs, education administrators and decision makers in dozens of other industries. For sure, the commercial vendors and embedded custom implementers have other ideas about how to construct the next wave of gov2.0 – and they likely have some good solutions to promote too. But open source Drupal is my choice for this particular set of tasks and here is what I think we can do to help prove that.

We need a government community open source CMS option

In late 2008, my company, Phase2 Technology initiated an effort to put together and then release an open source packaged version of Drupal that would help online publishers of news, magazines, and other publications get started with Drupal right away. We called it OpenPublish, it was a big success, and it is going stronger than ever now. From that project, we learned that Drupal can be made significantly more useful, less intimidating and more powerful through a distribution targeted at a specific set of industry challenges.

So after wrestling with putting government sites on Drupal over the last two years, we have decided to launch a similar project we think will help government and Drupal find each other faster – in the same sort of way as OpenPublish was able to married up publishers looking for the advantages of open source with Drupal. We are calling this project OpenPublic because of the similarities and because we see it as the public sector equivalent of the same experiment.

We believe the project can be successful and provide substantial value to government sites if we can achieve these 7 tenets that are lacking in current CMS options for government:

1. Low barriers to entry.

Someone from, or on behalf of, the government should have the immediate ability to start or prototype a project without an RFP, procurement cycle, Statement of Work or contract vehicle. Download, test, try out and play with it for free. Today. No strings attached.

2. Demonstrable return on investment.

It should be easy to prove that that the tax payer is getting high value for services, without wasteful scenarios in which the government is putting large investments directly into reinventing functionality that exists elsewhere or overpaying for commercial licenses to use relatively generic functionality (e.g. core CMS publishing).

3. No proprietary technology or vendor lock-in.

The solution can’t trap the federal government into a proprietary technology or forced monopoly experience that either requires repeated contractual awards, recurring fees or licensing costs to a single company that is the sole provider of technology expertise.

4. Low total cost of ownership.

It should be easy to prove if agencies are paying a premium over the course of ownership via post-purchase fees that do not involve the delivery of additional value. The government cannot grant annuities to vendors that continue to add cost based upon the justifications that were created because proprietary technology was used.

5. True technical flexibility.

The government must be able to modify the solution to meet continually evolving needs and be able to improve, modify, maintain and grow the solution over time.

6. Community innovation & contribution.

The government should benefit from the continued contributions of the open source technical community at large as it relates to inheriting solutions to similar problems and . It should gain from the innovations of this larger pool of talent.

7. Minimal barriers to extend.

The government should have the ability to get free and open access to knowledge, code, training and best practices on the platform – to the extent that others are willing to share – but not required to withhold.

OpenPublic: A community solution

OpenPublic is being developed as a community effort with Phase2 taking what we have learned from building Drupal distributions to lead the efforts, but we – by no means – want to go at this alone. In fact, we believe the quality of the solution and the value it can provide are both infinitely improved by community participation.

So we are looking for both people with technical experience in open source (Drupal preferably) and the business of government itself.

We are also actively looking for feedback and help from the opengov community that haunts events like the Open Government Workshops, the Gov2.0 Summit and Expo, the Open Government & Innovations conference and Transparency Camp. We are looking for the people that hang out and read GovFresh, GovLoop and the Sunlight Labs blog. We want the inputs of people on the Gov2.0 Heroes List and on Twitter lists like this, this and this.

If you believe in the same things and want to help, then please email us (openpublic at phase2technology.com) to let us know of your interests and share your ideas.

USAspending.gov 2.0 gets its money’s worth

Version 2.0 of USAspending.gov launched this week and includes a cleaner, more elegant user interface and search filtering on all federal government spending. The new site was developed in Drupal and is partially hosted on NASA’s Nebula cloud service.

Users can search anything from bombs to toilet paper and filter government spending by location, timeline, agency, extent competed, recipient, product/service code, NAICS and fiscal year.

USAspending.gov first launched December 2007 as part of the Federal Funding Accountability and Transparency Act (FFATA) of 2006 that required the Office of Management and Budget to ‘establish a single searchable website, accessible to the public at no cost’ on all federal government spending.

From USAspending.gov What’s New in 2.0?:

  1. Compare spending across agencies – understand types of agency spending understand types of agency spending
  2. View agency spending dashboards – see how and where agencies are spending money and who the recipients are
  3. Explore spending trends with interactive charts – use interactive motion charts to see how spending trends have changed from year to year
  4. See spending where you live – use interactive maps to see dollars being spent in your state
  5. Quickly find what you are looking for – use interactive search features to customize your search across multiple dimensions
  6. Filter, analyze and share – share your feeds, exports and results with friends via social book-marking and RSS feeds
  7. Analyze contract and award transactions – review all transactions for a single contract or award in one simple list
  8. Download bulk data – download all spending data for offline analysis
  9. Get spending updates every day – access new spending data on a daily basis
  10. Expect more transparency – look for more spending data in the future as 2.0 is engineered to support full FFATA compliance