This is the third post in a multi-part series on using GitHub for Government. In previous posts, we've discussed the basics of GitHub, as well as what the public can see and do with GitHub. In this post we'll look at what Drupal code should and shouldn’t be in a public repository, and in future posts, we'll discuss users and permissions on organizational accounts and developer workflows.
What code can be safely made public and what code should be made public are not always the same thing. What custom code should or should not be made public depends on what your agency’s objectives are in releasing your source code. These objectives usually include one or more of the bullets below. (If you know you’re expected to open source your code, but you’re not sure which of these objectives is driving the decision, I recommend finding out. This can help you avoid a lot of headache and confusion down the road.)
Possible objectives for releasing source code to the public:
- Comply with an organizational source code policy that mandates “open source by default” (e.g. Consumer Financial Protection Bureau policy here)
- Release code as a matter of transparency, so the public knows what it paid for
- Release code with author names in the commit history to give developers a sense of pride, ownership, and peer pressure to do their best work
- Whether code is reusable or not, provide it as an example or starting point for other agencies solving similar problems
- Cultivate a community of users and contributors so your agency is not paying the total cost of ownership alone
- Encourage other agencies to reuse your code, so you’re not using taxpayer dollars to solve the same problems over and over again
The following lists of bullet points describe the different types of code that power Drupal-based web applications. These are things you can release. With your agency’s particular objectives above in mind, hopefully this will help clarify what you should release in your own particular situation.
These are the different types of projects that make up most of a Drupal application, and the different types of projects that people contribute on drupal.org. If your objective is reuse, these are the most important things to share:
- Modules: Provide features and functionality that extend Drupal’s core feature set
- Themes: Graphic designs are implemented as “themes”
- Install profiles / Distributions (“distros”): Whole web applications can be made sharable and reusable as install profiles or distros (if developers build and maintain install profiles from the beginning, these are really easy to release later; trying to reverse engineer an install profile after the application is built can be laborious and costly)
- Make files: A Drush make file is like a recipe for an application including a list of all included projects and version numbers. This can be used to assemble a whole application from all its constituent parts (these are usually included in install profiles on drupal.org to create a “distribution,” but you can release these on your own on GitHub too)
These are things developers do not release on drupal.org, but they may be valuable to others to serve as an example or starting point for similar projects.
- Site-specific modules including features or functionality that is specific to your government agency.
- Site-specific themes including branding assets, hard-coded privacy policies, or site names specific to your government agency.
Do NOT release:
- Site-specific settings (e.g. settings.php)
- Site-specific files (e.g. .htaccess)
- Copies of other people’s work maintained elsewhere (e.g. drupal.org)
- A full copy of the exact site code base
In the next post in this series on GitHub for Government, we’ll discuss users and permissions on organizational accounts.
