Skip to content

CentOS Dojo in Orlando at Fossetcon 11 Sep


If you are in Florida or in Orlando attending Fossetcon next week, come over to our next CentOS Dojo on Thursday 11 September (all day).

CentOS Dojos are a one day event that bring together people from the CentOS communities to talk about systems administration, best practises, and emerging technologies.”

At this particular Dojo we have this great lineup of information, discussion, and getting things done:

  • Jim Perrin (@BitIntegrity) will start the day with a few minutes about the CentOS Project and do some introductions around the room.
  • Garrett Honeycutt (@learnpuppet) goes next with a session, “Why Automation is Important” that covers topics such as configuration management with Puppet, Ansible, et al.
  • Dmitri Pal from the FreeIPA project will discuss “Active Directory Integration”, a popular topic for many sysadmins and ops people stuck with a mixed-in-with-Windows environment.
  • Greg Sheremeta (@gregsheremeta) of the oVirt project finishes with a tutorial on using the oVirt all-in-one installer. oVirt is virtualization management around KVM (cf. VMWare vSphere) with a growing userbase.
  • Then a sponsored lunch and time to network with your fellow Dojo attendees.
  • After lunch until the evening is a hackfest focusing on building and using Docker, building Xen components for CentOS 6, and whatever else gets cooked up. The CentOS team will be bringing a local mirror and WiFi for connecting on a private LAN for the hackfest. You can bring your laptop, ideas, and skills.

If you are interested in attending, please sign up on our event page.

Rate of discussion analysis on centos-devel


I was curious how the discussion rate on centos-devel compared to previous time periods. I want to know if our work on growing the project participation at the contributor level is working, and while examples such as the increase in the SIG activity are a good indication, one simple one is to see if there is more discussion in the contributor communication channels. Based on what I see, the trend looks very good.

To make this chart, I simply grabbed all the sizes of the mail archives from the centos-devel archive page and dropped them in to a spreadsheet.

Chart showing discussion rate on centos-devel over 10 year period

Discussion level on centos-devel over last decade.

My analysis is pretty simple.

  • There have been other periods of time where the discussion level was this high (above 50 KB in archive size), but they appear more to be spikes than sustained discussion, with the exception of November 2010 through July 2011. If you were around the Project during that time, you know that is a reflection of work and associated noise around the CentOS 6 release. Although the sustained discussion levels are similar, I think the tone of the discussions is quite different, so I weigh the current trend as “good” by comparison because it reflects growing participation rather than concern about the timing of the CentOS 6 release.
  • 50 KB seems like a good level to judge against in that it seems most months reach at least 25 KB, but going above 50 KB is less common. In the nine years the archives track, the size has gone above 50 KB about 20 times out of 112 archived months, or about 18% of the time. (By comparison, the size has gone above 25 KB 64 times, or 57% of the time.)
  • The one largest-spike-of-all-time is January 2014, which is easily attributable to the announcement about joining forces with Red Hat and the subsequent discussions. Again, the tone of those emails was quite good, as compared to the previously largest spike of February 2011. That spike was to be expected since the news caught many people by surprise, so I’m generally ignoring it as an outlying data point in terms of having any more meaning than that.

Why consensus-decision making is better for open source projects


Many of us use consensus-style decision making in our free/open source projects such as Apache’s lazy consensus model, but often we have a practice or even a governance of having things end up in a majority-wins voting process.

In a majority-wins voting model, the dynamic is one where the dissenters are marginalized — the majority has to put the dissenting minority in the position of being a “loser” in a vote.

In a consensus-decision model with blocking, you have a situation where it becomes the duty of the entire group to take care of the dissenters’ concerns.

In general, consensus decisions force the group to focus on a compromise around the best-possible solution. When people are in the position of being a winner or a loser, the effect is to make people solidify around one of two extremes that may not represent the best possible solution.

Often achieving consensus only requires clarification of a misunderstanding or minor adjustments to the original proposal. This occurs even where no one has blocked, but the appearance of -0 (or a stand aside) will also make it clear that the original proposal might need more thought — getting a -0 from a leading thinker in a group spurs others to wonder if maybe there is more that can be done to make the proposal fully supported.

