Skip to content

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

20-Jan-14

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

07-Jan-14

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 git.centos.org. 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?

04-Sep-13

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!

Return of Fairytale Fridays and Sauerkraut Classes

18-Jul-13

This summer we have restarted the salon-style events here at Fairytale Farm – Fairytale Fridays. We’re also offering an array of classes every Saturday morning.

Every Friday we’re holding a community-space event, free to attend. We’re drawing in musicians to play for us, giving garden tours peppered with urban farm wisdom, something artsy/craftsy and fun for the kids, and featuring the treats of our own Pumpkin Peddlers.

This Friday 19 July we begin offering a dinner as well. It will be vegetarian (usually vegan) with a dish from the day’s garden harvest, and usually a pot of beans and/or a delicious grain. Once you are done, you can follow it up with fresh-fruit pie or one of the non-gluten brownies-to-die-for and cookies-to-live for of our new mobile bakers. If you plan to attend, please let us know so I know how much to prepare. 

On Saturday 20 July from 10 to Noon I’ll be teaching how to make sauerkraut and kim chee. We’ve done this class before a few years ago with great success, and we’ve watched how much more interest there is in the fermentation arts wherever we look! For $39 you get instruction on making sauerkraut and kim chee via hands on and lecture. We’ll supply the vegetables, utensils, and send you home with a jar of your freshly made ferment. More details and sign-up on the class page.

The virtuous water cycle – updating an old analogy

29-May-13

When we talk about how code moves in the free/open source software ecosystem, we often use the upstream/downstream analogy. In this analogy, code flows from an upstream project downstream to the users and vendors. Users use. Vendors package and support. When anyone contributes their ideas (innovations) and code back to the project, it is said to happen in the upstream.

Recently I was in a meeting with a few folks and we were discussing the flaws in that analogy. For one, it describes backbreaking labor or requires magic – how do you get your changes from downstream back upstream without overland hauling, big motors to get through the rapids, or a helicopter firefighter team. It supports the idea that getting things upstream is hard, and therefore undesirable. Our real world experience is that the projects prefer to make it easy to contribute, and then we have to extend the analogy for pipelines that carry water, etc. It also doesn’t really describe the actual flow of innovation, it’s not all in one direction toward a larger ocean.

As a first pass at describing this virtuous flow, I wrote,

We all live on the same river. Care where your water comes from. Care where your water goes to.

What this misses is the circularity of the flow that a river doesn’t encompass. For a river to be circular it is either something magical or it’s not a river, i.e., the analogy is inaccurate. Just as I reached that conclusion, so did JimJag because he jumped up and drew this image on the whiteboard:

water_cycle-whiteboard-drawing

That, folks, is a water cycle. It solves the circularity problem because it looks at an ecosystem as a whole. In a normal physical world the water that flows downstream doesn’t spontaneously go back upstream directly. Anything else that happens to get water back upstream directly is a manual process – pumps, helicopters, etc. But a river is not in isolation – it flows from multiple sources down to the ocean, and along the whole way evaporation brings the water back to the atmosphere so that it can come down in ways that may replenish the water sources.

In this new analogy (and diagram), I’m not sure yet where to put the various groups we’re used to putting on the river. Such as, “User”, “Project”, “Vendor”, and “Customer”. Also, it’s unclear to me if the water represents one thing – contributions, code, content, what? – or if the water is in fact us. Looking at my own experience, I work for a free/open source software company, contribute to many projects, benefit from many thousands of more projects, and am a customer of vendors who create and sell solutions around or based on open source. As I’m moving around that water cycle … am I a boat or the water itself?

 

Social support not private patrols

25-Feb-13

If you are concerned about how the City of Santa Cruz has stretched in to hiring private security teams to patrol public open spaces, email the City Council by tonight or show up at the Tuesday 26 February meeting. The Council is going to vote on actually legalizing their own practice, and extending it to allow the private security to patrol the public beaches. Read on for some of my thoughts on this matter.

Here in Santa Cruz, we have this … interesting process used by the City to impose some kind of control on the river levee.

Because we have totally failed as a city population to make the beautiful river levee into a destination for people – there are no food carts, no cafe tables, no benches, no vista points, no attractive plantings, no shade structures, no art, no population of hipster-intellectual-professional-slackers to make the place look cool – the levee instead becomes the quiet, hidden place for all the street people to hang out. (There is a long history as to why we ignore this treasure in the middle of our city, and continuing to allow private security teams to drive patrol cars is not any help to solving that.)

