Drupal is a CMS (content management system) that uses an open source license. This GPL license is also applied to any contributed code that is added to Drupal.org. There can be a bit of confusion about open source software. Yes, it is free (as in free beer) for you to download and modify. This does not mean that planning, constructing, and maintaining a Drupal site is free, however. Drupal website projects must have appropriately skilled human resources, hosted servers, and often other third-party services to collectively satisfy engineering requirements.
A key component in building most Drupal websites is the creation of Drupal modules and themes. Read: time, cost, best practices, ongoing maintenance, security considerations, bug fixes, new features, and support for external code/services. Did we mention TIME? YES! LOADS OF TIME!
Organizations have limited resources and budgets. When a finite number of developers are responsible for a Drupal module, progress is restricted to their availability, both during initial development and thereafter. Software is never “done” since it tends to evolve over time with the needs of one or more organizations. There are also security exploits and performance concerns that either are not obvious during a module’s first iteration, or simply, there is not enough time to create the most ideal version of that module.
Enter the open source community. The name of this game is public interest. The more interest a contributed Drupal project (module or theme) has, the more willing people are to help make it more mature. Where a lone organization has limits, a community can massively accelerate development through contributors. A project needs to generate interest to get this level of support. Here are a few general tips to do exactly that:
- Do not recreate something that already exists. Instead, extend and refine. Use the issue queue and create patches for code changes that help a project.
- Contribute code and designate code maintainers in your organization. There is a specific process to adding a sandbox project versus a full project.
- Be responsive in the issue queue for your Drupal projects.
- Routinely review your project code as your knowledge of Drupal grows.
- Sponsor development of components that are vital to your website and organization. This will help advertise your support of the Drupal community, so everyone wins!
- Encourage developers to think about how to create modules or themes in a way that can be shared as a contributed Drupal project. This includes adhering to coding standards and best practices, writing secure code, thinking about code in a generic enough way to share with others, and creating configuration pages for website-specific information (don’t hard code this stuff).
- Attend Drupal meet-ups, camps, DrupalCons, and other events to talk about and improve your organization’s contributed projects.
Sure, some things must be built that are website-specific. It is best to relegate this business logic to custom modules (and sub-themes) if that logic cannot be made in a way that can be shared. Be strategic with these decisions. The more code that is contributed, the more opportunity there is to have additional resources help with those projects.