Some Open Source Recommendations


Published on

Some considerations when using open source components and tools

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Some Open Source Recommendations

  1. 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. 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: 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. 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: 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