We have planned for a long time to evolve the governance of the Standard for Public Code towards a more community maintained codebase. In light of the European office winding down (see above) we are speeding up that effort.
The call opened with the question: What would be some important governance aspects for you to feel empowered to continue to use and feel inspired to contribute to and consider to help maintain the Standard for Public Code? Some values that were mentioned were transparency, openness, meritocracy and neutrality. It was also mentioned that it would be nice to not have to bootstrap the governance, rather, stepping in to some existing framework would be better. Another point that was made was that creating, and “staffing”, an executive body from the start, rather than just publishing a GOVERNANCE file, would make a tremendous difference. Some also expressed it to be essential that people with historical knowledge of maintaining the Standard for Public Code to be part of this executive body. It was also highlighted that the members of this executive body are funded for their time somehow, possibly by having their organizations making a commitment to help maintain the Standard for Public Code.
As a separate point to raise the importance of active maintainers, that it is utterly important that they exist, it was agreed that: “a dead document is not authoritative”.
Some participants of the meeting expressed interest in becoming co-maintainers of the Standard for Public Code, including the Swedish Public Employment Service. Obviously, of course, pending final details of the governance.
The OSPO alliance kindly offered to provide infrastructure for the continued work. Luckily, the existing infrastructure will continue to exist, so there is no urgent need of that to date.
Besides the governance question, it was expressed that continued knowledge sharing between users of the Standard is important. Partly, the Community built companion can solve this already, by being a place to share good ways of implementing the Standard for Public Code. Similarly, a wish for the community to help disseminating the Standard for Public Code and showing good examples was expressed. Also there the Community built companion could be a solution, not to mention the list of codebases that are compliant. For the rest, using the mailing list to share knowledge and examples might be a good start.
Quite a lot of the call was spent on ideas for finding funding for the Foundation for Public Code to maintain the Standard for Public Code. Some of the ideas that was discussed was:
There was also some self reflection made: that no public organization is yet using the Standard for Public Code as an internal measurement and thus is not a critical path. This was not exactly refuted, but one counter point was that as public organizations like standards (“If we don’t create them, they will legislate them.”), it still has value as an argument in discussions. Also, as there is no blueprint for open projects and the Standard for Public Code shows how it could be done, that is a value in itself. “The structure may be more important than full compliance.”
We will finalize a new GOVERNANCE file based on the feedback from this call and from people giving input beforehand. Thank you all for your valuable viewpoints.
This will be done together with the organizations that during the meeting and separately have stated the intentions to commit person hours to do this work and be part of an executive body.
In order to empower this executive body to have full control over the repository and the path forward, it will be transferred to a new GitHub repository with these people as owners.
]]>In this sixteenth episode, we are joined by Liv Mart Nordhaug, the Chief Executive Officer of the Digital Public Goods Alliance. We will delve into the core functions of the Alliance, explain the criteria and process for recognizing digital public goods (DPGs), and explore the profound impact of the open source ethos on digital innovation. From the 50-in-5 initiative to the ambitious goal of making DPGs the norm for addressing urgent global challenges by 2028, this episode promises an enlightening journey into the future of digital innovation and collaboration.
Links related to the discussion:
You can subscribe to the podcast at open.audio or by searching in your favorite podcast app.
Above, screenshot from the recording.
We are winding down the current composition of the European office of the Foundation for Public Code, because our existing financial model has not proved to be sustainable.
All of the full-time staff associated with our European office are being laid off. We are extremely grateful for their contributions and look forward to potentially working with them in other capacities in the future.
The North American chapter of the Foundation for Public Code will continue to move forward with an expanding set of project-based initiatives and collaborations with public administrations. Additionally, the Foundation will continue to participate in policy conversations around the growing ecosystem of codebase stewardship organizations at the European level.
We had initially built our organizational structure following a Linux Foundation model, including having the capacity to steward codebases and communities within our organization. We asked public administrations to become members of our association, becoming part owners of the Foundation which would function as an external entity that worked closely with internal departments to create sustainable codebases through modern software practices and communities of practice. Thanks specifically to Provincie Zuid-Holland in the Netherlands for becoming our first official member! And to the public sector codebase communities who were eager to meet the Standard and enter into stewardship with us. And to everyone we met along the way who told us this was forward-thinking and necessary.
But despite the enthusiasm and support we encountered, that approach has not worked. Our membership model was not viable. Participation as a member in this type of association was too risky for public administrations. They could not afford to be part owner of an entity which they did not have sufficient control over. Additionally, as we began to work internationally, it became clear that non-Dutch public administrations could not legally even join as a member a body governed by rules of a state outside of their own sovereign jurisdiction. As these limitations became more defined, we attempted to transform our financial and governance models, but we weren’t fast enough to achieve sustainability for our full team. We also dedicated substantial energy to raising funds via institutional philanthropy, but much of this funding is focused on specific causes, rather than on capacity building and process transformation in the public sector.
Of course the pandemic did not help. Many of the government technology teams we were initially working with rightly refocused on rapidly developing responses to devastating national public health crises and damaged national economies, without much bandwidth to think about the longer term issues that stewardship practices represent.
There are also some quite positive reasons why it makes sense for us to adjust the composition of the Foundation for Public Code. The perspective in public administrations toward taking active responsibility in procuring and stewarding their own digital projects has evolved faster than we initially anticipated. There is now a growing movement among European governments toward creating an Open Source Program Office within their organizations, which is a strategy we have long advocated for globally and championed among our members and partners. We are a proud founding member of the OSPO Alliance and have worked with OSPO++ on projects in the European Commission and the United Nations. One of our co-founders has even gone on to become the founder of the first OSPO at a Dutch national ministry. As these initiatives internal to government become more resourced and develop capacity, it is less necessary for the Foundation for Public Code to develop external networks within the open source community on behalf of once insular public organizations.
The North American chapter of the Foundation will continue to engage with the multiple projects and communities of practice it is moving forward, and participate in the developing policy discourse there.
In the European policy context, the Foundation will continue to be involved in multiple conversations and working groups at the European level and in multi-stakeholder frameworks focused on the creation and sustainable development of Open Source Program Office capabilities and the creation of non-profit organizational vehicles for collaboration around digital public goods. We will continue our collaboration with the Digital Public Goods Alliance, Open Futures, and Open Forum Europe, among others. Our Advisory Board will continue to provide strategic guidance.
Based on potential forthcoming grant-based project awards, the Foundation will continue to collaborate with our network of trusted experts on projects towards building capacity in the public sector and creating codebase governance and stewardship organizational structures for digital public goods.
We’re also working to build a distributed community of practice for the Standard for Public Code. We hope to support and assist this network of maintainers and other experts in shepherding the Standard to 1.0, in line with the goal agreed in recent community calls.
The Foundation for Public Code’s role in the ecosystem of digital public goods must evolve. We have worked hard on moving the awareness and practice of codebase stewardship and governance forward and have seen positive results. There will be more news about this transformation in our future posts, but for now we would like to honor the enormous contributions and efforts of the collection of talented and hard-working individuals that are the outgoing employees of the European office of the Foundation for Public Code.