The City’s solution is to hire private security guards to drive up and down the levee. I’ve never seen them do anything other than drive. I can’t imagine what they can do from inside of their vehicle. I just know that my dog and I have to stop and step out of their way as they squeeze through spaces where only emergency service vehicles should ever go. I go on the levee all the time, and I find the private security patrols to be as bothersome to my use of the open space as any of the street people, travellers, and derelicts who hang out there.

People who are enjoying the river levee, regardless of their purpose or background, have the same legal rights of being there. At least, during daylight hours and out of the sections the local Parks Department has closed for “rehabilitation”, which is admittedly their way of making it illegal to be there so they can give tickets to trespassers-on-public-green-space. I have friends who have been ticketed for picnicking on this closed space. I’ve been verbally warned for walking my dog on the levee after dark when it is “closed”. The command and control exerted over this open public space has the effect of further reducing the enjoyability for everyone.

It turns out that the private patrols don’t currently have a legal right to drive there, which the City Council is considering changing. Here is a letter from City Council member Micah Posner to the local Nextdoor group.

Several of you have mentioned a dislike of First Alarm trucks driving on the levees. I always wondered how they were authorized to do that without permission from the City Council. As it turns out there is a city ordinance that limits cars/trucks on parks and beaches to maintenance and emergency vehicles. This ordinance is on the agenda on Tuesday at 3PM with a proposed change that would allow First Alarm and other vehicles contracted by the city to drive in parks and on the beach. This would be an excellent time for people to send emails AND come to the meeting if you have an opinion about these vehicles driving on parks and beaches. Send emails (by Monday evening) to citycouncil@cityofsantacruz.com

Regardless of where you personally stand on the issues of street people in Santa Cruz, I think we can all agree on a few things:

  • Santa Cruz really is mostly populated and controlled by the people who live here with legal residences and generally contribute to the tax base.
  • Changing the laws to reduce the rights of a small population affects all of us.
    • For example, in the City of Santa Cruz, if you are on your lunch break and take a snooze on a park bench after eating, you are in violation of the law. There is a ban on public sleeping that was put in place as a focus on a specific population, but it is binding for all people.
  • If you are going to accept your rights being reduced, you should know about it (be informed) and really consider the implications. Are you really going to be more secure?
  • Money spent on patrols that sweep street people around (“million-dollar broom” is an accurate term, budget-wise) doesn’t solve any of the problems that keep these people on the street. When people need help, they benefit more from social workers than another night in jail.

Thus I’d rather see us pay social workers to walk around the levee solving problems for people who get lost in three-letter-agency bureacracy. I would rather not see us pay private security patrols to drive around getting in the way of every citizen’s right to enjoy the open space free of car exhaust in our faces.

I encourage all of you to write the City Council and let them know what you think.

Fedora joins Google Code-In 2012

19-Nov-12

Google Code-In is the pre-college program for 13 to 17 year old students to earn prizes for completing tasks in various open source projects.,

This year will be the first year that the Fedora Project participates. We’re looking to build on many years success with Google Summer of Code, but the stakes here are higher. Unlike college students, who learn real life lessons the hard way, pedagogically you can’t allow high school students to truly fail. But failure is built in to the open source ethos. A fine line must be trod.

If you are a 13 to 17 year old or know one who is interested in code, design, documentation, just about aspect of an open source project, have them check out what Fedora has as tasks. They should also look at the wider program. Students can do work across multiple projects, or dig in deeply to a single project. Ideally, tasks are designed to be done within a few hours or days.

If you have any questions, I encourage you to contact Buddhike Kurera, who was last year’s GSoC admin. IMO, he has been doing a fabulous job driving the Fedora Summer Coding group. Joining the Google Code-In is the next step in his vision of how Fedora can work with students in these sort of contest/internship-style programs. I’m excited and curious to see how it all goes.

MWikipedia: M (named em ) is the thirteenth letter of the ISO basic Latin alphabet.

Contributor agreements – the grass is browner

05-Nov-12

If you’ve been looking to implement a contributor license agreement (CLA), or your free/open source software project already has one, I wanted to let you know that the grass is greener on this side of the fence. As soon as you can, burn your CLA and never look back.

I’ve had more than my fair share of dealings around these tools of accidental-anti-community – I’m fairly sure I coined the phrase “nuclear option” to refer to using the CLA to relicense without obtaining copyright-holder consent, and I certainly was instrumental in using that option in the now-defunct Fedora CLA.

As I continue to hear groups and organizations struggle with using CLAs, I wanted to pull together a few useful pointers and one particularly good presentation by Richard Fontana. Basically, I agree with everything he says, especially how CLAs inhibit community-building.