There are a lot more details to how things work in practice in a consensus-decision model, which I covered fairly well in the Appendix to the CentOS Project Board governance, quoted here:

In the CentOS Project a discussion toward a decision follows this process:

  1. A proposal is put forth and a check for consensus is made.
    1. Consensus is signified through a +1 vote.
  2. A check is made for any dissent on the proposal.
    1. Reservations? State reservation, sometimes with a ‘-1’ signifier
      1. Reservations about the proposal are worked through, seeking consensus to resolve the reservations.
      2. A reservation is not a vote against the proposal, but may turn into a vote against if unresolved. It is often expressed with an initial -1 vote to indicate reservations and concerns. This indicates there is still discussion to be had.
    2. Stand aside? No comment, or state concerns without a -1 reservation; sometimes the ‘-0’ signifier is used.
      1. This option allows a member to have issues with the proposal without choosing to block the proposal, by instead standing aside with a +/-0 vote.
      2. The stated concerns may influence other people to have or release reservations.
    3. Block? Vote ‘-1’ with reasons for the block.
      1. This is a complete block on a proposal, refusing to let it pass. A block is a -1 vote and must be accompanied with substantive arguments that are rooted in the merit criteria of the Project – protecting the community, the upstream, technical reasons, and so forth.

Block (-1) votes used as a veto are typically used only when consensus cannot otherwise be met, and are effectively a veto that any sitting Board member can utilize with sufficient substantiation.

In writing the original section of The Open Source Way, I didn’t go so far as to recommend the abandonment of the majority-wins voting method, instead I said, “Seek consensus — use voting as a last resort.” That section (unfinished) is now going to get a rewrite where I’ll definitely come down against majority-wins, and write out more of the why.

Partially I owe my improved understanding from using the consensus model in a business collective where I’m a partner, Santa Cruz Pedicab. Working with the model in the physical world made me intensely aware of the human impact of majority-wins by comparison, and convinced me it was really the backbone to a welcoming community.

CentOS Dojo Santa Clara – 31 March before MySQL Conf


On the eve of the Percona Live:  MySQL Conference and Expo (Monday 31 March 2014) I get to help run my first CentOS Dojo at the Santa Clara Convention Center. For this event, I’ll MC and give a talk about the newness in the CentOS Project. The lineup so far is pretty set and quite stellar:

  • Jeremy Carroll — Systems Automation and Metrics at Pinterest:  “At Pinterest metrics instrumentation and presentation has been an increasingly vital as our systems scale …”
  • Monty Widenius — Notes on MariaDB 10:  “MariaDB is coming along in great strides, and is now included by default in the EL7 Beta cycle …”
  • Peter Zaitsev — Running MySQL on CentOS Linux:  “Linux is by far the most common platform to run MySQL, and there is a lot of accumulated knowledge about which way is best to run MySQL …”
  • Jordan Sissel — Happy Tools:  “Happy tools! This talk will introduce three different operations-friendly tools to help make you happier …”
  • Joe Miller – Two Years in Your Future:  “Systemd is the new kid on the block, everyone is talking about it, everyone is thinking about it, everyone is planning for it …”
  • Joe Brockmeier — Software Collections on CentOS:  “The power to build, install and use multiple versions of software on the same system, without affecting system-wide installed packages. Welcome to software collections …”
  • Karsten Wade — The New CentOS Project:  “A new Board member’s perspective on where the CentOS project is today and the road ahead …”

Massive thanks to Joe Brockmeier and Karanbir Singh (of the OSAS and OSAS/CentOS Engineering teams) and Kortney Runyan and the event crew at Percona. If you want to attend, hop on it — space is limited. 🙂 It’s a no-cost event and comes with the bonus of a no-cost expo and keynote pass for Percona Live. Oh, did I mention we’ll serve you some lunch and generally treat you right?

If you are attending the main conference, visit us as the CentOS Project booth in the DotOrg Pavilion — or contact me if you are interested in staffing the booth.

SCALE 12x – CentOS and Infrastructure.Next


