The slogan of the new Drupal website is:

Come for the software, stay for the community

This is the typical process by which people learn that Drupal's ultimate strength is its community, rather than its code base.

Websites are like human beings - any two websites can be very different and do very different things, but under the hood they are 99% the same. Any website (large or small) has very small unique code base, compared to the enormous software stack that it sits upon. Other components in the stack are typically:

• kernel, e.g. Linux - 13.5 million lines of code (mainly device drivers)
• database, e.g. MySQL - 1.7 million
• webserver, e.g. Apache - 450,000
• HTTP accelerator, e.g. Varnish - 78,000

The operating system distribution itself is even larger, e.g. Debian has about 32,000 software packages, totalling almost half a billion lines of code. Of course, only some of these packages would be involved in running a given website. At a lower level, even more is going on in hardware.

Regardless of what your website is doing, all of the above components will be typical and you will probably not be reinventing any of them from scratch. Drupal core (275,000 lines) is just another component in the stack. But, as small as Drupal is compared to the rest of the software stack, it is still a very large piece of software that has taken a decade to develop. The functionality that Drupal provides is also reusable for just about any kind of website.

Drupal has the experience of having been deployed hundreds of thousands of times. It works around so many weird security problems and software incompatibilities to provide a robust plateau on which to build your site.

On top of Drupal core sits the contributed modules - these are further reusable components. There are about 6,000 of these totalling about 10 million lines of code. Of course, you should only use a few dozen modules at most on any one site.

The trick is, to have as much of the functionality provided by reusable, community or contractually supported, open source components as possible. From the operating system right up to the contributed modules. Write as little private code as possible and only do so as a last resort. It should sit at the top of the stack, like the skin of an apple. If you need some new functionality that someone else might need, write a module and contribute it back to the community.

Time and time again I have seen companies using Drupal, but having no understanding of how to utilise it correctly. It is not a technical understanding that is required, but rather a social one. Developers will download Drupal and whatever modules they like the look of, and go off on their own, making modifications to get Drupal to do exactly what they want and failing to benefit from the following advantages:

• Popular modules are always getting better and better. For a company to fully benefit from improvements they make to a module, these improvements need to become part of the module on drupal.org. In order for the code to be incorporated, it will be peer reviewed and improved. Others will build upon it. This also removes the burden of maintaining a 'fork'. Updating core and modules to the latest release is considerably harder if a developer has hacked it.
• If you are having a problem with a popular module, there are probably many others having the same problem - making it much easier to get to the bottom of it in the issues queue.
• New engineers can be be parachuted into your site and know exactly what they are doing. They are already experts with the modules that you use. Time and money doesn't need to be wasted getting them up to speed with your bespoke effort.
• Increasingly, Drupal provides functionality that is more abstract in nature. New content types used to have to be created in a custom module - now this can be done by an administrator through a point and click interface. More and more can be done without any programming. Views and Panels are examples of this.
• Higher quality code - it takes a lot of time and effort to write code that is of really high quality. When code is staying private within an organisation it will be of much lower quality. Publishing forces developers to do a good job. Cutting corners with poor quality code is never a good investment.
• Security - if a considerable number of organisations are using the same code, then there is a much greater collective effort to make sure it is secure. Private code simply can't compete with this.

Developers need to fully utilise the Drupal community to their benefit. The best way for this to happen is for management to understand this. This means they can instil a culture within their organisation to engage with the community, and also to permit this to happen. Developers need to be able to participate in the community without fearing that management would not understand.

How can developers and management best come to have an understanding of the community and how best utilise it? Come to Drupal events like DrupalCon.

A further advantage of management understanding the Drupal community, is that they will probably see that it is much less dysfunctional than their own organisation. The Drupal community has extremely high levels of transparency. Almost everything (except security issues) are discussed in public. This has enabled the Drupal community to be a extremely effective engineering and decision-making machine. Something to be envied by almost every other organisation in the world.

There are a couple of other blog posts on similar topics:http://www.garfieldtech.com/blog/pay-it-forwardhttp://www.lullabot.com/articles/best-practices-in-open-source-development

[lines of code source: http://www.ohloh.net/ ]