|
2. Joining an existing community | 4. Long-term sustainability | 
|
3.1 Operating within your public administration
Given that the OSS community is to be launched within a public administration, the nature and operation of the community will inherently be affected by the public administration’s ways of working. Therefore, to ensure that the community is well positioned and recognised within the public administration, it is recommended that you promote the community and inform your colleagues about the benefits of and ways of working with OSS.
How to establish collaboration between an OSS community and the public administration it is attached to?
Building relationships outside your community will help to boost its recognition. Contributions and resources dedicated to your OSS community have to be recognised and valued by the management and employees. This can only happen if other civil servants outside the community understand what working on an open source solution entails.
The Developers Italia community started by inviting civil servants from the Italian public administration to participate in the community’s forums and events, thus helping them to get better acquainted with the working methods of OSS and to recognise the value of the community.
The benefits of the new OSS community should be demonstrated to your peers, management, and the decision-makers of your organisation as early as possible. This could be done by sharing weekly or monthly reports about the recent developments and code contributions to the software. Another good way to showcase your project’s growth over time is to define some metrics against which you could assess your community.
For inspiration, you can consult the CHAOSS Community Health Metrics
It is also important that the hierarchy of your public administration understands the collaborative nature of OSS communities. This will help safeguard the horizontal and transparent ways of working in the community. Furthermore, public sector managers should appreciate the fact that software development is a continuous process that might require several iterations, tests and release cycles before the final product is put together. Even then, software updates and new add-ons are regularly released. OSS communities are not static and there is no end-goal per se. As long as the software is used, the open source community behind it will be needed to publish updates and respond to user requests.
Should we set up an Open Source Programme Office (OSPO)?
To better position your OSS projects within the public administration, you may consider setting up an Open Source Programme Office (OSPO). OSPO’s responsibilities will vary depending on the size of your organisation and its OSS engagement scale. Its main mission is, however, to nurture and support the open source approach to software development, foster its organisation’s capability to work with OSS, and engage with developer communities. The European Commission, in its renewed open source software strategy, has established an OSPO and tasked it with facilitating all activities outlined in the strategy.
Setting up an OSPO also allows you to get in touch more easily with other public administrations engaged in open source projects. OSPO networks offer useful resources to leverage OSS, create OSPOs and open source programmes, and provide information on good practices regarding the health of open source communities. For instance, the OSPO++ network organises bi-weekly working group meetings to exchange information on the benefits of OSPO programmes and share advice on potential challenges among practitioners and public administrations or non-profit organisations looking to set up an OSPO. The OSPO++ network also publishes a series of podcasts on good practices when setting up and maintaining an OSPO. Another example is the OSPO alliance which provides useful resources on the use of OSS to any public or private organisation wanting to engage with open source. One example is the Good Governance blueprint.
Description of functions and tasks that can be carried out by the OSPO have been proposed by TODO Group.
How can we ensure the community’s growth within our public administration?
As your community will be set up within a public administration, you should work to ensure that its decision-making process does not slow down your community’s growth. Raising awareness of OSS benefits and your community among civil servants and the political hierarchy will encourage openness in your public administration with regard to fostering the growth of an OSS community. You should highlight the fact that OSS helps prevent vendor lock-in and ensures your administration’s digital sovereignty. You could invite your colleagues to contribute to community forums, participate in any online or physical events and encourage them to meet community members to better understand the nature of OSS communities. Having an above-mentioned OSPO in place will also help your administration to build capacity to work with OSS.
Bearing in mind that public administrations are hierarchical, which stands in contrast to the the horizontal communal nature of OSS projects, launching and growing your community may take patience and determination. The decision-making process within public administrations depends on long-term planning and budget cycles, which in turn depend on the political priorities at the time. Nevertheless, the OSS communities that we have studied all demonstrated flexibility and agility to work with and within public administrations.
Who can become our community’s members?
A public sector open source community should always arise from the needs of the public administration. However, just because the project is created and funded by a public administration, it does not imply that the community cannot evolve beyond the frame of a single public organisation or branch out to other users. In fact, our research shows that an increase in the number of actors involved in the community as active contributors strengthens its sustainability.[23] Indeed, the Growing Open Source Projects with a Stable Foundation report recommends that the technical and community governance be siloed from each other. This will allow the technical contributions to the project to remain open. It will also enable various contributors to take part in developing the code base without influencing the evolution of the community’s governance.
The open source community behind the CONSUL software has an active strategy of diversification of its contributors and users. This strategy prevented the development of an unbalanced dependency of the open source community towards a single decision-making authority, in this case the City of Madrid which created the software.
3.2 Focus on the software
The maturity of the community’s software is crucial for the community’s sustainability as it is the foundation on which the community is built. There are several elements that you need to consider when releasing and maintaining the community’s code.
How can we choose the right licence?
Choosing the appropriate licence allows the software to gain visibility. It is also a guarantee for all actors involved in the project that the source code will benefit the open source community. It is good practice to choose an open source licence recognised by the Open Source Initiative (OSI). Furthermore, it is recommended to choose a licence commonly used in the programming language or framework ecosystem that your project will build upon. This will ensure continued participation from outsiders and lead to a more sustainable community. If you decide to adopt a less-than-reciprocal licence, it is important to add a clause to the effect that you will update/change your software licence if certain conditions are not met. These would include failing to grow a strong user base or the community of public administrations losing interest in the project at some future date. We reiterate that an OSI-approved licence is usually best, but even within the list, there are less reciprocal options. A permissive licence is best when attempting to build a healthy community. A less reciprocal license – one that does not oblige the party adopting it to maintain an open license in the future – does not build trust within the community. Trust is a concern because the community needs to believe that parties using their software will contribute back. Communities that have a highly reciprocal license for their software project are more likely to attract a diverse range of contributors.
Some tools that can help you in the process of identifying the right license include Joinup Licensing Assistant and Choose A License. Once chosen, open source licence compliance-checking software, such as the open source Fossology project, allow you to run licence, copyright and export control scans from the command line.
Additionally, open source communities need to check whether the country where the project is taking place has requirements regarding the licensing of open source solutions by the public administrations. For example, in France, public administrations are obligated to publish their source code under an open licence listed by the Decree, and in Spain, public administrations should follow the Guidelines on the Publication and Licencing of Assets, that explain how to publish and distribute open source software.
Which programming language should we choose?
The choice of the programming language is another key element of an open source project. It depends on the nature of the software, but whenever possible, you should choose a well- known language to allow more developers to contribute to the project and foster its reusability.
City of Groningen’s adoption of CONSUL was slightly slowed downed by the software’s programming language. As the software is written in Ruby on Rails, the Groningen team found it difficult to find local developers proficient in this programming language, as it is not widely used in the Netherlands.
How should we approach software releases?
Having an overview of your planned product releases, as is the case with proprietary software, helps to add structure to your project. A project roadmap will be a helpful way for your team to plan the key milestones associated with your software’s development. When it comes to OSS, new software releases often happen in 3- or 6-month cycles.
Additionally, planned software releases should be announced in advance. This will create anticipation, boost your community’s visibility and help the community to prepare for the new release. More specifically, having a clear idea of the next version release will allow community members to anticipate potential new bug fixes, plan training sessions, and to set expectations for their workflow.
A designated team within Integreat updates the software, conducts peer-reviews, and follows up on any bug reports. They ensure that Integreat is up to date, responsive to the community’s needs, and digitally relevant. The mature and user-friendly packaging of their software is one of the key factors explaining their success and rapid growth.
How should we ensure code quality?
Prioritising quality over quantity with regard to the development of the source code is a key element of an open source project’s sustainability. To ensure that the source code meets high quality standards, open source communities need to put testability mechanisms in place and foster peer-review processes. Giving more responsibilities to individual members of the community can also motivate them to keep the highest standard of code quality without relying too much on the community’s code testing capacities.
Furthermore, to maintain the long-term software quality, you need to carefully evaluate (and not underestimate) the workload required to keep the software updated, fix bugs and respond to users’ queries. In many cases, software maintenance is a full-time job.
What should we do regarding software documentation?
Well-documented software makes it easier to onboard new members and foster software reusability.[24]
Does our software have to meet GDPR requirements?
When building an open source solution for a public administration, keep in mind the specific requirements that it entails. Lack of compliance with the requirements of the General Data Protection Regulation (GDPR) is an obstacle to the use of some software. Open source communities need to make sure that their software is GDPR-compliant and that information about its compliance is easily accessible to external users. It is also worth checking whether the software that your public administration is developing must meet any national requirements or regulations.
How do we make the software accessible?
It is equally important to ensure that your software meets the EU and international standards for accessibility. The European Commission’s Web Accessibility Directive, in force since 22 December 2016, lays down the standards and procedures associated with ensuring the accessibility of European websites and mobile apps of public services.
The Developers Italia community decided to invest their resources in physical gatherings. Not only did this stimulate communication and more efficient collaboration, these gatherings also helped to put a face to the community.
Additionally, the W3C has put together a detailed guide on Accessibility, including international accessibility principles.
When to make the source code available?
It is good practice to make the code publicly available from the project’s inception, starting with the very first line of code. This way, more developers are encouraged to join the community. Waiting too long before publishing the source code not only results in fewer developers being involved but also contradicts one of the core principles of open source – making the source code available.
In addition to publishing software, you should maintain and keep it up to date. Ideally, the public software repository should be the main ‘working’ software repository used by the project team and the community.
The UK Government has put together a dedicated guidance explaining the value and process of making source code open from the start.
3.3 Organise the community
Organising OSS communities helps to guarantee their smooth operation. Given the hierarchical nature of the public sector, organising the community becomes especially important in demonstrating a project’s success and sustainability. Clear governance and operational guidance should be agreed upon with the community so it can operate and grow freely.
How should the decision-making structure of the community be set up?
The sustainability of any open source community depends on strong leadership and open management. Community governance, set up transparently, should strike the right balance between openness and the organisational structure of the public administration.[25]
- Identifiable public sector manager: The role of public sector manager(s) is to enable flexible and transparent modes of operation for the community. Any decisions taken by public sector management should be clearly reported back to the community along with justifications for such decisions. Considering the openness of open source communities, public sector manager(s) should consult with community members as frequently as possible to ensure that the community is truly member-driven. This will also help to strengthen members’ motivation to contribute to the community and its project(s).[26]
- Project manager / steering committee: The project manager or steering committee should demonstrate a strong understanding of OSS and the nature of the community as well as knowledge of public sector operations. This will allow them to act as facilitators between the community and the public administration within which it operates. Additionally, the project management team should include the project’s key developers as they have the most specialised knowledge of the software.
For the sake of long-term sustainability, the community’s management should also take into account potential changes to the roles in the community. You should facilitate the organic growth of the community members’ responsibilities and envisage potential replacements of managers if they are no longer available to steer the community. Resources should also be dedicated to training future community leaders - a strong team behind the community is crucial for its sustainability.
A key part of your community is to have a core team. These are members who make daily contributions to your software, interact with the broader community, and are responsible for making decisions for certain subsets of your community. More often than not, some core team members are also part of the project management team as they tend to have the strongest knowledge of the long-term evolution of the open source software and the community.
One of the factors behind the sustainability of the Lutece software is the role played by core developers in the project. While Lutece’s inception stems from a political initiative, the developers’ team in charge of its technical development has been driving the evolution of the software since its inception.
Finally, users of your open source solution are another key community group as they share valuable feedback on the new releases. However, this group and the contributors can be viewed as being at the periphery of your community. Unlike the core group, they are more likely to switch to other software and be less committed to your project in the long run. These key community layers are summarised in Figure 5 below.
What are some key roles & responsibilities that should be fulfilled in the community?
For your community to function smoothly, your core community members should fulfil several different roles. Even though there are many types of open source communities, below are some of the key roles that can be found in most communities, as additionally summarised in Figure 6:
- Management – the key person(s) responsible for the community and taking decisions on features, releases, and other activities as well as acting as a bridge between the community and the public administrations’ political hierarchy.
- Core Technical Committee – a technical management team that is highly committed and is responsible for verifying and approving proposed changes to the code and making the final decisions regarding the project’s evolution together with the project leader(s).
- Maintainers – members of the community responsible for maintaining and managing certain aspects of the project (e.g. security). Community members who have a strong sense of responsibility and direction are best positioned to be community maintainers.
- Committers – community members who have demonstrated dedication to the community and are regular contributors can, with time, be recognised as project committers. They can also be responsible for reviewing new code contributions.
- Contributors – any members of the community who participate in forums, comment on issues, organise events and are active in any other way.
The team behind the CONSUL software exhibits a strong commitment to community building and outreach. Dedicated team members are tasked with being responsible the search for new users of the solution.
Additionally, some members of the core team should also be responsible for promoting the community and be in charge of communication, marketing and social media management.
The Linux foundation and GitHub Open Source Guides both outline some of the most commonly found roles within OSS communities.
What organisational information should be made available to the community members?
A community operates best when there are clear roles and responsibilities as well as defined means of operation. However, these aspects need to be agreed upon with and driven by the community. Community members are also encouraged to take up roles and responsibilities voluntarily.
The governance structure of the community itself will largely depend on the type of community being set up. A young community may be self-driven, thus allowing contributions to happen spontaneously. However, setting up your community will require strong efforts in the beginning to structure the team, set goals and milestones and build coordination mechanisms.
Clear Community Vision & Mission
A community is more sustainable if it has a common sense of purpose and a shared identity. For this reason, new and mature communities alike should have clear, publicly available Vision[27] and Mission statements[28], which will help foster a sense of a community working toward achieving a single goal. They will also help potential new community members to understand the community’s purpose, thus encouraging them to join.
Community Guidelines
The rules governing the community should be driven from the bottom-up and agreed with community members. Nevertheless, if you wish to have more formal internal control, the coordination mechanism should not undermine the community’s ability to freely evolve, innovate, and develop. A mature community may, over time, become leaner and more informal.
The best way to set out the community’s operational model is by putting forward Community Guidelines.[29]
They should cover the key elements as follows:
- Code of Conduct – outlining the operating principles of the community and expectations for how community members should behave.
- Roles & Responsibilities – detailing any specific roles & responsibilities that exist within the community and how community members can get involved.
- Community’s ways of working and key procedures – outlining the key processes within the community, such as becoming a community member, contributing code, reporting and fixing bugs, and animating the community.
- Resources – detailing any supporting resources available to community members, such as online tutorials, documentation, and online forums.
FAQ for community members and the general public to consult
You can host a FAQ on your website or on the development platform that you use for your project. This FAQ may also be divided into two parts: one for contributors and the other for the users of your open source solution.
The FAQ can comprise various sections on general questions, definitions, rules, licencing, documentation, and the communication channel.
How can we foster a diverse and inclusive community?
Despite the shared values of openness and collaboration, open source communities can still do better in applying diversity, equity and inclusion (DEI) principles. For example, men constitute a vast majority of contributors.
If you want to nurture an inclusive community from the start, make sure you create a welcoming environment for new members. Research shows that the first experience of participating in an OSS community is crucial for later participation. Consider having mentors, onboarding kits, and events to ease new members into your community.
Additionally, in your community’s Code of Conduct, highlight how your community approaches diversity and outline transparent procedures for resolving issues linked to harassment or discrimination.[30]
How inclusive can we afford to be at the start of the project without losing control of the direction?
Your community should be agile and understand that priorities may need to be redefined at times. The outputs of your community will be based on the current needs of the public sector but may, in the future, require changes and new input that will put other projects on hold. Changes may include adding new features and reworking the code at hand to adapt to these new needs. Your community should thus be prepared for agile methods but you should define a short-, mid-, and long-term vision to achieve the set goals.
Additionally, choosing a few key developers to start developing the software will be useful. You can choose a well-respected figure from the open source world to join the project – even if only temporarily to help secure developers’ initial commitment and contribution to the code.
3.4 Keep the community active
An OSS community is driven by the dedication of its members. Thus, ensuring the community’s health and vibrancy is vital to its longevity.
How to best facilitate communication between community members?
Rapid and transparent communication is key for open source communities, and there are various ways to facili- tate it. For example, the community may establish a place for both synchronised and unsynchronised conversations, in the form of live chats and a forum respectively. In addition to informal chatting, a central information hub should also be set up. This can be a wiki, a mailing list, Discord, Slack, GitHub, or GitLab. A single point containing all information will ensure that no important information is lost or scattered across the various channels. Furthermore, your community may also opt to hold meetings at a frequency determined by you, for example every two weeks. These meetings may serve as an opportunity to communicate with your peers or to share any updates on your project. You can choose to use open source video conference tools such as Jitsi Meet, Apache Open Meetings, Yami, BigBlueButton, BlueJeans, or Nextcloud Talk. Some of these tools can be used for free. Public sector open source projects are encouraged to choose OSS for their means of communication in order to boost their credibility within the community.
To ensure the smooth flow of information between the diverse OSKARI community, the project team has hired a community manager responsible for handling internal and external communication flows.
Public progress reports highlighting weekly or monthly contributions are also very popular with community members as a means of ensuring transparency within the community. These updates might also be shared with the public administrations’ hierarchy to demonstrate the project’s evolution.
How to sustain the motivation of community members?
Motivation of the community members is a key aspect of the community’s long-term growth and sustainability . If community members do not feel motivated, they are more likely to leave.
There are several ways to maintain the motivation of your community’s members: recognising members’ work, transparent decision-making, and organising meetups.
Recognition of members’ work
Community members are more likely to be motivated and proactively participate in the community if they feel that their contributions are visible and recognised.[31] This, for example, can be facilitated by having weekly overviews of the community’s activities that are shared with the entire community. Another good practice is to recognise OSS contributions and work within an OSS community as part of developers’ employee evaluation.
Similarly, active community contributors can be rewarded by being assigned more formal and official roles with the community. Such roles and duties include management positions, providing translation services, managing documentation, acting as an organisational integrator, reviewing code, and tracking progress. Allocation of these roles will help to ensure that the community’s management is as horizontal as possible within the framework of a public administration.
Another way to recognise members’ contributions to the community is by introducing gamification elements, such as badges or leader boards, to your community. These might be a fun way to give recognition to and motivate community members. However, before introducing these concepts, assess whether they would be welcome. Some community members might view these changes as fostering competition, rather than collaboration, between members.
Transparent decision-making
Transparent and non-hierarchical decision-making is imperative in ensuring that members feel valued and motivated to participate in the community. Any decisions made regarding the community should be clearly logged and transparent. Community members should also, to the extent possible, be involved in planning the next steps and project releases. An organic community is defined by good coordination and the members working together towards the same goal.
Organising meetups
The Developers Italia community decided to invest their resources in physical gatherings. Not only did this stimulate communication and more efficient collaboration, these gatherings also helped to put a face to the community.
As much as open source communities’ members mostly interact online, physical community meetups are highly beneficial to the community. While physical meetups should not replace online interactions and hangouts of the community, they might help to add some vibrancy to it.
The management team at the Integreat platform, recognising the importance of a vibrant community behind its solution, organises regular events where both the developers and usersV of the application can come together and share their experiences of using the software.
If your budget allows for it, your project will benefit from regular meetups as these are useful to maintain a sense of belonging and foster information exchange. Furthermore, as your community grows, it might also be worthwhile to organise location- specific meetups for, say, different municipalities using your software. If physical gatherings are not possible, organised online meetups may bring similar benefits.
3.5 Grow your community
How do we ensure the visibility of our community?
As discussed in section 3.3, some community members need to be dedicated to increasing the visibility of your community. One factor that might help your community be more visible to potential contributors and users is having a dedicated website. It should be easy to access and navigate and provide the most important information about your software. You should use the social media to raise awareness about your software, find like-minded community members, and learn about other ongoing projects.
Furthermore, you should list your software in an existing national catalogue and any other independent catalogues.
Are there other public administrations that could be interested in joining the community?
Community growth is an important aspect of any community’s sustainability. It is likely that there might be other public administrations with similar needs that could also benefit from your software.
Therefore, your community should dedicate time and resources to raising its visibility across other public administrations. Your software might be particularly useful to small public entities which, taken alone, do not have the financial or technical resources for long-term involvement in an open source community.
How do we attract new contributors?
There are a multitude of ways to attract new contributors to your community. Most communities collaborate with other public administrations, universities, private developers, private companies and citizens. Once communities reach a mature stage, you should publish clear mission statements and have easily accessible documentation and code. You should also participate in any online or physical gatherings of open source communities. There are many OSS focused events taking place across the globe every single year. Your community could attend EU-funded workshops and conferences, such as the Sharing & Reuse Awards, where you could showcase your project and boost its visibility.
Developers Italia organised a 48-hour code sprint throughout Italy and even in San Francisco! They invited programmers, IT professionals, and students to develop functionality for public administration projects hosted by the community.
If you have resources to spare, you could take a more pro-active role in attracting new community members. Hosting a hackathon is a great way to involve interested citizens and potential new community members.
How do we approach the departure of members?
You should be aware that it is natural for community members to leave. Indeed, high turnover of peripheral members is a sign of health in a community. Movement of members between different projects generates new idea circulation and innovation. However, core member loss is a more serious concern. Departing members should be quickly replaced with new ones so your community grows organically. For this to be a smooth process, you should document the evolution of your community (e.g., by tracking key decisions and maintaining meeting minutes) and have onboarding kits ready for new joiners. In the case of departing core team members, it is best to select a replacement from within the community – somebody who has good knowledge of its evolution and is familiar with the required responsibilities in the new role. In successful open source projects, such as Linux, the community often has conversations about ‘grooming’ and training replacement leaders for the possible departure of Linus Torvalds, the founder of the Linux community. This is good practice for all projects. The departing member should also take time to train their new replacement or (at least) prepare guiding documents for the role, as well as make sure the documentation corresponding to the area of expertise on the software is available to the community. Their software skills are important, but passion for the project and charisma will be highly effective in rallying the community so that the latter endures.
Generally speaking, an OSS community with a strong developer core and a large body of peripheral developers with a high turnover is a good indication of a community that is doing well and evolving naturally. Hence, as long as you have a pool of active contributors, you should be able to fill departing members’ roles without major complications.