We’re very excited over here to be attending the twelfth annual Southern California Linux Expo, aka SCALE 12x, on 21 to 23 February in likely-to-be-sunny Los Angeles.

On Friday, I’m going to hang out near the stage and nod cleverly as Jim Perrin tells us about “Growing CentOS as a Platform for Infrastructure Development“. You can register for Infrastructure.Next (it’s no-cost!) here. It’s a full day devoted to learning about how real people are solving real problems with open source. I’ll have to visit my friends at the Fedora Activity Day. Then I’ll do the brisk-for-LA dinner so I can get back for Lawrence Lessig’s keynote, “Only You Can Get This, So Where Are You?” at 9 pm.

Saturday is dedicated to all the fun the expo has to offer, plus the evening activities. I’ll be hanging out at the Fedora, CentOS, and Red Hat booths. I’ll definitely carve time for m’man Jason Hibbets’ “Open Source ALL The Cities” – a topic near to my heart, one I’ve acted on, but barely to the extent Jason has, so I’m looking forward to learning more from him (and seeing a friend speak, natch.) Closing Saturday, two other friends-also-faves are Ruth Suehle (“Raspberry Pi Hacks“) and Rikki Endsley (“You know, for kids! 7 tips for improving tech education in our schools“), at 6 pm opposite each other (curse the schedule overlords!!!), I may have to favor Rikki as I had the fortune to catch Ruth in Scotland talking on the same topic a few months ago … which is another story. And look! I have another colleague, Rich Bowen (“Demystifying mod_rewrite“) at the same time (a skill I sorely need to demystify), and I note Dawn Foster is talking as well … So much goodness!

Sunday kicks off for me with Leslie Hawthorn at 10 am with “Why Checking Your Privilege is Good For *You*“. Leslie is another friend-and-great-speaker, but I’ll note that she’s particularly interesting to listen to and I think more so on this topic. I’m very much looking forward to this, especially as the newbie feminist that I am. Then Thomas Cameron is speaking on “Next Generation High Availability Linux Clustering” at 11:30, which I hope to be able to catch some of (and heckle.). I’ll be preparing for the “CentOS Project Q&A Forum” that I’m leading with Jim Perrin and Johnny Hughes at 1:30, where I’m looking forward to some reverse-heckling from Thomas. Perusing the schedule, I found the quite intriguing, “Hacking the Kernel, Hacking Myself” talk by Kelley Nielsen at 4:30. I’ve quite interested to hear her story around the domains of kernel development, personal development, the Outreach Program for Women, and her story overall.

GSoC at CentOS office hours


I love how KB started CentOS Project online office hours right after our joint announcement about the new relationship between Red Hat and CentOS. I don’t think this sort of thing was happening before, but it’s now a regular part of exposing the inter-workings of the new CentOS Governing Board.

This Monday 10 February at 16:00 UTC (yes, that’s 8 am in California for me) we’ll be talking about CentOS and the Google Summer of Code. You can watch via the YouTube channel or, and participate in IRC on #centos-devel on Freenode,  Here’s my quick agenda for the hour:

  • Quick summary of what Google Summer of Code (GSoC) is.
  • Overview of what is possible to do with GSoC for CentOS.
  • What we have so far.
  • What we need to work on now (this week), next (following few weeks), and for the summer (full program length.)

See you there!

CentOS and GSoC


With the Google Summer of Code season upon us, I’ve decided to stick my nose right in to the situation and help run a GSoC for the CentOS Project. I was co-admin for Fedora for 6 GSoC sessions, a mentor for a few specific projects including the kick-off for Transifex, and ran the one-off Fedora Summer Coding 2010 the year Fedora didn’t get in to GSoC. I would LOVE co-admin assistance, this is a fun effort that is well-worth sharing with other contributors. Let me know if you want to help in any way. Note that a few admins and mentors from each project are invited each Fall to Google headquarters for the Mentor Summit. I’ve attended a handful of times, it’s an absolutely fantastic event.

So far my understanding and history lesson for the CentOS Project is …

  1. CentOS applied at least one time in the past;
  2. We were not accepted;
  3. That is all.

