Open Source Working Group Minutes RIPE 88

Thursday, 23 May 2024, 14:00-15:30 (UTC+2)
Chairs: Marcos Sanz, Martin Winter, Sasha Romijn
Scribe: Sean Mottles
Status: Draft

A. Administrative Matters

The presentation is available at:
https://ripe88.ripe.net/wp-content/uploads/presentations/94-oswg-agenda-ripe88.pdf

Martin asked the audience to raise their hand if they had to make a difficult decision in attending the Open Source Working Group or Routing Working Group since they were scheduled at the same time. About 10 to 15 audience members raised their hands.

There were no other questions.

B. Chair Selection Process Review

Martin Winter, Co-Chair

The presentation is available at:
https://ripe88.ripe.net/wp-content/uploads/presentations/90-WG-Chair-RIPE87.pdf

Ondřej Surý, ISC, said that it was reasonable to require the future chair to attend the meetings as well as adding a commitment to attend future meetings.

Martin replied that the existing rules state one chair should be at each meeting at a minimum, then asked the audience if they had an opinion on that requirement being satisfied via online or in person attendance.

Ondřej Surý, ISC, supported on-site attendance, acknowledging that it may narrow the candidate pool but stressed that it is important to get to know the community. He added that it might be worth adding meeting attendance as a voting requirement.

Jim Reid, representing himself, disagreed with the idea of a unified working group selection process. He was a proponent of letting the working groups decide how to do it themselves as long as it was a fair and open selection process. He continued by disagreeing with voting for working group chairs in general, citing the disqualified candidate as an example of how this process can be gamed. He applauded the action taken by the chairs in this case and suggested that including the RIPE Chair or Vice-Chair could be a second opinion on cases similar to what was presented. He continued by supporting common sense action instead of creating more elaborate requirements or complex mechanisms that could potentially be gamed as well.

Martin added that he hoped Jim had spoken to Mirjam about the unified policy as it may at least get a draft for the different working groups.

Mirjam Kühne, RIPE Chair, wanted to clarify that when Martin used the word “voting” in his presentation he actually meant Statements of (Non-)Support which was a longstanding process in Working Groups, and that in this case it did not work.

An attendee suggested a nomination committee, similar to what is done at APNIC, where statements of intent as well as RIPE Meeting attendance are verified by this two or three-person committee.

Maria Matějka, BIRD / CZ.NIC, added that common sense is not common and doesn’t work under stress. Processes exist for situations like this, and common sense can be used to create processes. She also requested that additional qualifications be added to people’s biographies as a better way to gauge attendance than relying on an individual’s own ability to keep track.

Martin asked in reply for clarification on if Maria meant that there should be more strict rules and planning for everything ahead of time.

Maria responded that she would like to see a bit more policies, not necessarily strict, and that rules look like the right way to go.

Shane Kerr, IBM, supported a unified policy as differences between working groups would be confusing for outsiders or newcomers and reduces the legitimacy of the Working Group Chairs and the community. He added that gateways to putting yourself forward will be off-putting and reduce legitimacy as it will feel like a closed cabal trying to keep outsiders out, not necessarily that it would happen, but that perception is important. He continued by saying that we shouldn’t be terrified of voting, but consensus-driven decision making has its own problems as well.

There were no further questions.

C. Open Source QA Process

Petr Špaček, Internet Systems Consortium

Presentation:
https://ripe88.ripe.net/wp-content/uploads/presentations/93-pspacek-open-source-qa-and-risk-mitigation.pdf

Petr spoke about the perception and mitigation of risks in open source projects, and shared the results of a Working Group participant survey. He used BIND 9 as an example and opened the discussion to the working group.

Oleksij Samorukov, NetArt Group s.r.o, added that developers and operators of the software have different needs and those differences do not mean that what ISC is doing for QA is wrong, just that the target audience is in a different position than ISC developers. He added that it’s helpful for upstream to work with distributions rather than just publishing your own repositories, and making sure distributions apply patches or version numbers appropriately is also a big help to users.

Marcos San, DE-CIX, thanked Petr for organizing the survey and added users and developers are in a complementary situation where each side has their own expertise. He continued by thanking ISC for presenting this information and how open they are with their processes.

Petr, in response to Marcos San’s feedback, asked if it means that the top priority for users are the things they do every day and not necessarily the behind the scenes work.

Marcos San, DE-CIX, said yes, it’s a good way to word it and there’s some truth to it.

