The Evolution of an Open Source Company

The advantages of becoming part of an open source community and contributing back to it.

It's hard to believe, but it's only been about two years since Palantir launched its first Drupal website for the University of Washington in St. Louis. Since that time, we've built dozens of sites using Drupal, and adopting it as our preferred platform for content management and web application development has led to a lot of positive changes for our company.

Dries Buytaert, the creator of Drupal, recently noted on his blog that he was surprised at how many companies don't contribute back to Drupal or participate in the Drupal community because they haven't figured out how to make it work for them financially. While I can't speak for the experience other firms might have had, I can say that at Palantir, we've found that becoming part of the Drupal community and contributing back to it has been not only been good for business, but it's allowed us to grow in a way that wasn't possible before we became a fully "open source" company.

Since we started back in 1996, we've always worked with free and open source technologies like Perl, PHP, MySQL, Linux, and Apache. These technologies are distributed under a license that allows users the ability to view the source code and change it as needed. Not only do they lack the expensive licensing fees and restrictions of their proprietary counterparts, but we've found that they're generally more flexible, robust and secure as well.

We first started seriously looking at Web content management solutions in the late 1990s; at the time there were a few free and open source options, such as PHP-Nuke and OpenACS, but none of them satisfactorily met either our needs or those of our clients. So, like many other companies at the time, we decided to create our own custom content management system, which we called the Community Platform. While the Community Platform wasn't technically open source, it was built using an open source language (PHP) and our clients had the right to modify its source code as desired.

The primary reason that we didn't release the Community Platform under a free or open source license is that we wanted to protect our "intellectual property", which we mistakenly believed was encapsulated in the code that we had written. In reality, our clients come to us because they're looking for someone who can help them solve their business problems, and they have little or no interest in the specifics of the code that we've written (if they did, they probably would have already written it themselves). Palantir's intellectual capital is the experience and expertise in problem-solving that we bring to the table, not a series of functions or template files.

The Community Platform started out as a loose conglomeration of PHP scripts held together by a single administrative interface. These scripts were often modified and updated for reach project that we worked on, meaning that each site had an almost completely custom technical architecture. The advantage of this approach was that we were able to quickly and easily develop solutions that met the specific business needs of the project we were working on at the time; the disadvantage was that it was often very difficult to maintain or extend the functionality of a site once it had been developed, and each project brought with it a large support burden. Subsequent rewrites of the Community Platform brought more structure to the system, but at the expense of flexibility both on the front and back end. By the end of 2006, it was becoming increasingly obvious that our days of working with a custom CMS platform were numbered.

We've also worked with a few well-known proprietary CMS platforms, but none of them have been very satisfying for us either. First, they require upfront licensing costs that typically run into the tens and even hundreds of thousands of dollars, meaning that the client has less money to spend on the actual development of their site. Second, we've found that many of these proprietary platforms are badly written and full of bugs, but the vendors are either unwilling or unable to fix them, and we can't do it ourselves because we don't have access to the software's source code.

In the spring of 2006, we were hired by Arts & Sciences at Washington University to do an evaluation of leading CMS products in the marketplace, as well as our own custom solution. It became clear very quickly that a free and open source solution was going to be the best fit for them. Of all the leading open source content management products, Drupal was the only one that offered the kind of functionality that their project needed. Our biggest concern was that Drupal might not have the flexibility we wanted for the front-end design, but those fears were soon proved false. The success of that project, combined with the release of Drupal 5 at the beginning of 2007 prompted our decision to move our focus away from the Community Platform to Drupal.

Adopting Drupal has had a number of profound positive effects on our development environment. Functionality that previously took dozens of hours of custom coding to develop is now immediately available via contributed modules, allowing us to more quickly build out functional prototypes that can be used to test and refine site features before everything is set in stone. Implementing sophisticated designs in HTML/CSS does take a little more time, but by adopting sustainable theming practices, we're able to create themes that are not only of higher quality, but are more flexible than just using custom HTML and CSS.

I sometimes get asked, "But how can you make money in open source development if you're always giving away your work?" First, we do not give away our work: we are compensated for every hour we spend developing new Drupal functionality for one of our clients. We are very upfront with them that while we will always keep their proprietary business information and methods confidential, we may end up releasing some of the code that we develop for their site into the community, assuming it's something that other folks would benefit from as well. By doing so, Palantir not only helps make Drupal better, but we also derive benefits from other people reviewing and extending something that we've written.

Releasing modules that we've written into the community and talking about the projects that we've worked on is also really great PR for Palantir, not just for potential clients, but for potential employees as well. Before adopting Drupal, it was sometimes difficult for us to immediately identify top-notch developers, especially PHP programmers, because of the tremendous range of experience and expertise in the field. Now, however, if a job applicant comes to us from the Drupal community, we can see what modules they've written or other contributions they've made to the community, allowing us to get to know them a little bit better than we would just from bringing them in for a couple interviews and reading their resumes.

Adopting Drupal has improved job satisfaction because we no longer have to re-invent the wheel every time we work on a new project, and we're no longer working in a vacuum. If we run into a challenge on a project, chances are that someone else in the Drupal community has run into that challenge before and either found a solution or come to the conclusion that a new module needs to be written to solve it. Either way, we can take advantage of the community's knowledge and experience, and avoid having to bang our heads against the wall. And if we're the ones who find a solution to a particularly thorny Drupal problem, we make sure to let other folks know as well, so they don't run into a roadblock when it comes up for them.

Another advantage that Drupal has over a custom solution is the emerging commercial infrastructure that supports it. As folks who are primarily involved in the strategy, architecture, development, and deployment phases of a project, we don't provide 24/7 support services. And although we've found that the support burden for Drupal sites is far less than that of any other product we've worked with, some of our clients still want to have someone they can call at 3am if they're having a problem with their site, which is where companies like Acquia come into the picture.

While there's probably at least a dozen more ways that working with Drupal and interacting with the community has been good for business at Palantir, the most important thing is that it allows us to focus on our core mission, which is to build great sites and Web-based applications in a way that's both personally and professionally fulfilling.

Thanks, Drupal, and best wishes for even more growth and success in 2009!