Richard is Red Hat’s lawyer specializing in FOSS licensing, and he gave this half-hour talk at the Open World Forum this year as part of the European Open Source and Free Software Law Event. In “Contribution Policies for FOSS Projects“, Richard systematically covers the major objections and concerns about CLAs.

Richard inherited a Red Hat practice of using CLAs, and I think it’s fair to say that he represents the learning that Red Hat has done institutionally around contributor agreements. Similar to other organizations, we originally thought the CLA was a good practice overall, and you’ll find the remnants of that practice throughout Red Hat-started projects.

These days, though, you can see that we’ve been using what Richard calls “inbound = outbound”, that is, code and content coming in to the project as a contribution is simply taken in under the same license the code and content is distributed under, no additional agreements required. If the project uses the Apache License, contributions must simply be under the Apache License. Same with the GPL, and so forth.

Examples of Red Hat using inbound = outbound in practice are the oVirt project and OpenShift Origin, both of which are licensed under the Apache License. Similarly, I like the contribution policy we crafted for The Open Source Way. It’s simple, clear, unambiguous, and reusable.

One thing I appreciate about Richard’s viewpoint is that he looks beyond the basic concern that legalese can scare people away, which is what many perceive as the main threat. More importantly, he highlights the way contribution agreements create different classes of contributors with a larger imbalance of power than many of us recognize.

Response to ‘Meaning of “the only thing that could have happened”’

16-Jul-12

After I setup John D. Smith’s account on The Open Source Way wiki, I followed up to look at his website and discovered he is one of the authors (with Etienne Wenger and Nancy White) of “Digital Habitats: stewarding technology for communities”. This is a book out of the communities of practice milieu, and in fact is a book I’ve recommended on a few occasions. (An oversight: we missed having it listed on the wiki, which John fixed, thanks!)

This post is in response to John’s post about his experience at the Community Leadership Summit this year. I tried to post this as a comment to his blog, but had troubles getting signed in, so I’m going to post here instead.

John, I’m glad you bring up the topic of belonging at CLS.

Originally, there had been a CLS goal of reaching out beyond software to share with people from different community backgrounds than open source. I think that is still a goal.

When I was last at CLS in 2010, some of us looking for that higher-level community leadership conversation were disappointed at the quantity of “how to deal with assholes in your online forum”-type sessions. At the same time, it was already becoming a place for that higher-level discussion but only about open source communities.

The reports I got from CLS 2011 revealed that trend continued, on the higher-level side. It has become a place for people interested in open source communities, and is now the de facto summit for that angle. Unfortunately, this growth of one aspect – which is honestly the easiest one that could have grown out of CLS – has the effect of pushing aside the conversations from outside of the software sphere.

One reason I agreed to put so much support in to CLS this year – working with Guy Martin on the OSS community consulting working group, and a good percentage of my team at Red Hat were there, although I had to cancel at the last days – is because of the growth of the open source aspect. I cannot ignore that being valuable to what I do. However, I do think it’s a loss to not continue growing the non-software focus.

Would you consider coming again if you and others could make it more of a place that works for your interests? You might only represent a small percentage of the people there for a while, but the kind of higher-level conversations on community interaction that you want to have outside of just-software is very much needed. Open source folks need to learn about what is happening outside of our narrow sphere of influence and affect. “Digital Habitats” is good example of the kind of material many people may not know about – that’s been my experience with the main “Community of Practice” book, people really didn’t know there was this body of academic research that addressed what we experience in open source communities.

If that type of conversation doesn’t grow at CLS, it will grow somewhere else. I would like it to happen, though, where the open source folks can be involved – we have a lot to teach, but even more to learn.

Fedora 17 packager metrics and why I care

20-Jun-12

I’m going to do something very dangerous – talk about specific raw, unanalyzed, and likely inaccurate statistics.

But I don’t know how else to combine radical transparency with my work of tracking and analyzing community health.

Does that mean someone is likely to read my posts and cherry-pick information that serves their own agenda? Perhaps. But I don’t choose to be open and transparent because it’s the risk-free position. I do it because it’s the better way to do things.

Do I expect some healthy criticism of my methods and results? Yes, I encourage it, and figure criticism will be more accurate and reasonable when the critic can view my methods transparently. I know I’m doing things incorrectly and getting things wrong. I need the eyes and help of others who care as much (or more) than I do.

