Jekyll2024-04-28T20:04:47+00:00https://blog.publiccode.net/feed.xmlBlog for Public CodeHome to the Blog for Public Code, where blog posts are planned and collectively written.Notes from the Standard for Public Code community call - 26 March 20242024-03-27T00:00:00+00:002024-03-27T00:00:00+00:00https://blog.publiccode.net/community%20call/2024/03/27/notes-from-community-call-26-march-202426 March 2024 Standard for Public Code community call

Attendees

  • Jan Ainali
  • Eric Herman
  • Claus Mullie
  • Nico Rikken
  • Johan Groenen
  • Silona Bonewald, Foundation for Public Code NA, OSPO Alliance, Os-Gov at Eclipse Foundation
  • Maria Dalhage, Swedish Public Employment Service and Community manager NOSAD
  • Ian Forrester
  • Boris Baldassari, Eclipse Foundation
  • Matti Schneider
  • Joakim Verona, Swedish Public Employment Service
  • Max Carlson
  • Nick Gates
  • Jonas Södergren, Swedish Public Employment Service

Updates from the Foundation

Notes

Background

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.

Discussion

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:

  • Trainings
  • Certification
  • Grants
  • Consultancy
  • Donations (mostly state/towns/users of the standard)

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.”

Next steps

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.

]]>
Jan Ainalihttps://publiccode.net/who-we-are/team/jan-ainali.html
Episode sixteen of Let’s talk about public code! - Liv Marte Nordhaug, Digital Public Goods Alliance2024-03-12T00:00:00+00:002024-03-12T00:00:00+00:00https://blog.publiccode.net/news/2024/03/12/episode-sixteen-of-lets-talk-about-public-codeEpisode sixteen of Let’s talk about public code!

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.

Screenshot from the video with Liv, Eric and Jan Above, screenshot from the recording.

]]>
Jan Ainalihttps://publiccode.net/who-we-are/team/jan-ainali.html
Changes at the Foundation for Public Code Europe office2024-02-28T00:00:00+00:002024-02-28T00:00:00+00:00https://blog.publiccode.net/news/2024/02/28/changes-at-the-europe-officeChanges at the Foundation for Public Code Europe office

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.

Challenges along the way

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.

Maturing public sector open source ecosystem

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.

Looking to the future

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.

Europe office in a grid

Thank you so much Claus, Elena, Eric, Jan, and Kehinde.

Ben Cerveny,

President

]]>
Ben Cervenyhttps://publiccode.net/who-we-are/team/ben-cerveny.html
Episode fifteen of Let’s talk about public code! - Astor Nummelin, Open Forum Europe2024-01-30T00:00:00+00:002024-01-30T00:00:00+00:00https://blog.publiccode.net/news/2024/01/30/episode-fifteen-of-lets-talk-about-public-codeEpisode fifteen of Let’s talk about public code!

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.

Screenshot from the YouTube video with Astor and Jan Above, screenshot from YouTube.

What’s next?

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.

]]>
Jan Ainalihttps://publiccode.net/who-we-are/team/jan-ainali.html
Episode fourteen of Let’s talk about public code! - Åsa Jagre and Konstantin Ay, Jitsi Outlook plugin2023-12-18T00:00:00+00:002023-12-18T00:00:00+00:00https://blog.publiccode.net/news/2023/12/18/episode-fourteen-of-lets-talk-about-public-codeEpisode fourteen of Let’s talk about public code!

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.

Konstantin, Åsa, Eric and Jan chatting in a video chat grid

Where can I find the video?

The video is available in a number of places:

What’s next?

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.

]]>
Jan Ainalihttps://publiccode.net/who-we-are/team/jan-ainali.html
Notes from the Standard for Public Code community call - 7 December 20232023-12-11T00:00:00+00:002023-12-11T00:00:00+00:00https://blog.publiccode.net/community%20call/2023/12/11/notes-from-community-call-7-december-20237 December 2023 Standard for Public Code community call

Attendees

Updates from the Foundation

Notes

Background

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.

]]>
Jan Ainalihttps://publiccode.net/who-we-are/team/jan-ainali.html
How to be a good codebase contributor as a public organization2023-11-20T00:00:00+00:002023-11-20T00:00:00+00:00https://blog.publiccode.net/codebase%20stewardship/2023/11/20/good-public-contributorHow to be a good codebase contributor as a public organization

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.

