Some considerations when using open source components and tools

1. Selecting software: Total Costs of Ownership
Open source is often selected as a means to reduce license costs and ease the management of said
licenses.
However, one must take the total costs of ownership into account, including but not necessarily
limited to:
• Migration costs: often a migration traject is needed to migrate data, templates, … from the
old system into the new one.
• Re-integrating costs: if a system is to be a “drop-in” replacement for an existing component
in an integrated environment, it still has to be tested, and some changes may be required
nevertheless.
• Maintenance costs: open source software also needs upgrades / security patches etc. These
changes have to be tested and installed by your staff.
• Training expenses: staff and users do need training, whether the product is open source or
not.
• Exit costs: at the end of usage cycle, there are exist costs for moving data, templates … out
of the system, into a new one.
Open Source Recommendations 1 / 3

2. Writing your own software - Custom development
Make sure you own the code
If your department wants to publish custom code, it has to be sure it has all the rights to do so.
While this may seem obvious, in some countries one has to explicitly specify in a contract that a
developer will transfer all the rights to the client / government agency he is working for.
This should not only cover source code, but also documentation (in original / editable form), hi-res
versions of graphics and so on.
Another option would of course be that the developers themselves publish the code as open source.
In that case the government does not own the code, but the objective (being able to reuse and adapt
the code within the boundaries of the license) is reached.
Don't invent your own license
Reusing existing licenses benefits both your department and the developers: your legal department
does not have to write something from scratch, and many open source developers are already
familiar with the existing open source licenses. This saves time and avoids confusion when several
parties need to combine and/or maintain open source software.
Stick to well-known licenses like Apache, BSD or (L)GPL. When in doubt, the European Public
License (available in 22 official EU languages) may be an option:
http://joinup.ec.europa.eu/software/page/eupl
Respect the license
Although open source software can be distributed for free, this does not mean it comes with no
license at all. Please respect the license: this is no different (and certainly not harder to do) than
respecting commercial licenses, and often the requirements are very modest and easily met.
When extending software or reusing open source libraries, your integrator should make sure that
components with different licenses can be combined.
Make sure you have the expertise to maintain the code
Having the source code helps, but having internal expertise (or being able to quickly find external
expertise) is equally important.
Without a good understanding of how the system works, it will be very difficult and / or time
consuming to find and fix bugs or add new features, when the typical code base easily consists of
several thousands of lines of code.
Open Source Recommendations 2 / 3

3. Use the well-known community tools
Many open source projects already have development tools and guidelines in place that can be used
for free. While your department may have its own development environment, it is recommended to
use the open source project's version control system / ticketing tool instead, and follow the
established best practices on developing code and writing documentation.
When developing a project from scratch, the European JoinUp platform may be considered:
http://joinup.ec.europa.eu
Contribute your patches
Aside from creating goodwill from the community, reporting bugs and contributing patches also has
the benefit of keeping your source code in line with the source code of the community. It is very
time consuming to maintain your own branch of a product that is regurlay updated, so contributing
your patches reduces the risk of divergencing code branches and simplifies the hand-over to other
developers.
In addition, some open source licenses require that all end users can obtain a copy of the modified
code. Contributing your patches to the project's code repository or ticketing tool ensures that this
requirement is met, without much effort.
Open Source Recommendations 3 / 3