Part of the better way is that I’m doing work on tracking community health directly in the communities themselves. The tools and data already belong there, so will the gathered statistics and (at least) base analyses. There is no opportunity or reason for me to keep all this a secret, but it is going to be a while until a coherent story unfolds. In the meanwhile, I’m making the proverbial sausage but without a recipe.

A website we’ve been working on at Red Hat is going live next week – and I’ll announce it when it goes live, but give us our rare Big Reveal without tittering, thankyouverymuch – and one part of that work is going to be based on these statistics I cooked up about Fedora Packaging today. At a minimum, this post is a reference for how those statistics came about.

Thankfully Toshio still had the script he wrote with Max a few years ago (2007!), and with some tweaks to the interaction with the Fedora account system (FAS), I got these raw, unanalyzed, and likely inaccurate statistics about who owns and co-maintains Fedora 17 packages.

Why am I so certain they are inaccurate? Simply, folks at Red Hat who work on Fedora don’t always use their @redhat.com email address. Unfortunately, this tool creates statistics based solely on the email address of the packager. We don’t have anything more than a wild guess about how many Red Hat people use a different address (most likely user@fedoraproject.org but others from personal domains and mail hosting services.)

Is there anything I can do to make them more accurate? I need to make a mapping of the different email addresses Red Hat folks use, mapped to their main Red Hat account. This will help with sorting out this sort of detail.(Currently 659 accounts to check, not a terrible manual research job, just tedious.)

Why am I so concerned with who owns or maintains what packages? Aren’t Red Hat people community contributors, too? Darn tootin’ they are, but that’s not the point. I know people look at such statistics as a competition, but that’s not my goal. These are statistics that are all out there in the public, I’m just doing a job of gathering things together. I’m doing that job because it’s one useful way of knowing if projects are being successful. We all want to see a steady, sustainable growth in packages in Fedora, with a healthy balance of package ownership so that one person or one organization isn’t taking on too much for itself. I’d like to be able to give a more accurate account of who at Red Hat contributes to Fedora – I’m sure even Red Hat doesn’t know exactly how much effort goes in to Fedora (and other upstreams) from Red Hat folks.

What is my future plan for these specific statistics? I feel responsible for reporting these, now that I’m starting. I recall Simon Phipps once wisely saying, “Don’t start reporting on any statistics that you don’t want to report on forever.” I accept that, and that any changes to the reporting – the methods, sources, results, etc. – need to be highlighted and explained. (I also hope that by putting tools and methodologies directly in to the projects, others can be involved in the creation and delivery of statistics and reporting.) I’ll link out to everything I do from the canonical Fedora statistics page, and I’ll host tools, configurations, and documentation on Fedora Hosted and the Fedora Project Wiki. Anything that is generic will also get contributed to the Metrics Working Group (metrics-wg) of TheOpenSourceWay.org.

And now, the stats and how I got them:

./rhpkgers.py f17 maint.list users.list 
Total Packages: 12157
Total RH Maintainers: 386
Total NonRH Maintainers: 659

These stats are for people able to commit to the package.
The first set disregards packages which are open for anyone to
commit:

Packages which have at least one Red Hat maintainer and packages
which have at least one non-Red Hat maintainer:
   @redhat.com: 5330
  !@redhat.com: 8575

Packages which have solely Red Hat maintainers, solely non Red Hat
maintainers, and a mixture of both:
  solely   @redhat.com: 3490
  solely  !@redhat.com: 6735
  mixed redhat+!redhat: 1840
     orphaned packages: 92

This set factors in the possible effects of open acls (ie: anyone
in cvsextras can commit:

Packages to which only Red Hat packagers can commit, only non Red Hat
packagers can commit, or both:
  solely   @redhat.com: 0
  solely  !@redhat.com: 0
  mixed redhat+!redhat: 12157
Total Packages to which anyone can commit: 12154

Steps:

  1. Get a list of all maintainers for all versions of Fedora (8.2 Mb file in the end):
    • curl https://admin.fedoraproject.org/pkgdb/lists/vcs?tg_format=plain \
      > maint.list
  2. Get a list of all active user accounts (61201 accounts, 3 Mb file); substitute the USERNAME and PASSWORDwith those of any active FAS user (I used my own):
    • curl -d 'user_name=USERNAME&password=PASSWORD&login=Login' \
      'https://admin.fedoraproject.org/accounts/group/dump' > users.list
  3. Run the scriptspecifying the package version:
    • ./rhpkgers.py f17 maint.list users.list

I will be getting a git repo started on Fedora Hosted soon to put relevant bits in, and I’ll update this post with a link to that repo when ready.