illustration of a purple hand holding holding a heart with containing HTML code symbols, against a peach background

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:

  • Your organization’s current scale of commitment. What is your headcount or budget?
  • What is your organization’s ability to participate in the future maintenance of the contribution?
  • How formalized is your involvement? Is there specific support from policy and or management? Or are you in a situation such that if the role of one engaged contributor changes, the involvement may dry up?
  • What is the expected duration of your contributors? Are the contributors from your organization short term contractors or embedded experts with long term contracts?
  • Will your contributors be paid to gain depth and become reviewers over time?
  • What policy objectives, if any, are being addressed by your participation or contributions, for example adding GDPR compliance, or accessibility requirements, or a feature that was a political campaign promise?
  • The goals and aspirations of your organization. Do you plan further contributions already, and if so, of what kind? How are you using the codebase, and what is your scale of deployment/implementation?
  • How is your orgainzation able to contribute? Code and documentation contributions are great, but many open source communities can also benefit from other forms of support, including community management, financing, help with governance, marketing, endorsements, and so on.

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!

]]>
Eric Herman, Jan Ainali
FOSDEM 2024 Public Code and Digital Public Goods devroom Call for Participation2023-11-13T00:00:00+00:002023-11-13T00:00:00+00:00https://blog.publiccode.net/news/2023/11/13/fosdem-2024-public-code-and-digital-public-goods-devroom-call-for-proposalFOSDEM 2024 Public Code and Digital Public Goods devroom Call for Participation

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:

  • have you tried to replicate or co-develop a codebase with another public organization? what did you learn along the way?
  • do you have any procurement or governance models (or hacks!) that helped you use, reuse or co-develop public code or a digital public good?
  • are you working on or using an amazing DPG or public code project with strong reuse potential that everyone should know about?

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:

  • 30 minutes (20 minutes presentation + 10 minutes Q&A)
  • 5 minute lightning talks, perfect for presenting your project, but other lightning talk topics are also welcome!

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’.

Submission process

Please submit your proposals before 1 December 2023.

  • Head to the FOSDEM 2024 pretalx website. This has replaced Pentabarf!
  • Follow the instructions to create an account.
  • Once logged in, select “submit a CFP”.
  • Your submission must include the following information:
    • Proposal title
    • Track - Select Public Code and Digital Public Goods from the drop down list
    • Abstract (will appear on the FOSDEM schedule)
    • Description (will appear on the FOSDEM schedule)
    • Submission notes - Write if you want to give a Lightning talk or Presentation here. Add any other details as needed.
    • Session Image (optional new feature): Use this if you want an illustration to go with your proposal. Please do not upload files larger than 10.0 MB!
    • Additional speaker
    • Click Continue or you can save and come back to it
    • About your proposal: Which open source license do you use?
      • FOSDEM is an open-source software conference, please specify which OSI approved license your proposal uses.
    • Extra review material, only shown to reviewers (not published when scheduled)
    • Extra Contact details (optional)
    • Click Continue or you can save and come back to it
    • Finally, tell us your name
    • Biography
    • Availability

Important dates

  • 1 December 2023: deadline for submission of proposals
  • 15 December 2023 or before: announcement of final schedule
  • 3 February 2024: devroom day - You must be available in person to present your talk

Recordings

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 logo      DPGA logo

/ Foundation for Public Code and Digital Public Goods Alliance, co-organizers of the devroom

]]>
Jan Ainalihttps://publiccode.net/who-we-are/team/jan-ainali.html
Notes from the Standard for Public Code community call - 2 November 20232023-11-06T00:00:00+00:002023-11-06T00:00:00+00:00https://blog.publiccode.net/community%20call/2023/11/06/notes-from-community-call-2-november-20232 November 2022 Standard for Public Code community call

Attendees

Updates from the Foundation

Notes

Background

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.

Notes

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.

  1. The ability to “deep link” directly to a requirement. We work on that in issue 327 but also got a tip to look at legislative linking standards like the European Legislation Identifier (ELI) and the blog post A love letter to the Parliamentary Counsel of the world which has some extensive writing on the topic. Our aim for now is that deep links like these should be stable over time so that we can avoid breaking links even if requirements are reordered or deleted.
  2. The ability to find older versions on the website. Currently, older versions are available on GitHub, but they are not easy to read or to link to. Later, when we have several versions after 1.0 and especially if some of them are ISO standards, it will be more important to be able to refer to a criterion of a specific version of the standard.

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.

]]>
Jan Ainalihttps://publiccode.net/who-we-are/team/jan-ainali.html
Notes from the Standard for Public Code community call - 5 October 20232023-10-09T00:00:00+00:002023-10-09T00:00:00+00:00https://blog.publiccode.net/community%20call/2023/10/09/notes-from-community-call-5-october-20235 October 2023 Standard for Public Code community call

Attendees

Updates from the Foundation

Notes

Harish Pillay gave a presentation on how a standard can get an ISO status. (slides)

Some good takeaways were:

  • There is a Joint Technical Committee with mentors that help organizations through the process.
  • As the Standard for Public Code is not starting from scratch, it can jump a few steps in the process so that it will likely take 6-9 months.
  • The biggest effort will be in converting the standard to the required formats (for example, ISO doesn’t use IETF RFC 2119), but there are templates and guidance to make this easier. This work is done by the standard’s existing community.
  • Standards need to be submitted in PDF and Word formats (templates).
  • The review is mostly for formatting.
  • The process is free of charge.
  • When a standard is released in a new version, it needs to go through a review process again.
  • If a standard was open, it can stay open and does not need to be paywalled.

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.

]]>
Jan Ainalihttps://publiccode.net/who-we-are/team/jan-ainali.html