On Fri, Jan 22, 2021 at 6:26 PM Ljubomir Ljubojevic <centos at plnet.rs> wrote: > > On 1/22/21 4:53 PM, Brian (bex) Exelbierd wrote: > > On Thu, Jan 21, 2021 at 12:16 PM redbaronbrowser via CentOS-devel > >> Do they get a louder voice for paying the bills? > > > > Red Hat's louder voice is based on two different components. The > > primary form of this "louder voice" is that Red Hat employs a ton of > > engineers who contribute directly to the CentOS Project or the > > codebases that become elements of CentOS Project outputs. We speak > > loudly in the sense that we can choose what we do and what we don't > > do. In the same way committers in a project have a louder voice than > > other contributors as they decide what the project will and will not > > do. This is the way Open Source works. > > > There is a silver lining here because at least few people offered to be > active in producing CentOS, but were refused for various reasons. What I > understood from those exchanges, main reason was CentOS dev team did not > want anyone else to know how they are doing things, they wanted tight > control. Even requests dev teams publish how they produce CentOS was > refused. I never said anything because it did not affect me. Red Hat also didn't say anything here because it didn't affect it's needs, the same as you. We wanted a development platform for the SIG and other layered work. This is part of the cognitive dissonance we maintain with communities we sponsor. In general we leave a community alone to self-govern. We only act as a company when we need to protect the community and by extension the company from liabilities or when our direct contribution goals are impacted. In the first case we use positions like the Liaison to talk to the governing body and if required (and it NEVER has been so far) our veto. In the second case we show up and make our case in the various bodies that manage the code. You can see this mostly in CentOS SIGs or in Fedora because CentOS Linux was a rebuild and generally did not make or accept changes that weren't in the code RHEL had published. Now that we are all working on CentOS Stream there are some competing interests in play when it comes to build systems, but I think that ultimately we will have more access and transparency. WARNING: I am not a distribution build engineer so I am speaking in generalities here. Our build systems and software has, in some cases, not changed to keep up with modern development practices or needs. Does this make it bad or wrong? No. Does it offer room for improvement? Absolutely. Looking at some of the work individual contributors have done to align build processes and software across distributions and third-party repos, I think that it is exciting to be able to use CentOS Stream as a platform for thinking about our entire build process. This won't be fast or easy as we have to be very careful, but it should be possible in a way that CentOS couldn't before. This is possible explicitly because CentOS now is ahead of RHEL, not behind it. It is building tomorrow, not rebuilding yesterday. The other interest though is around the actual act of making the distribution, the "turning of the crank." Here Red Hat has very specific security interests and we need to limit the ability to do specific build tasks to specific people. Having spoken to the CPE team, the engineering organization in Red Hat that is tasked with our infrastructure contribution to CentOS, I know they are looking at every option to open up what they can. One thing they have to do is to get new authentication and other practices in place, which CentOS has traditionally not had in this fashion, to allow the right access (again - I am speaking in generalities here and glossing over detail. Detail discussions are not going to be useful if I am participating :D). They will tell you that in internal meetings I am constantly harping on the need to get SIGs greater controls and build opportunities, for example. That internal meetings comment raises a great question around how to get more community participation. There is an infrastructure SIG spinning up to ensure that there is a forum for these conversations. I'd also love to see, if we can technically do it, a SIG focused on improving build systems, with an eye toward making the deliberate incremental change that lifts all of us (Fedora, CentOS, RHEL, EPEL. elrepo, etc.). > > So this is a case of "secretive group" deciding and controlling entire > project and naturally anyone else had no say in what is done beyond > proposing something on the mailing list or forums and hoping group in > control will accept their reasoning. > > Again, as far as I got the no-cost distro I was fine with how it was > run, but saying anyone else could have a say/voice is false. AIUI, the way the CentOS Linux distribution is produced as a direct artifact, your statement is generally true. I suspect this was largely driven by the rebuild nature of CentOS Linux and the fact that the engineering the project did was almost exclusively in service rebuilding, not creating software. An opportunity we have, as a community, is to really embrace the full definition of contribution. If you look at Fedora, as an example, we have lots of contributors who have never written a line of code or packaged a piece of software. Their contribution is invaluable and important. CentOS can have that too, if it wants it. I hope that this will be another area where the community shows up and the project thrives. Innovation comes in many forms, let's go find the ones we want to tackle, whether code or non-code activities. regards, bex