Procuring FOSS4G – an introduction
This article provides an overview on procuring Free and Open Source Software for Geospatial (FOSS4G). Procuring refers to purchasing work related to FOSS4G. In the process it’s not only important to ensure that the right supplier is chosen, but that contracts align with procurement needs and FOSS4G principles, and the final results support the objectives of the organisation.
FOSS4G projects follow open-source principles, necessitating specific considerations to support continuous development and sustainability. Engaging people with prior expertise on FOSS4G tools and related processes early in the procurement process can streamline operations and ensure the best use of available tools and expertise.
This blog post outlines three key procurement scenarios: acquiring a new FOSS4G tool (e.g., a custom tool for a specific use case), updating a software that is already in use, and customising an existing tool (such as GeoServer, QGIS or QField).
This blog article is by no means exhaustive, yet hopefully helpful. And while this is aimed to focus on FOSS4G, many principles presented here are not limited to it but apply to procuring other software, too.
Procuring a new tool
Be it standalone software, plugin or a service, it is important to define the organisation’s needs. These include not only use cases and objectives, but also required functionalities, possible hosting options and integration needs to other software or services.
Clear timelines and documentation expectations should be set from the beginning, even though defining a realistic timeline can be challenging as different work phases require different amounts of time. The success of the project may depend on the systems that the new tool has to integrate with.
Updates to existing applications
Understanding the current system version, past updates, and any customisations is essential. For software that has been set up “as is” (such as GeoServer) and has not been customised, the updating is usually quite straightforward and well documented when updating between consecutive versions. Longer gaps between updates require more effort.
For updating, ensuring that the service has proper documentation that’s been maintained constantly helps track changes and improvements over time. It may also guide through common pitfalls of the updating process of that specific service or even help to avoid them.
Highly customised applications may pose additional challenges, making well-maintained documentation even more crucial.
Customisations and new functionalities
Organisations should evaluate their current and future needs, determine whether the customisation is for internal use or broader contribution, and maintain comprehensive records for future reference.
Before developing new functionalities, it is beneficial to check for existing solutions (ie. going through has someone already done something that could be of use in your use case).
Collecting and prioritising ideas for development teams helps streamline the process: if you gather together all the ideas that you have and hand them over to the development team, they can see which are top of your priorities now and what kind of things to expect next – and also suggest to you which of your ideas could be fulfilled at the same time quite easily.
All new functionalities should be properly documented, and organisations are encouraged to contribute improvements back to open-source repositories for long-term sustainability.
Considerations before and after procurement
Before procurement, organisations should assess existing infrastructure and potential integration requirements. Hosting, security, and database needs should be carefully considered. For some FOSS4G tools hosting and database are not required yet for public map services they can be essential.
After procurement, assigning an administrator for the system ensures smooth operation. The admin should be in the know about the update needs and the possibilities of the newly implemented system. After the system is up and running it should be promoted within the organisation (and if it intended for public use, to the public / target group) to maximise its benefits and to make sure that it actually gets to benefit the end-users as intended.
One thing that should not be forgotten in the midst of procuring a FOSS4G tool is the support and training for the tool. You might need training in the use of that software / service, whether it is the training for the admin, the team that will be using it or if the key persons change over time and the knowledge has to be passed on to new people. Or then there’s a need for flexible support (for example, via e-mail) as “an insurance” that makes sure that in case of an unexpected error there’s someone to reach out to for help.
Documentation
We cannot overestimate the importance of documentation. Maintaining thorough documentation ensures smooth updates and maintenance. It should provide details about implemented customisations, locations of key files, and clear instructions for future developers or administrators. The documentation should be comprehensive enough for a person who hasn’t been in the original development team to continue the work.
Closing Thoughts
Effective procurement facilitates ease of use for administrators, developers, and end-users while supporting the long-term success of FOSS4G solutions. Even though this article gives many viewpoints and lists various things to consider, the most important thing is, after all, to procure solutions that answer your needs and make your work easier.