Please let me know any details, subtleties, or differences to my history-so-far. I have seen URLs to some wiki pages but haven’t got the #acl to read them yet.

My plan is to do the usual what-works that I learned as an admin for Fedora for 6 years, as well as what I’ve learned of the open source way. This means:

  1. We need an ideas page, with an idea paired to a mentor. For example, the 2013 Fedora ideas page.
  2. We need students to be dreaming up ideas — especially students who are already users or contributors to the project — and get those ideas out to see if there are likely mentors amongst other contributors
    • It doesn’t hurt to ask about your idea!
  3. We need to be thinking in a realistic and useful way about the GSoC potential — what can it really mean, how can we use it to the project’s advantage.
  4. Then we need to fix the ideas page on the discussion from 2) and 3).
  5. Do all the rest required by deadline to apply as a mentoring organization (I can do that.)
  6. Magic! (If we’re lucky; I’ll  monitor the process and shepherd it through.)
  7. Magic requires us to find and engage with students.That’s what is next … first let’s get accepted!

The only time my organization didn’t get in to GSoC … we hadn’t finalized the ideas page (partially because of my mistaken thinking.) If the CentOS Project can do the basics, and we have good ideas, CentOS has a fair chance of getting in.

Where it comes to “what the heck can students do that helps CentOS?!?”, I have this small list to spark ideas; I’ll be opening a new thread on centos-devel to discuss all ideas in full:

If you are a student with an idea looking for a mentor, please let me know. I will post it and help you look for a mentor. Ideas from students have been very successful in the past!

I’ll also note that existing community members who are students are qualified to enter the program, and your existing relationships may be useful for your efforts. Email me if you have any questions about this.

This should be another great GSoC year, and I hope the CentOS Project gets a chance to participate as a mentor organization!

Explaining the CentOS governance, or, Ouch, the snicker-snack


My man Donnie Berkholz wrote a good analysis (and great blog post) about the new relationship between Red Hat and CentOS, with a delicious analogy of myself appearing as the Jabberwocky. (Does that make Donnie the young man with his vorpal blade?) For many reasons, I’m honored at the comparison. Yet, I detect some underlying concern in Donnie’s post that I want to address … line by line, in true open source fashion 🙂 … as well as a few items worth commenting/supporting. In the below quotes, Donnie is the first indent, and whatever he is quoting is the deeper indent.

LWN made some excellent points in its writeup (emphasis and links mine):

The ownership of the CentOS trademarks, along with the requirement that the board have a majority of Red Hat employees makes it clear that, for all the talk of partnership and joining forces, this is really an acquisition by Red Hat. The CentOS project will live on, but as a subsidiary of Red Hat—much as Fedora is today. Some will disagree, but most would agree that Red Hat’s stewardship of Fedora has been quite good over the years; one expects its treatment of CentOS will be similar. Like with Fedora, though, some (perhaps large) part of the development of the distribution will be directed by Red Hat, possibly in directions others in the CentOS community are not particularly interested in.

I’m not sure acquisition is the right way to describe this, as for a company it’s usually used in the context of a takeover of one company by another. It’s not really a takeover, it’s more like a marriage where each part comes in and remains on equal footing.

Red Hat has simply followed our long-term practice of hiring smart people to work full-time on the independent community they already care about.

The CentOS Project has set its own practices and procedures since creation, but Red Hat has provided influence on the project simply by being the upstream.Whatever influence I might have as a Board member with my Liaison hat on, it’s going to be squish-and-squat compared to the influence of the many hundreds of people already working upstream in RHEL Engineering and Fedora.

An explicit goal of this new relationship is to grow the variants — something CentOS has been doing already, so it’s a shared interest that brought both groups together — and that itself will create an expanded roadmap for the Project that is outside of the monolothic influence of the RHEL roadmap. By getting more involved, we’re helping the project go beyond just being a downstream of RHEL.

The playing field may never be perfectly level due to the influence of RHEL on the overall CentOS roadmap, but considering the Liaison’s limited-and-not-unique powers by comparison to RHEL Engineering controlling the code, it’s much more playable than before. And only going to get more so, as the community and leadership work out the kinks.