Jim Reid, representing himself, agreed with the previous commenters. He continued by saying he doesn’t concern himself with these factors because of the already-established trust of ISC, and he knows how to contact them if there are issues. He placed greater issue on the distributions where QA processes might not be as robust as ISC’s, as well as external dependencies outside their control like openssl. He added that the lack of consistency in QA is problem with open source in general, where labour and resources are not spread evenly. He finished by praising the presentation, and asked if ISC can publish the presentation as a blog post with the added benefit of possibly encouraging others to do the same.

Moin Rahman added that when thinking of the intended users of this software in particular, it will mostly be system administrators who put a much higher importance on documentation and end user resources, and may rarely if at all interact with the backend processes.

William Toorop, NLNET Labs, thanked ISC for this work, and added that it’s very valuable for software vendors, software makers, and end users.

Alistair Woodman, NetDEF, also thanked ISC for their work. He compared what Petr presented to what the car industry goes through, where end user’s needs appear to shift to new features, but don’t worry about how the seatbelts work because they assume it’s a solved problem. He thanked ISC for their worked and encouraged them to keep making sure the seatbelts work.

There was still time remaining after the last question, so Petr asked the audience how they felt about distributions applying hand selected patches to software delivered via tarball from upstream sources, as opposed to upgrading to a new minor version of the same software. He added that one school of thought which says that hand picked patches results in better quality software where there is a stable version that gets progressively more reliable, versus the idea that if any change happens at all it indicates a version change.

Oleksij Samorukov, NetArt Group s.r.o, responded that from the perspective of a smartmontools developer dislikes the hand applied patches as their application is inconsistent and is difficult to provide assistance to users of a distribution that does this. He added that the current software environment is very dynamic and changes frequently as opposed to earlier years where there was more hesitation in changing things after a distribution cut a release. Exceptions to this, for example, are small patches applied by distributions outside of the core software, like init scripts. He also suggested a practice done by the homebrew project where if you want to apply a patch you must show that you attempted to upstream it, show that the upstream vendor declined the patch because it does not make sense to include it, or show that it was accepted upstream and is not yet released, then you can apply it.

Ondřej Surý, ISC, said that it is a fallacy trying to keep software stable with patches. It creates some problems, when upgrading to another minor version for example, but for the complex software it’s not helpful. For things he maintains in Debian, like PHP and BIND, an agreement was made with the Debian release and security teams that they push the latest minor versions to Debian. He added that Ubuntu does not take this approach and that they have observed it causing issues with complex software.

Maria Matejka, BIRD and CZ.NIC, added that they are actively trying to upstream distribution patches and integrate them, or convince those maintainers to remove the patches. She added that sometimes this approach works, sometimes it doesn’t. She also agreed with previous commenters that today’s software is much more complex and applying random patches is not doable anymore for a variety of reasons.

Shane Kerr, IBM, asked what to do when organizations have strong policies on version numbers where the amount or size of patches doesn’t necessarily matter, as long as the major version number remains the same, more commonly practiced in enterprise software, especially when workers at these organizations do not have a lot of power over these policies.

D. Contribution and Credits Policy for Open-Source Projects

Maria Matejka, BIRD and CZ.NIC

Maria shared a template created on a model policy on crediting contributions to open source software and projects.

Presentation:
https://ripe88.ripe.net/wp-content/uploads/presentations/69-ripe88_osswg_talk.pdf

Shane Kerr, IBM, asked for recommendations when going back and adding documentations about previous contributors for projects without a policy that didn’t keep track.

Maria responded saying that it depends. She continued by giving examples on what could be done, reconstructing the history, stating that there is a historical point where that information is no longer available and from that point you will keep track, stating that there was an attempt to reconstruct it and if people missed would like to be added they could submit a pull request. She finished by saying that it’s about where the information is and how much time it takes.

It was asked to continue the discussion on the BCP Suggestion draft via the mailing list.

There were no further questions.

E. Lightning Talks

E. 1 Roadblocks to Open Source in Asia-Pacific

Martin Winter, NetDef

Presentation:
https://ripe88.ripe.net/wp-content/uploads/presentations/91-RoadblocksToOpenSource.pdf

Martin shared an overview of the obstacles encountered in running open source projects in the Asia-Pacific region

E. 2 The RIPE NCC Community Projects Fund

Gergana Petrova, RIPE NCC

Presentation:
https://ripe88.ripe.net/wp-content/uploads/presentations/116-Gergana-Petrova-CPF-OSWG-Lightning-Talk.pdf

Gergana explained how the RIPE NCC Community Projects Fund operates and invited those interested to apply before the deadline.