Observations and some concerns about contributing to openSUSE
Heisan fellow Geekos, as some might have learnt from my technical discussion on library packages on the Factory mailing list, I am a Debian Developer currently collecting experience with how openSUSE works, both technically and as a community. I am not at all new to SUSE – SuSE Linu 8.2 was my first Linux distribution in 2003, but I left for Gentoo some time around 2008 because because YaST was a major annoyance at that time. First of all, let me say that I am impressed by the developments in openSUSE, especially with Tumbleweed. And, hooray, openSUSE follows standards, and I can just ignore YaST ;)! As it happens, I am also the founder of Teckids, a community with (among others) the goal of helping very young people contribute to open source software. Our youngest contributor was 8 years old, and the average is 12 years. For reference, that's far from any record, given the youngest Linux kernel contributor was a 4 year-old girl [1]. [ If you are not interested in these ramblings, you can skip ] [ the next paragraph; if you wonder "why is this relevant", ] [ read on ] Some might wonder why ot os worthwhile to care about very young people as contributors. Granted, the contribution of 4 year-old Maisa referenced above can be regarded as having very little technical impact on Linux. But that is only one side of the coin. Considering what the impact might have been on Maisa, it probably was of unmeasurable value, because she experienced something very important: If you care, you can do something. The letter "s" being sad at 4 can easily grow to be a driver misbehaving, or community issues being brought to discussion and solved at 14 (although in the particular case, I can find no reference that happened). And, believe me – demonstrating to young people that technology and ocmmunities is something you can care about, and change, and control, is absolutely invaluable in a world where technology concerns spend millions on burrying that fact, making their living by assuming that people blindly consume instead of raising concerns. Therefore, my endeavour of finding out what contributing to openSUSE means to a big part entails looking at how high the barriers are for contributors. After giving you the background above, one might think that what I raise here is only relevant for very young contributors, but in fact, it is for adults as well (the difference being that for the barriers named hereafter, children tend to have no choice, while adults could potentially overcome them with some will and effort). Hence, please bear with me while I bring up some observations and concerns in regard of using and contributing to openSUSE. I'd be happy about any insights or helpful remarks – also, if there are points, or the topic of minimizing barriers towards (young) contributors, that someone would like to discuss with me or Teckids in person, please feel very welcome to ask! openSUSE infrastructure ======================= One (mostly technical) aspect of contributing to openSUSE is its build infrastructure. Coming from Debian, I find it delighting to have one tool do the job. Open Build Service and osc simplify onboarding a lot. I am not particularly fond of versioning tools that are not based on Git, but at least we have one platform used for development, where I can contribute to all packages, with quite well-defined workflows. Registration to OBS (and mailing lists, and everything else) is straight-forward: Single Sign-On is handled by the SUSE IdP Portal, which, to my surprise, does not even require consent to questionable terms of use. Pretty much anyone can register. So, no issues here until now – thanks for being that open towards contributors, and providing a clear path towards technical contributions! SUSE IdP and dependence on SUSE LLC =================================== I assume everyone is quite tired of questions like this ;). All openSUSE services relying on the SUSE IdP Portal for single sign-on is a dead giveaway that there is more dependence on SUSE LLC than "just" sponsoring. As it seems, should SUSE pull the plug at some point, openSUSE would lose money and a lot of server infrastructure, but also a lot of data. I know that plans to found a foundation for openSUSE comes up every now and then. Should that succeed at some point, would control over the single sign-on system be handed over as well? One major concern I have is SUSE's handling of personal data. As I said above, the IdP portal seems to be quite clean (except for a reliance on the Sentry cloud service, which, as I see it, is not GDPR-compliant). However, looking at the SUSE company website, the picture changes drastically: The website includes tracking service from around 25 domains (according to uBlock Origin) – it pretty much feels like a "let's track as much as we can by all means" take. To what extent can a contributor ignore the SUSE website? Is there any point where one would need to use a SUSE web service, except when using the IdP self-service portal? Upstream development on GitHub ============================== While investigating some inner workings of openSUSE, I found that development of openSUSE upstream code (all platforms like OBS and Kiwi, as well as system components, RPM patterns, etc.) is developed on GitHub. GitHub has its fair share of issues regarding software freedom [2], but for now, I'd like to focus on accessibility for contributors. GitHub, in contrast to the SUSE IdP, has strict limitations on who can use it: Explicitly excluded are people younger than 13 years (or 16 years, depending on jurisdiction), as well as citizens of countries currently under embargoes by the US. My concern is that contributions should be equally welcome in all parts of the project, and that the project should welcome everyone, independent of theire age or origin. The only limiting factor should be applicable regulations by law, and as it stands, children far under the age of 13 *can* in fact use online services, if their personal data is not abused there ;). Thus, relying on GitHub unnecessarily imposes additional limitations on who can contribute to the parts of openSUSE that rely on it Are there intentions to move to an independent Git service that is run under the same preconditions as OBS or the mailing lists? Now, I am quite curious to what extend these concerns might have already been discussed in the past, and how others in the community look at them. Thanks, Nik [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... [2] https://sfconservancy.org/GiveUpGitHub/
On Di, Aug 22 2023 at 16:45:57 +0200, Dominik George
openSUSE infrastructure =======================
One (mostly technical) aspect of contributing to openSUSE is its build infrastructure. Coming from Debian, I find it delighting to have one tool do the job. Open Build Service and osc simplify onboarding a lot. I am not particularly fond of versioning tools that are not based on Git, but at least we have one platform used for development, where I can contribute to all packages, with quite well-defined workflows.
Registration to OBS (and mailing lists, and everything else) is straight-forward: Single Sign-On is handled by the SUSE IdP Portal, which, to my surprise, does not even require consent to questionable terms of use. Pretty much anyone can register.
We do have terms of use, to be quite honest it's a bad thing we don't require people to actually see them and agree to them :D
So, no issues here until now – thanks for being that open towards contributors, and providing a clear path towards technical contributions!
SUSE IdP and dependence on SUSE LLC ===================================
I assume everyone is quite tired of questions like this ;).
All openSUSE services relying on the SUSE IdP Portal for single sign-on is a dead giveaway that there is more dependence on SUSE LLC than "just" sponsoring. As it seems, should SUSE pull the plug at some point, openSUSE would lose money and a lot of server infrastructure, but also a lot of data.
I know that plans to found a foundation for openSUSE comes up every now and then. Should that succeed at some point, would control over the single sign-on system be handed over as well?
My usual answer is Hell Yes!, but I have some bad news for you, build.opensuse.org is very much not hosted and maintained by openSUSE either. Granted, none of the infrastructure is hosted by openSUSE, since there's currently no such concept as an openSUSE server (yet at least, there is some work being done to get at least to that point), but even if that was the case it will still existing within a SUSE data center. Build Service and openQA are likely the two largest services within opensuse.org domain, and they are both in essence maintained and run by SUSE without any involvement of openSUSE in terms of infrastructure (though you can contribute to the codebase of both). There are also quite a lot of servers required to run those services. There are also a few services under opensuse.org that can only be used by SUSE Employees and/or function as a service explicitly for SUSE events. The two examples that I'm thinking of right now are ci.opensuse.org and hackweek.opensuse.org. Not exactly sending that great of a message to the community with that :P
One major concern I have is SUSE's handling of personal data. As I said above, the IdP portal seems to be quite clean (except for a reliance on the Sentry cloud service, which, as I see it, is not GDPR-compliant). However, looking at the SUSE company website, the picture changes drastically: The website includes tracking service from around 25 domains (according to uBlock Origin) – it pretty much feels like a "let's track as much as we can by all means" take.
To what extent can a contributor ignore the SUSE website? Is there any point where one would need to use a SUSE web service, except when using the IdP self-service portal?
You shouldn't have to
Upstream development on GitHub ==============================
While investigating some inner workings of openSUSE, I found that development of openSUSE upstream code (all platforms like OBS and Kiwi, as well as system components, RPM patterns, etc.) is developed on GitHub. GitHub has its fair share of issues regarding software freedom [2], but for now, I'd like to focus on accessibility for contributors.
Patterns are in OBS nowadays. This repo should be archived but nobody ever remembers to do that :P
GitHub, in contrast to the SUSE IdP, has strict limitations on who can use it: Explicitly excluded are people younger than 13 years (or 16 years, depending on jurisdiction), as well as citizens of countries currently under embargoes by the US.
My concern is that contributions should be equally welcome in all parts of the project, and that the project should welcome everyone, independent of theire age or origin. The only limiting factor should be applicable regulations by law, and as it stands, children far under the age of 13 *can* in fact use online services, if their personal data is not abused there ;). Thus, relying on GitHub unnecessarily imposes additional limitations on who can contribute to the parts of openSUSE that rely on it
I suspect that in accordance to some US regulation, we also shouldn't accept people creating accounts under 13 years old (I think it's COPPA), and our Terms of Site do state that we follow US law for all the pages pretty plainly https://en.opensuse.org/Terms_of_site. This also means that indeed citizens of countries that are embargoed by the US are also not allowed to use the services :D I do think it's unfair for this to be the case, and I think it would be nice to have a discussion about this, because I do think we benefit from having young contributors, I have experience helping quite a few young people contributing to the project myself. This feels like something that is brought up to the board's attention and discussed with SUSE Legal with involvement of the community over some span of time to arrive at some better terms of site though. However, my very much non legal advise is that you can lie on the internet and likely nobody will stop you from doing that. My date of birth for the longest time was in 1988 instead of 1999 because I wanted to sign up to some 18+ service at 7 years old. I am still not behind bars for that, and I doubt anyone will be going after me for ever doing that.
Are there intentions to move to an independent Git service that is run under the same preconditions as OBS or the mailing lists?
No, and there's quite a few reasons for this. Most of it that it's easier to pay somebody to take care of this kind of stuff than host it yourself. And GitHub already doesn't cost anything, the only cost is the CI on top of it. There is code.opensuse.org, but I have doubts that we would ever migrate all the code from github over because it ends up being quite a disruptive process for very little practical gain if any. LCP [Jake] https://lcp.world/
Hi Jacob, thanks for taking the time to reply!
We do have terms of use, to be quite honest it's a bad thing we don't require people to actually see them and agree to them :D
Indeed.
Patterns are in OBS nowadays. This repo should be archived but nobody ever remembers to do that :P
Hmm, and probably also remove the Upstream URL pointing to GitHub in the patterns source RPM currently in Factory.
I suspect that in accordance to some US regulation, we also shouldn't accept people creating accounts under 13 years old (I think it's COPPA),
That is a common misconception. COPPA does **not** forbid to let people under 13 years of age in. It only forbids to abuse their data for marketing purposes or to direct commercial offers at them. If you do neither, you can accept them. And even if you can't, you can still accept parental consent. GitHub locks children out without offering them to show parental consent, because they do abuse personal data **and** do not invest time in collecting and validating parental consent. For a project like openSUSE, that work could, should we get to this point at some time, be sourced out to a trusted partner (our Teckdis organisation would and is capable of doing such things). But, if you only ask for an e-mail address and a username, and then do nothing with that data except allow them to use the build service and mailing lists exactly for what they are intended for, then there's not even a need to get parental consent (you still could require it to be on the safe side though). The same is true for the EU under GDPR.
and our Terms of Site do state that we follow US law for all the pages pretty plainly https://en.opensuse.org/Terms_of_site. This also means that indeed citizens of countries that are embargoed by the US are also not allowed to use the services :D
Only if these services are of commercial interest. If they aren't, then the embargoes are not effective. That, of course, is a very strong argument for completely separating openSUSE from SUSE.
I do think it's unfair for this to be the case, and I think it would be nice to have a discussion about this, because I do think we benefit from having young contributors, I have experience helping quite a few young people contributing to the project myself. This feels like something that is brought up to the board's attention and discussed with SUSE Legal with involvement of the community over some span of time to arrive at some better terms of site though.
Thank you very much for supporting young contributors! If we need at some point to work on policies and terms, and expertise in working with young people is needed or helpful, we (Teckids) and I will be happy to collaborate.
However, my very much non legal advise is that you can lie on the internet and likely nobody will stop you from doing that. My date of birth for the longest time was in 1988 instead of 1999 because I wanted to sign up to some 18+ service at 7 years old. I am still not behind bars for that, and I doubt anyone will be going after me for ever doing that.
Sure. But, as a pedagogue **mentoring** children, this is not something I can advise them on ;). Cheers, Nik
On 8/23/23 00:15, Dominik George wrote:
Heisan fellow Geekos,
SUSE IdP and dependence on SUSE LLC ===================================
To what extent can a contributor ignore the SUSE website? Is there any point where one would need to use a SUSE web service, except when using the IdP self-service portal?
As someone who's been a contributor for 12 years, and a SUSE employee for 7+ of that, the only time i've ever had to actively use the website is when I was applying for a job. The SUSE Website is completely independent of all the infrastructure openSUSE uses including the login etc.
Upstream development on GitHub ==============================
While investigating some inner workings of openSUSE, I found that development of openSUSE upstream code (all platforms like OBS and Kiwi, as well as system components, RPM patterns, etc.) is developed on GitHub. GitHub has its fair share of issues regarding software freedom [2], but for now, I'd like to focus on accessibility for contributors.
GitHub, in contrast to the SUSE IdP, has strict limitations on who can use it: Explicitly excluded are people younger than 13 years (or 16 years, depending on jurisdiction), as well as citizens of countries currently under embargoes by the US.
My concern is that contributions should be equally welcome in all parts of the project, and that the project should welcome everyone, independent of theire age or origin. The only limiting factor should be applicable regulations by law, and as it stands, children far under the age of 13 *can* in fact use online services, if their personal data is not abused there ;). Thus, relying on GitHub unnecessarily imposes additional limitations on who can contribute to the parts of openSUSE that rely on it
Are there intentions to move to an independent Git service that is run under the same preconditions as OBS or the mailing lists?
Now, I am quite curious to what extend these concerns might have already been discussed in the past, and how others in the community look at them.
In practice as a project we don't specify which tools contributors / teams use. If you go back say 10 years github was clearly the best tool going around if you consider the alternatives were projects such as sourceforge that really haven't kept up. As such contributors chose to start putting projects there, which then of course snowballs to if X and Y are already on gjthub then we may as well put Z there as well. The Citizens being embargoed certainly has been discussed before but in reality migrating to a different service doesn't really change that unless we were to self host in a country that doesn't embargo anyone (i'm not sure how many such countries exist). Either way as LCP pointed out as a project we have neither the resources or volunteers at the moment to make moving to a self hosted solution a viable and long term dependable / reliable solution. To the best of my knowledge i've never seen the age issue raised before which I guess is either because we haven't had contributors that young or if we have they've ignored the terms of service. At the end of the day, one of the best features of github is that its relatively easy to migrate away from should openSUSE as a project make a decision that its terms of service are unacceptable. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
participants (3)
-
Dominik George -
Jacob Michalskie -
Simon Lees