I’ll also point out that the idea of CentOS variants came equally from the community, with it’s desire for and consumption of Xen4CentOS.

I’m not convinced it had to go nearly as far as it did to realize those benefits, though — formalizing a partnership would have sufficed. However, giving three of the existing lead developers the opportunity to dedicate full-time effort to CentOS will be a huge win, as well the other resources Red Hat is providing around infra, legal, etc. But the handover of the trademark and the governance structure are a bit unusual for the benefits as explained, although entirely unsurprising for an acquisition and company ownership of an open-source project.

Yes, Red Hat has taken on the overall management of the CentOS trademark. Having a defendable mark and someone who will defend it is valuable to the future of the project.

In a free and open source software project, the trademark is often the only way the community can assert that such-and-such a combination of software is the community’s work and a similar-yet-different combination of software is not the same, so cannot be called the same name (under the trademark.)

Regarding the governance structure, I cover that below.

Red Hat still needs a breeding ground for innovation of the Linux OS, so I don’t see anything significant changing here. What I would hope to see over time is a stronger integration of developers between Fedora and CentOS such that it’s easy to maintain packages in both places if you desire.

While I can’t promise how the CentOS and Fedora communities will interact, this exact topic came up amongst the group of Fedora and CentOS folks discussing this behind the scenes pre-announcement. We concluded that i) sure enough, there are lots of ways we might be able to collaborate, and ii) we needed to get the new story out to the public first and see where the actual communities want to go. The idea of making it easier to maintain packages in both places was definitely discussed as a probable goal.

Perhaps the largest concern for Fedora is a lessening of Red Hat employees contributing to it on paid time, in the longer term. As the company pivots more toward cloud infrastructure (see its recent appointment of Tim Yeaton and Craig Muzilla to lead groups that own cloud software at Red Hat) with a clear hope of increasing its cloud revenue share, Red Hat’s need to differentiate at the OS level may shrink and thus its need to contribute as many resources to Fedora. However, Robyn duly points out that Fedora’s role as upstream for RHEL isn’t going anywhere, so neither is the project.

One might conclude that more resources in area A might have to mean fewer in area B, but this isn’t the case. In fact, if the cloud makes the OS less popular so fewer people are using it directly, that makes it harder to innovate and integrate — the brunt of the work ends up on the paid OS developers to integrate, test, fix, etc. As that work starts in Fedora makes its way to CentOS (not the reverse), the investment in Fedora is primary and core to all the missions.

Red Hat’s Karsten Wade seems to have become the closest thing there is to a CentOS BDFL (or at least an avatar of Red Hat as BDFL) by virtue of being the “Liaison” on the newly created governing board. The other named board role is Chair, who is a coordinator and “lead voice” but cannot take decisions for the board as the liaison can.

What’s missed here is the way the role works with the consensus decision making model, as the Liaison doesn’t have more power than the Chair. The Chair has traditional agenda and lead-voice responsibilities that give the role the clearest equivalence to project leader. All of us have the same voting powers to approve (+1) or block (-1).

In case you didn’t see the fine print, here’s the reason I say that:

The Liaison may, in exceptional circumstances, make a decision on behalf of the Board if a consensus has not been reached on an issue that is deemed time or business critical by Red Hat if: (1) a board quorum (i.e., a majority) is present or a quorum of Board members has cast their votes; or (2) after 3 working days if a Board quorum is not present at a meeting or a quorum has not cast their votes (list votes); provided that the Chair may (or at the request of the Liaison, will) call a meeting and demand that a quorum be present. Unless the Liaison specifically indicates on a specific issue that he/she is acting in his/her official capacity as Liaison, either prior to a vote or later (e.g., after an issue has been deemed time or business critical), the Liaison’s voice and vote is treated the same as any other member of the Board. Decisions indicated as Liaison decisions made on behalf of the Board by the Liaison may not be overturned.

