OpenConcept believes in the importance of community & the power of open source. Drupal is a great software product, but the community behind it is bigger and better than the software itself. Open source approaches are really disruptive when they are applied properly because they can disrupt the producer/consumer mindset which has been drilled into our heads over the last 50 years.  When we realize that we can contribute something which helps others and by making the community stronger also helps ourselves.

Sadly there are a few process in place which really hinder that participation. There are a lot of organizations out there quite interested in adopting open source software, often because it is free. Who wouldn't want to benefit from 265 years of effort without having to pay the millions of dollars it would take to create it. However, most organizations want to adopt open source technology, with as little changes as possible to other systems.

In our experience, most procurement departments leverage a boiler plate of previous contracts which have a number of practices that are bad for the open source community and indeed for the organization.

Here are some best practices that I would like governments & non-profits to adopt.

1. Leave the code as GPL. You may not know or understand licensing issues behind open source software, but it is very important to remove all references to the client or the 3rd party owning the code.  What organizations need is protection to see that
   • We suggest this language: "All software we develop through this contract will be the copyright of OpenConcept Consulting Inc. and licensed under the Gnu Public License (GPL) to ensure that the software may be freely used, modified and distributed. Any documentation provided by OpenConcept will be similarly licensed under the Creative Commons Share Alike License." It doesn't really matter who the copyright owner is though and this could easily be the client.
   • It is expected that you will also have a statement about client confidentiality and that the bulk of the code produced won't be of benefit to anyone else. 
2. Hire people who have contributed. Especially with popular web applications like Drupal, don't assume just because someone says that they know Drupal that they do. Drupal is community driven software and if people haven't participated in the community, they don't really know Drupal. There are so many ways to participate, most of which are completely transparent.
   • If you are looking at the individual, you can ask them for their Drupal ID. If you are assessing an agency, see if they have a /drupalgives page or see if they are listed in the Drupal Market Place. Membership in the Drupal Association is also an excellent sign.
3. Don't Hack Core. This is really a short form, but we've encountered so many organizations who have taken short cuts and have modified the code in Core & contributed modules directly.  This causes huge problems when it comes to security upgrades and also often causes vendor lock-in as nobody else really understands the coding that was done on the system. Make sure you have a system that can be maintained for security.
4. Look to contribute back. If you need to have a module developed which could benefit others in your sector, consider asking your developers early to think about contributing it back to the community.  It might end up being a bit more expensive, but if developers think that their code might be peer reviewed, they will invest more time in following best practices (which will benefit you).

There are likely a lot of other things that can be done in the procurement process to ensure that you are selecting the right people.  Please suggest ideas that occur to you.