Originally published at: FESCo election: Interview with Stephen Gallagher (sgallagh) – Fedora Community Blog
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 21 May and closes promptly at 23:59:59 UTC on Thursday, 3 June 2021.
Interview with Stephen Gallagher
- Fedora Account: sgallagh
- IRC: sgallagh (found in #fedora-devel, #fedora-modularity, #fedora-eln, #fedora-server)
- Fedora User Wiki Page
Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?
I have served on FESCo almost continuously since 2011 (I took one term off in that time). I’ve been heavily involved with Fedora’s direction, having participated in the Fedora Editions Initiative, the Fedora Modularity Initiative, the creation of Fedora ELN and many other projects. Serving on FESCo has provided me with a unique opportunity to get involved with parts of the project beyond my own areas of expertise and as a result I think it has provided me with the opportunity to turn those experiences into better holistic decision-making for FESCo.
Over the next term, I plan to spend most of my time improving the interaction between CentOS Stream, Fedora ELN and Fedora Server. This will require a great deal of cross-functional work, from packaging and release engineering all the way up to documentation, Fedora Magazine and Websites. From FESCo, I’ll be able to coordinate this with greater efficiency.
How do you currently contribute to Fedora? How does that contribution benefit the community?
Currently, I serve on FESCo, I maintain several important packages in Fedora (such as the Node.js interpreter) and I regularly act as a Fedora representative both in person at events and on social media. In my day-job, I’m heavily involved with the preparation of future releases of Red Hat Enterprise Linux, and I constantly advocate for increased openness and Fedora involvement with the creation of RHEL. In turn, I work tirelessly inside Red Hat to encourage greater contributions to the Fedora Project. Notably, during this last year, I’ve helped to found the Fedora ELN project which provided the springboard for the new CentOS Stream 9: the public development channel for Red Hat Enterprise Linux 9.
How should we handle cases where Fedora’s and Red Hat Enterprise Linux’s needs conflict in an incompatible way?
(Full disclosure; I’m copying this verbatim from my response last term)
There’s a delicate balance to be struct between the Fedora Project and its principal sponsor, Red Hat. Red Hat provides tremendous support in terms of personnel, hardware, event funding and much more. As a for-profit company, it of course is not doing this without some expectations of a return on this investment. For years, Fedora has benefited Red Hat by doing a lot of the hard work of developing an operating system, not just by integrating all of the disparate software packages but also by building up a community of users, developers and other enthusiasts.
The Red Hat and Fedora partnership has seen the Linux community drive immense change over time. Fedora provided a place for new, disruptive technologies like systemd and Cockpit to establish themselves and grow into something that was useful to Red Hat’s business users. At the same time, we’ve had the opportunity for Fedora to “fail fast” and prove some ideas to be dead-ends (OpenLMI and Server Roles come to mind as projects I worked on).
Yet other times, we have faced disagreements over the best way to proceed. There are two particular examples of this I would like to address, both coincidentally trying to solve the classic “Too Fast / Too Slow” problem.
The first attempt made was Software Collections (AKA SCLs) which attempted to create a specialized system for creating RPMs that could be built to install and run either in their traditional filesystem locations or in special parallel-installable locations. This solution was developed within Red Hat (with little communication with the Fedora Project) and when it was presented, the Fedora community disliked the approach and ultimately it was forbidden to use SCLs in Fedora. Thus, a huge amount of development time was wasted and Red Hat was left in the unenviable position of supporting a technology that failed to gain upstream support for years.
The next such attempt at addressing the same problem was with the Modularity Initiative. In this attempt, we made far more effort to develop the technology in Fedora first. Ultimately, due to pressures from within Red Hat, we rushed some key features into Fedora (such as default module streams) that in hindsight were plainly not ready. Even today, we are still dealing with the fallout of that premature deployment. Yet, I still feel that we succeeded in a major way with Modularity: we developed it in public and received a great deal of feedback, much of which was incorporated. The fact that the first deliverable fell short of our lofty ambitions was less important to me than the fact that we had done it in such a way that the effort was not a total waste.
So, where am I going with this? Well, one problem I’ve seen that has developed in recent Fedora history (and has been magnified by the issues with Modularity) is that there is a small, but growing, set of voices in the Fedora Project that has decided that all changes proposed by Red Hat need to be fought against. There is a constituency that views Red Hat as The Enemy and in some extreme cases fears anything brought forward as a conspiracy to “take over” Fedora. In the tradition of True Scotsmen, Fedora must remain entirely independent from Red Hat and in order to do that, changes proposed by employees at Red Hat tend towards a greater level of controversy and have a higher bar to overcome to be allowed in Fedora.
My belief is that in most cases, Fedora and Red Hat’s goals really are aligned and it’s certainly worthwhile to engage in conversation to convince people of the value of changes. However, at times it has gotten to the point where the tendency to default to saying “no” to Red Hat is providing stop-energy and exacerbates the already unnecessary tension there.
What I’d like to do (and plan to spend my time on FESCo working towards) is trying to bridge this gap and help people remember that Fedora and Red Hat are in a symbiotic relationship, not a parasitic one. Fedora cannot survive without the support offered by Red Hat. Red Hat cannot survive without Fedora as its premier Innovation Engine.
Will there be times where needs really do diverge in a totally incompatible way? Absolutely. Fedora is not and will never be interested in monetization of the operating system, so any feature that works specifically towards that goal (such as support for Subscriptions) is naturally never going to gain traction in Fedora. For these situations, I hope (in the medium term) to make Fedora ELN a place where we can try out these Enterprise-y changes without disrupting the rest of Fedora. ELN will also provide Fedora with a place where Red Hatters and non-Red Hatters alike can work towards a vision of what the next release of Red Hat Enterprise Linux will look like.
I suppose I have probably rambled a bit here, but my main point is this: I think most disagreements between Fedora and RHEL are artificial and should be talked out. For those that cannot, I think we owe it to Red Hat to provide a space for some of these ideas to develop and prove themselves out.
What else should community members know about you or your positions?
I am a True Believer in the power of FOSS to change the world for the better. Even more, I’m a believer in the Fedora Project to be the driving force behind that change.
I have been a Red Hat employee since 2008 and I have had the privilege to spend much of that time working within the Fedora community in one capacity or another: it is the foundation beneath everything that Red Hat does. I will always be a strong advocate for Fedora needs inside Red Hat and for Red Hat’s needs from Fedora.