Translation? If the board (the majority of which is Red Hat employees) can’t come to a consensus or can’t meet/vote within 3 days, the Red-Hat–appointed liaison can make an irrevocable, unilateral decision on behalf of Red Hat.

Note that the governance clause specifically limits this ability to when the Liaison puts on the Shadowman hat and says, “Such-and-so is time or business critical for Red Hat” and the Board has been unable to meet or come to consensus in a reasonable time period on that specific topic. This is clearly a limited set of potential situations, and not the same as if any vote, at any time, can be forced or overruled by the Liaison.

Also worth noting is that Karsten will be the direct manager of the three CentOS employees joining Red Hat, giving him further influence in both formal and informal forms. Although whoever’s in the liaison role theoretically steps down in power when not acting as liaison, this is much like temporarily removing “operator” status on IRC. Everyone knows you’ve got it and could put it back on at any point in time, so every word you say carries much more weight. It is therefore of great interest to understand Karsten more deeply.

Let me unpack this a bit by starting with a quick lesson in the consensus decision model that the CentOS Governing Board and many other projects follow. People don’t usually view it in light of the formal model, but the classic “-1, 0, +1” voting model is basically a consensus model with blocking.

In a consensus decision making process, one or more persons puts forth a proposal. In responding, others need to decide if they like the proposal, have some reservations about it that need to be resolved, or are solidly against the proposal as written/proposed:

Flowchart showing how a consensus-model decision is made

Consensus decision making flowchart (Image by Grant Horwood (frymaster) from Wikipedia under CC BY 3.0 license)

  1. If you like the proposal, you vote +1.
  2. If you have some reservations, you let others know and work toward resolution. In the this case you are saying, “I am not actually blocking with a -1 vote, but if my reservations are not resolved, I may block with a -1 vote.”
  3. If you can’t accept the proposal, you can block it with a -1 vote. This vote can appear to be a veto … but isn’t a veto.
  4. Based on the above, you drive toward consensus by working through reservations and blocks until you have a proposal that all can agree upon.

Importantly, in the consensus model, the -1 vote must be accompanied with a sufficient reason (usually technical or community oriented in free and open source software projects) as to why the proposal doesn’t work. You can’t block a proposal without a sufficient reason.

Also, the blocking vote is an opportunity to work toward consensus to get the Board member(s) to unblock. It is not a permanent vote per se the way a veto is in a democracy. The blocking reason can be resolved, and then the blocker removes the -1 vote (changed to a +1 or 0), consensus is achieved, and things go on. Not at all like a majority rules with veto.

In this model, every single CentOS Board member can cast a -1 vote and block a proposal.

What the new governance provides is that a set of reasons that are normally not considered in an open source project such as, “Will doing this action cause a ‘foo bar baaz’ risk to Red Hat?” are now considered to be sufficient reasons for casting a -1 vote … but only if the Liaison says so.

To summarize, the Liaison role doesn’t provide special veto powers that no other Board member can use. Rather, it makes it clear that items “deemed time or business critical to Red Hat” can be brought up by the Liaison as sufficient reason for a block (-1). It adds a set of sufficient reasons that are otherwise not normally present in such situations.

That post makes it perfectly clear where Karsten’s interests lie, so it, along with his background in community management is what drives my initial expectations of Red Hat’s influence upon CentOS. It remains to be seen how often Karsten will need to step up to liaison mode, and to what extent his actions in that role will be handed down from higher up in Red Hat vs independent, so I’m looking forward to seeing how these changes play out.

You and me both. 🙂

As to what my interests in the project are, I suppose it’s fair to figure I’ll use my influence via the Board to get there, but I don’t think that’s related to my role as Liaison.I will definitely agree that the focus of our team at Red Hat is to work to enable variants, but only after all the regular work of the project is safely covered.

Red Hat and CentOS joining forces


As you may have heard by now, Red Hat and the CentOS Project have announced that we are working together. I’m very excited about this announcement and what it means for the future. There are plenty of resources that I’ll list below to find out more about the new effort, but I wanted to take a moment to share with you my personal view (and why my view matters.)

