The open source path can be a delightful and cost-effective way to go for a web-based project. However, if you don't understand the primary dos and don'ts of open source, a "free" open source website can quickly become a costly and difficult bear to manage.
As open source software becomes more popular and more relevant to the needs of non-tech-minded people and organizations, we thought we'd offer some basic background on how to use -- and not to use -- open source for a web platform.
Read on....
<!--break-->
It's a business methodology, not a religion
Forget the image of programming idealists spending their days and nights writing code to give away. The open source world is a rich and vibrant area of the economy -- and it's growing. Opting for free open source software like Drupal is a business decision, with clear and definable benefits and costs. On balance, as a business methodology, open source has its definite advantages.
On the upside:
- You own the code (under the GPL).
- It's free.
- You're free -- free to change the code, free to add new features, free to have anyone come in and do these things for you.
What comes with this is responsibility. You own the code running your site, so you're responsible for its upkeep. While you don't need to pay any licensing fees for proprietary software, you also don't have a proprietary software vendor maintaining that code for you, meaning you need to maintain the site yourself, or have someone do it for you.
Even if you don't plan to implement new features, you will want to plan for periodic security updates. (All software goes through updates; open source is not excluded.)
What's truly wonderful about open source, though, is that you are not alone....
It's a community, not an application
Drupal, like most open source projects, is the living manifestation of the interests of hundreds of developers who are sharing and collaborating on code with each other in order to individually and collectively benefit from the synergistic result. You have thousands upon thousands of people working from the same code base, finding the same problems. When one developer fixes a problem, the entire community benefits.
The whole idea of going with an open source platform is not that there's free code to be taken, but rather there's a dynamic worldwide community of developers who are behind that platform, evolving it, growing it, and always improving the code base from which you can benefit for years to come.
What this means is that, while Drupal itself is a software application for content management on (primarily) websites, the smart business move is not to simply download the code and go your own way, but rather to join the caravan and participate in the community ... or at least pay attention and stay abreast of developments.
As a result, you get not just Drupal today but what Drupal will be tomorrow -- you get not just the (free) application, but also the (free) upgrades. You have the whole worldwide Drupal community developing modules and code upgrades and theming techniques for your code base, there for your use, but only if you're keeping apace.
And only if you....
Don't hack the core
When you hack the core -- that is, change the code in the system's foundational programming -- you create a "fork": a variant of the system that is now unique. While such hacking may be tempting -- after all, it can be a relatively easy way to change features and functionality (and you do own the code and have every right to hack to your heart's content) -- ultimately venturing down that path can end up being a very costly decision, namely because when you hack the core, you stand alone.
Open source is not just a static code ripe for the taking, but moreso a community that you join, participate in and benefit from. If you hack the core code, you effectively remove yourself from that community. You will be standing still -- alone -- while the rest of the community moves on.
In pragmatic terms, without a world full of developers familiar with your particular fork in the code, you will inevitably have to confront the reality of maintaining the code yourself. For every bug fix, every security update, every alteration, you will need to hire developers to do that for you (or do it yourself, if you have the expertise and time to spend on such endeavors).
There are ways to modify Drupal to do what you want, but hacking the core is not the right way.
This isn't to say that it is somehow "evil" to just take open source software and fork it to your own ends -- though there are some who would make just that assertion -- but rather than to do so has consequences that may not seem readily apparent at first.
Think of it this way....
It's a vector, not a point
In other words, open source projects move. They don't stand still. Drupal today is different than what Drupal was a month ago. Drupal from a year ago would be almost unrecognizable to users of Drupal today. That is because Drupal -- and open source projects in general -- continues to evolve and improve.
Open Source Development in Motion: This diagram is an illustration of how Open Source development keeps moving. Visualize the (mostly) blue diamond as moving through time (here, from left to right). The "release" points are static: largely unchanging snapshots of the evolving code base.
The diagram above illustrates this. Think of the blue diamond area as the amount of developer activity on a project. The amount of worldwide activity increases as the community gets close to a new release. Once a release is out, development continues for a while, but then starts to taper off as the next latest and greatest release is being prepared.
As each release is replaced by newer releases, developer attention starts to shift towards the newer stuff. When that happens, people using the older releases end up relying on code that is getting less and less attention, meaning not only fewer new modules, but also fewer bug fixes and less security attention ... until finally a release languishes without any community support at all. At that point, you're on your own....
...Unless you've kept up, doing at least periodic updates.
The good news is that updating can be pretty easy -- that is, as long as your site uses community modules and your code hasn't been hacked. (See above.)
But what if you want some new functionality for your website -- something that existing Drupal core and contributed modules don't handle the way you'd like, if at all? If you shouldn't hack the core, does that mean you can't customize Drupal?
Not at all....
Modularize and Override
Drupal core is an open, scalable CMS where new functionality can be added without hacking the core and creating a fork. You can create -- or have created for you -- custom modules to achieve the functionality you need and template overrides (along with CSS styling) to create the look and feel you desire for your particular web project.
So let's say you've created some great new custom module for your website. The natural temptation is to treat it as proprietary -- secret. After all, isn't that module that you paid money for what makes your site special?
Not really. And let me explain, because here's where we get into another important step in the business methodology of adopting open source....
Don't keep custom code secret
Take any open source web software platform out there, and look at the wide array of sites built on that platform. What you will see are a few sites that are going like gangbusters, quite a few others that are doing quite well, thank you very much, and a whole bunch of sites that are trundling along (--plus not a few failures, though odds are you won't even notice them).
Obviously the code itself doesn't make a site, otherwise they would all be equally successful. Your website is the content you create, the community you cultivate, the conversations you engage in. Otherwise all sites running Scoop would be succeeding the same way, all sites running Plone would be the same, and so on.
The code is to your website what a font is to a novel or a film stock is to a movie: a means to an end, but not the end itself. This isn't a matter of "religion" (as some old media and web 1.0 types will accuse) but rather a matter of economic decision. It's a choice to follow a path where the community provides the tools and you provide the content.
Because what you want for your website is attention.
As Michael H. Goldhaber explains:
One of the first such standardized manufactured goods was money itself (in the form of coins). Now, increasingly, money tracks attention. Those with a great deal of attention can easily obtain money, should they want it. Those with little attention will have a much harder time obtaining money.
Wandering Stan illustrates with this example:
- IBM sold you hardware in exchange for money.
- Microsoft sold software you software in exchange for money.
- Google gives you stuff for free, but sells your attention to advertisers.
In other words, the code itself is not the website. So why keep the code secret? Why not share that code and let the community help maintain it and improve it?
When you develop some custom code (or hire a company to do it for you), and you keep the code to yourself, you are starting down that path of forking, and the host of added pressures and responsibilities that come with that. (See above.)
It's worth asking yourself: Would it really hurt your site's business if you were to release that nifty custom module back to the community? Is it really that likely that someone else will take that custom module and then knock your business right off the Google map?
On the other hand, wouldn't it be nice if there were other developers out there fixing bugs, patching security holes and adding new features to that module -- all things from which your own site could benefit?
The bottom line is the bottom line
In summary, when it comes to the bottom line, how you use open source can bring great boon or costly snags to your web project. Remember:
- If you hack the core, it will cost you more in the end.
- If you don't update, it will cost you more in the end.
- If you keep your custom code secret, it will cost you more in the end.
- On the other hand, if you go with the flow, stick by the community and give back what you can, going the open source path can be a delightful journey.
It's a simple business decision, and well worth considering for anyone embarking upon (or upgrading) a web-based project.
]]>
Al Steffen joined us about a year ago, but never had the opportunity to travel to any of the Drupal events outside of the greater Denver area. In fact, I just learned today, he hasn't even seen a proper ocean. Some may know Al online as Zarabadoo, the handle he uses on IRC and Drupal.org. He's the man behind the nicely semantic Hunchbaque theme (ugly on the outside, beautiful on the inside).
John Fiala (jcfiala) joined us last summer not knowing anything about Drupal, and now he's one of our power developers, with a particular affection for databases. He's already made a mark in the Drupal community with contributions such as the Drupal Markup Engine, not to mention helping with the upgrade of nodequeue to Drupal 6. That's not all: one of our favorite in-house modules, Node Carousel, was developed by John, along with....
Greg Hines, who also will be a first-timer at a DrupalCon. Greg joined us just a few months ago by way of Ars Technica, which already is very cool, and now has become a key player in coding and theming, with a bit of JavaScript thrown in for good measure. (Greg is one of those guys who just "gets" things quickly.)
Andy Lasda joined pingVision back in May of last year, but only now was he able to break away from family and bike cruises to attend a DrupalCon. Andy's interest in computers began at the tender age of 9, programming BASIC on an Apple II, and his love for technology has only grown. Now with over a dozen years' professional experience in systems administration, web development and application development in PHP and Perl -- not to mention business analysis and project management. As pingVision's first-string sysadmin and developer, Andy's keyboard has touched, checked out, pushed or created just about every file on every one of our projects.
Ben Jeavons is the most recent addition to the pingVision family. Ben learned his Drupal chops at the Boulder-based Drupal-powered venture Enthusiast Group, and has already become a project lead.
Matthew Saunders is our operations manager. In some ways he comes from years and years of experience in an entirely different world: non-profits. Matthew joined us already having a solid knowledge of Drupal. If you've read his blog or the TechSoup forums, you'll know him as something of Drupal evangelist as well.
Kevin Bridges (cyberswat) has become our lead developer on our largest projects of late. Kevin maintains the Picasa and Auto Assign Role modules. He's also been involved in our ongoing project management development quest. Be sure not to miss our case study presentation on PopSci.com. Kevin will be doing much of the talking there.
Rad (whose full name is Radovan Anzulovic) is a trained mechanical engineer who's one of our themers. His good cheer would almost be maudlin, except that it's really honest good cheer. He's also an adventurist, especially when it comes to bicycles. If you meet him, ask him about the schoolbus.
A returnee to worldwide Drupal events is Ezra Barnett Gildesgame (ezra-g), who was a presenter at OSCMS 2007. Ezra joined pingVision in 
Last, but certainly not least, is pingVision co-founder Katherine Lawrence. When pingVision evolved from a freelance shingle into an LLC, Kate and I comprised the entire company. Our first "office" was the livingroom of a 2-bedroom apartment, "financed" (if you could call it that) by our first client check. Much of what pingVision is today is thanks to Kate's hard-earned Fortune50 executive experience (which has often provided us both much lore on how not to do things) and unwillingness to accept conventional wisdom. On this trip, Kate revisits her former hometown of Boston for her first DrupalCon.
Wow. Two years ago we launched 