Thank you so much Claus, Elena, Eric, Jan, and Kehinde.
Ben Cerveny,
President
]]>In this fifteenth episode, we talked to Astor Nummelin, Executive Director at Open Forum Europe about how software is getting to a point that it is becoming institutionalised and what we can do in light of this.
Links related to the discussion:
You can subscribe to the podcast at podcast.publiccode.net or by searching in your favorite podcast app.
Above, screenshot from YouTube.
We are aiming for the next video within a month. If you have any suggestions for public coders we should talk to in the future, reach out to us on social media or create an issue in our Projects repository.
]]>In this fourteenth episode, we talked to Åsa Jagre at the Swedish Agency for Marine and Water Management and Konstantin Ay from Intunio working on a Jitsi plugin for Outlook. We focused on up-stream first development and code collaboration.
Unfortunately, Åsa had a bad cough, so we are reading her messages from chat in the interview.
Links mentioned in the show:
You can subscribe to the podcast at podcast.publiccode.net or by searching in your favorite podcast app.
The video is available in a number of places:
We aim to be back early next year year. If you have any suggestions for public coders we should talk to in the future, reach out to us on social media or create an issue in our Projects repository.
]]>In the Standard for Public Code, we have a requirement about translations stating “Any translation MUST be up to date with the English version and vice versa.”. However, many open source projects have community contributed translations, and it is obviously not the intention of the standard to discourage this.
Therefore, we created a proposal for change to address this.
During the call we discussed this proposal and what it implies. One important observation was that it may not matter whether it is the maintainers doing the translations or the community. Rather, it would be better to use terms like authoritative translations - for translations the maintainers have committed to - and courtesy translations, for community contributed or automatic machine translations. Even during the call, some suggestions to the pull request were made to this effect.
One aspect of it that also was mentioned is a contributor’s expectations around translations. It was proposed that the documentation should be clear that missing authoritative translations would block a contribution from being merged into a release. This is essentially the same in practice, but approaches it from a different angle. In the end, the first angle was favored.
Following from this we should update the ‘what developers need to do’ sections to be clear about which translations are authoritative or courtesy.
While we were on the topic of language, we also discussed the first requirement “All codebase documentation MUST be in English.”.
This does not mean it must be only in English; it can have complementary translations or summaries in other languages (even in the same file). They can even be leading, but there must be an authoritative version in English. Making this more clear could make people less hesitant about the standard, both for practical and political reasons.
We also discussed the tricky quesion of how to make clear what version the documentation is for. However, we thought that there is not enough widespread best practices out there to crystalize it into requirements. Possibly, we could make an issue on the implementation guide to add those who are doing good work as examples.
We also noted that requirement “All bundled policy not available in English MUST have an accompanying summary in English.” often takes us time to explain during assessments, so it could possibly be clarified more, but we didn’t immediately have ideas on how to do it.
The next community call for the Standard for Public Code will be 1 February 2024, 14.00 UTC+1.
]]>Increasingly, as public organizations mature in their digitization efforts, they tend to adopt policies of preferentually contributing to existing open source codebases rather than creating yet another codebase from scratch. A while back, we even got a question about what a public organization needs to think about as a contributor to existing open source codebases. That made us pause for a bit, as previously we had mostly been asked to help public organizations make their own codebases open or ready for collaboration.
The Standard for Public Code does not cover the aspect of being a contributor explicitly. Instead, it focuses on the existing community and how they can welcome more contributors. We realized there might be a knowledge gap to fill.
There are many contribution guides out there, and the FreeCodeCamp has collected a fairly comprehensive list of them. This is a good start for anyone that wants to be a helpful contributor. You’ll see there are a lot on the list, but the one-line descriptions will help select the ones of interest.
Additionally, we find these to be particularly useful if you’re contributing on behalf of a larger organization:
Together, these guides cover most aspects that any large organization should consider when contributing to an open source project, so we thought that writing one more guide wouldn’t be that helpful. However, for a contributor representing a public organization, it’s even more important to give maintainers the right expectations about the organization’s current and future involvement, including:
These points may not really fit in to a pull request, so you might want to consider starting a separate discussion in a place where the community is having their discussions (which might be something like a forum, chat or mailing list). Naturally, the importance of being clear about these points increases with the size of your contribution - if you just fix a small bug, then of course this would be excessive.
Healthy open source codebases have a great diversity in their communities and public organizations are likely to be seen as valuable contributors by maintainers, especially as they are uniquely positioned to engage on very long time scales.
Good luck contributing!
]]>We are happy to announce that the call for participation in the FOSDEM 2024 devroom for Public Code and Digital Public Goods has opened.
It’s a devroom dedicated to everyone developing public code - open source code that implements public policy, used for the public good, and by public organizations like governments, public administrations and state corporations. Digital public goods (DPGs) are open-source software, open standards, open data, open AI systems, and open content collections that help meet the Sustainable Development Goals.
The devroom will take place on Saturday, 3 February 2024 in Brussels.
We’re looking for contributions that fit within the main theme of the devroom. Below are some questions to inspire your proposal:
If you have another idea for a talk that you think would fit, please don’t hesitate to let us know! We hope that this will be an opportunity for everyone to meet and exchange ideas about public code and digital public goods around the world.
We offer two types of talk slots:
Please specify in the Submission notes field which type you’re applying for.
We welcome submissions from projects that have never been to FOSDEM before, as well as from ‘old timers’.
Please submit your proposals before 1 December 2023.
The talks are usually recorded on-site. Any recordings will be published under the same license as all FOSDEM content (CC-BY). By agreeing to present in the Public Code and Digital Public Goods devroom, you automatically give permission to be recorded.