Ten years ago I was present with many of you when Red Hat split our Linux product into the Red Hat Enterprise Linux (RHEL) product line and Fedora Project community distribution. Many of us were aware right away that a gap was created between Fedora and RHEL for a slower-moving, stable-enough community platform. That gap was where CentOS (and other) distros grew. That gap has since become a fully realized niche with an enormous community of users and use cases.

In that time, Red Hat has moved our product and project focus farther up the stack from the Linux base into middleware, cloud, virtualization, storage, etc., etc. We continue to use the open source way in developing code and content, and we’ve run in to some interesting effects from that. One of them is that the upstream projects we care really benefit from running on the CentOS platform for open source development. Another is that code in projects such as OpenStack is evolving without the benefit of spending a lot of cycles in Fedora, so our projects aren’t getting the community interaction and testing that the Linux base platform gets. Quite simply, using CentOS is a way for projects to have a stable-enough base they can stand on, so they can focus on the interesting things they are doing and not on chasing a fast-moving Linux. CentOS also popular with users, such as open source developers who want to combine various interesting projects on a platform they can rely upon to not change underneath them.

This change in relationship is really all about building more of that bright, shiny future. One of the major focuses in this next chapter of the CentOS Project is around the variants. This is where the interesting stuff people are doing meets the roadway that we are creating for them. In the coming months you’ll see special interest groups (SIGs) springing up in the CentOS Project such as cloud technology previews (meaning OpenStack, oVirt, Gluster, etc.), web hosting, and new technologies such as ARM. Variant SIGs do this by providing additional code or changes to the CentOS core distribution, kept in We’ll be be creating a new community build system with other contributors, and helping the Project overall with governance, transparency, and practicing the open source way.

What I love about all of this is how it creates the balance between the forceful personalities of Fedora and RHEL. Rather than having to make Fedora fit into every imaginable community platform need, we’ll see an expansion of the kind of efforts that fit better on CentOS for community projects where RHEL doesn’t make sense. If you look at the virtuous water cycle of open source innovation, you’ll see that CentOS continues to receive a flow from Fedora via RHEL, while simultaneously providing the innovation platform that flows better and better code back around the circle to influence products and other projects.

My relationship to this new effort is pretty integral. I’ve been acting as the project lead and have been one of the project architects since the beginning. In addition, I’m going to be joining the CentOS Governing Board and acting in the role of the Red Hat liaison. Finally, I have the honor of the being the team manager for the new CentOS team working in the CTO’s office as part of our Open Source and Standards Group, meaning I get to be the buffer and champion internally for Johnny Hughes, Jim Perrin, Fabian Arrotin, and Karanbir Singh.

Defining self-identity for an open source project & how did Fedora do it?


As an open community innovation engine, the Fedora Project continues to grow and change in how it creates/consumes itself for its community audiences. These are the “How is it made?” and “How do we use it?” questions. Over the last 6 months I’ve read and watched discussions and proposals around these topics, such as Tom Callaway’s “Overhauling the Fedora release model” and Matt Miller’s “An Architecture for a More Agile Fedora” (video). Most recently has been the proposal the Fedora Board just approved to have working groups that focus on a different editions of Fedora: Fedora Server, Fedora Workstation, and Fedora Cloud. Very interesting and exciting.

In all that, I began to wonder about the process the community used when going through a previous exercise, the rounds of self-identity that produced, for example, the four foundations “Freedom, Friends, Features, First” messaging, as well as the front-page descriptive -content such as, “Free your desktop with Fedora. Fedora is a fast, stable, and powerful operating system for everyday use built by a worldwide community of friends. It’s completely free to use, study, and share.”

This sort of mission-statement, self-identification vision exercise is not easy stuff. There are many personalities in a community as large as this one is now, and I’m sure it wasn’t any easier or less cantankerous back when that work was done.

Myself, I barely remember the process that was followed – I was a bit busy elsewhere at the time and just trusted the community to do the right thing. Anyone know of a history page or somewhere/way to figure this out? Or knows from first-hand the process and wants to meet me on #fedora-meeting-* to get a log of it all? I’ll turn it in to an article/page for The Open Source Way, at least. Thanks!