/ Foundation for Public Code and Digital Public Goods Alliance, co-organizers of the devroom
]]>We have long thought that to be able to say that the Standard for Public Code is production ready, it should be in use for at least a couple of codebases that meet all the criteria. This would validate that the requirements are proven in practice to be good. We have talked about this in a previous community call and made a note in the roadmap about it. When talking about applying to become an ISO standard in last month’s community call, this naturally became worth reviewing again.
First we talked a bit about what maturity might mean for a standard and when it could be too early to call it production ready. As mentioned in the background, we aimed for it to be used by at few codebases first, and formalizing that in an ambition might radiate proper intent to others. It was also suggested that, ideally, one would even leave some time after the codebases fully comply without requirements being changed or revoked to ensure that they were formulated well enough .
Secondly, we came in to a meta question of why even aim for a version 1.0 release. While the number is not critical per se, it is a strong signal, especially when adhering to semantic versioning, that a product is ready to be used. So there is no external pressure, but more of a wish from the community to be clear about what stage the Standard for Public Code is at. This also led into a subdiscussion about how to apply semantic versioning for a standard in terms of defining what its public API is. We think this aspect is already addressed, but may follow up with more documentation on our thoughts about that, and if it seems to have some general value, also publish a blog post.
Another aspect we discussed was more technical thresholds for moving it into 1.0. For example, it might be useful to look at a 1.0 release in terms of what we don’t want in there. By that we meant listing criteria like ‘the standard should have no critical issues’, or ‘there should be no requirements conflicting with each other’, etc. That way, we can almost get a “countdown” to a release that is objective rather than subjective. However, we feel quite confident that our last year’s issue pruning sessions, and the four years of development of the standard, to the best of our knowledge, have already addressed the examples that we could come up with.
For general information, we also brought up a few other items on the roadmap that are more related to the form than function of the standard, and thus we don’t consider them to be blocking a version 1.0 but are rather something that would be nice to have before that release. These are the two things that we would like to add.
Finally, we briefly discussed if the benefits of getting the standard to become an ISO standard outweigh the added overhead. Obviously, we don’t really know the answer to that question, but as we have been working with a standard for more than four years now, we have seen what weight the ISO label has and gives to the standards under their umbrella. We are also confident just becoming an ISO standard will turn a big spotlight on it.
]]>Harish Pillay gave a presentation on how a standard can get an ISO status. (slides)
Some good takeaways were:
In the discussion that followed we noted that the Standard for Public Code is not at version 1.0.0 yet, and we should wait until then to start the process. While some uncertainty still remains on exactly when that will be, it is likely this is within a year. We also noted that it is not unlikely that the release of 1.0.0 will draw attention, to the point that there might be a couple of more releases shortly after.
For formatting, it should be possible to build workflows that create properly formatted versions on release. For example, a tool to create DOCX files from MarkDown was shared which demonstrates that Pandoc is capable of this.
We also talked about the release cadence and it was clear that not many ISO standards release often. We could not think of any that have several releases per year. While talking about that, it was also noted that not each release has to be submitted for ISO status - it would be possible to only do that for major versions or even selected versions.
There was quite some excitement during the call as it seemed possible for the Standard for Public Code to achieve that status and that the biggest remaining question is about when to start the process.
]]>