till we meet again, goodbye

This blog is now retired. Please visit my new blog.

Several of my career changes at Red Hat have been announced on this blog.

My first post was written shortly after I became the Fedora Project Leader (FPL), and this blog was set up as a way to have frequent, informal communications with the Fedora community.

After two great years as the FPL, I stepped aside to institute Red Hat's Community Architecture & Leadership team.

Simultaneous to that team growing and finding its place, I had the fantastic opportunity to live in Europe and to give some extra support to that region of the Fedora community. I made some wonderful friends, and we learned a lot about how difficult it is to build and maintain autonomous regional leadership groups in a global community. We're still learning those lessons today, and I'm glad that we're still trying to do a good job at supporting Fedora worldwide.

Back in Raleigh the last few years, the team has expanded from its Fedora-only roots. We've worked to document the theory that is The Open Source Way while continuing to put that theory into practice in both the Fedora and Teaching Open Source communities.

Which brings us to today. I am leaving Red Hat at the end of July, just short of my seven year anniversary. As a result, my roles and responsibilities in the Fedora Project will be changing significantly at the same time. Red Hat's commitment to Fedora has in no way changed, nor has the Community Architecture team's commitment to Fedora.

In addition to Fedora's established leadership team, Harish Pillay is stepping into the management and leadership role that I've been filling. He has already shared his thoughts about this transition, and I have no doubt that the team will continue to grow and be successful under his leadership.

Harish will be looking after more than just Fedora, but Karsten and Mel, along with our interns (Ian, Sebastian, and Ryan) are all still part of the Community Architecture & Leadership team, and they are all great contacts whose Fedora roots run deep.

Red Hat has been wonderful to me, but it is time for a change in direction. I'm off to Seattle in August to join Amazon Web Services as a manager in their Kernel & Operating Systems group. My team's focus is on the overall customer experience of using Amazon Machine Images (AMIs). This includes accountability for the Amazon Linux AMI, working with external AMI vendors, and handling premium support for customers running AMIs.

In my spare time, I will still be around the Fedora Project (most likely the Cloud SIG), so this isn't a goodbye, but rather just a step along a more broad continuum of collaboration. You will all hear plenty more from me down the road.

When I stepped aside as the FPL, I said that it had been an honor to have been trusted with a leadership role in the Fedora community, and that I was deeply grateful to the community for accepting me and giving me an opportunity to lead and to earn respect. Those sentiments are just as strong today. It has been an honor and a privilege to have worked at Red Hat, and I will always be grateful for the opportunities that Shadowman has given me. My thanks to Jim, Matthew, Michael, and countless others within both Red Hat and the Fedora community.

fedora regional support budget summary

At the end of July, we'll be 5 months (42%) of the way through the fiscal year, which begins each March 1. I thought it would be useful to compare this year's spending to last year's, so that our regional Ambassador teams (as well as FAmSCo in an oversight role) can do some informed planning.

By region, here was our spending last year:

* NA - 48% (plus a FUDCon)
* EMEA - 29% (plus a FUDCon)
* India/APAC - 16%
* LATAM - 7% (plus a FUDCon)

This year, our Fedora regional support budget is about the same as least year's, but we are quite a bit ahead of pace in our spending. As I said, at the end of July we will be 42% of the way through the year, but we've already spent just under 68% of our budget. All the people who have responsibility and accountability for Fedora's regional spending will have to be careful in the second half of the year, and provide enough oversight to make sure that events stay on budget, and that budgets are clearly set in advance.

What do our regional percentages look like? The breakdown is similar to last year, though NA is down a few points and LATAM is up a few points. Also, this year each region of the world will also have a FUDCon this year.

As of July 15:

* NA - 44%
* EMEA - 30%
* India/APAC - 14%
* LATAM - 12%

In summary, our total regional support spending last year and this year is budgeted to be about the same. Our pace of spending in the past 6 months has really grown, and as a community we have to be careful about getting back on pace, while still providing our worldwide contributors with the support that they need in events, swag, and regional leadership.

packaging play-by-play

Over the weekend, I watched as Paul worked his way through the packaging of Pinpoint, and it got me thinking about what I see as the gap in our ability to teach packaging to others.

We've got tons of resources that discuss how to package, and how to get your package into Fedora, but what I'd really like to see is a presentation that shows the entire play by play.

What do I mean by that?

Well, let's try to re-create the different things that Paul had to do in order to package Pinpoint, which is probably about a 4 or a 5 complexity, on a scale of 1 - 10.

* Make sure his computer has all the right tools.
* Make sure he has all the proper Fedora permissions.
* Understand not only what all the different fields in a spec file mean (which we have good documentation for), but also figure out what to actually put into those fields. How does a person know if what is being entered is right, wrong, or right-but-not-optimal?
* Building the package and testing it.
* Submitting the package for review.
* etc.

I think we need to get some presentations that can be shown in Fedora Classroom or in FUDCons that actually walk someone through the entire play by play, and explain the why and the how for each step.

We should do this for packages that are both really easy (some Drupal and Python modules, perhaps) as well as packages that are mid-level complexity. Down the road, maybe we get into an advanced class.

Here's a specific example of what I mean, taken from the wiki:

BuildRequires: A comma-separated list of packages required for building (compiling) the program. These are not automatically determined, so you need to include everything needed to build the program. There are a few packages that are so common in builds that you don't need to mention them, such as "gcc"; see the Packaging Guidelines for the complete list of the packages you may omit. You can also specify minimum versions, if necessary, like this: "ocaml >= 3.08". You can have more than one line of BuildRequires (in which case they are all required for building). If you need file /EGGS, you can get its package by running "rpm -qf /EGGS"; if EGGS is a program, you determine its package quickly by running "rpm -qf `which EGGS`". Try to specify only the minimal set of packages necessary to properly build the package, since each one will slow down a "mock"-based build (e.g., try to use sed instead of perl if you don't really need perl's abilities). Watch out: Some applications permanently disable functions if their package isn't detected during the build; in those cases you may need to include those additional packages. If you have trouble figuring out this list, the "auto-br-rpmbuild" command (from the auto-buildrequires package) may be helpful.

I can read that and have an idea of what is being said, but until someone shows me both a trivial and a non-trivial example in practice, I won't really understand how to go about figuring these things out for the package that I want to create.

There's an example of a spec file for the eject utility (which is probably a 1 or 2 complexity), but nothing that shows someone how that example was actually created, and that's a key piece of learning that is missing.

Packaging is one of those things that seems really difficult, until you have a good teacher who can show you the best ways to do it. Passing on good, well-established knowledge is critical, especially if we want to give newer contributors a way to take over the maintenance and new packaging of easier projects.

southeast linux fest, day 2

Saturday at SELF was a pretty standard conference day of talks and hallway chats. Paul wrote some nice words about my talk.

The abstract for my talk was:

Close to 100,000 computer-related degrees are awarded each year in the USA. How many of those students are begininng their careers with any experience working in real projects, or with open source best practices? How do we grow that number? This talk discusses the intersection of The Open Source Way (TOSW) and educators and educational institutions, including the growth of the Teaching Open Source (TOS) community and the Professors' Open Source Summer Experience (POSSE) program.

And here are a few of my notes:

* Why does Red Hat care about education?
* How does Red Hat's education strategy parallel its engineering (Fedora -> RHEL) strategy? How does it differ?
* Audience discussion: are students beginning their engineering careers with any experience working in real projects?
* Talk about The Open Source Way as a set of concepts and theory --> how to build communities, how to influence communities.
* We put that theory into practice in communities like Fedora and Teaching Open Source.
* Key blocker for getting students involved in real world projects is mentoring, on-boarding, and setting folks up for success.
* Learn by doing, and learn while doing. Age and credentials don't have to matter on the internet, and discuss examples from Fedora. Also talk about how high school and university students have served as teachers and technical gurus at POSSEs, teaching university professors about things like git, packaging, etc.
* The digital abundance of the internet means that everyone can be a teacher, and everyone can access training and educational materials.
* The internet is the mechanism, and TOSW is the methodology.
* Talk more about POSSE and its evolution.

Southeast Linux Fest was a great weekend -- it was a nice morale boost to see some Fedora contributors and Red Hatters who I don't often spend time with face to face, and I believe it is critically important that Red Hat support its regional hometown conference.

southeast linux fest 2011, day 1

Friday at SELF began with a Fedora Activity Day in which we discussed a few ways to simplify FUDCon budget processes, and Fedora finances in general. The primary action item for me is to take advantage of the fact that we now have 3 community credit cards, and to use the Finance SIG, which is in need of a clear purpose, as the place to collaborate in public about how those cards will be used, the processes that we need to have in place, etc.

I said hello to Ben Williams and Mark McIntyre, who are taking care of the booth. Things are looking good. Mark and Ben deserve a special thank you for burning a bunch of media at the last minute, since our official Fedora 15 media suffered a shipping delay, leaving them no choice except to display adaptability. UPDATE: Our media was delivered at 9:30 on Saturday morning, just in time for the start of the day. Our Fedora presence is complete, and high quality.

In the afternoon, I spent a few hours quietly finalizing my own SELF talk, as well as going through some Red Hat email and making a list of my important TODOs for next week.

The speakers' dinner was excellent, followed by some social time with colleagues and Fedora folks whom I don't often see.

southeast linux fest 2011, day 0

Southeast Linux Fest is effectively Red Hat's hometown conference, so it's great to be here once again, and to see a wide variety of Red Hat folks -- people who work on Fedora, engineers and sales engineers who are responsible for RHEL, and a nice brand presence via

Last year I delivered the closing keynote talk, and this year I'm part of a 2-talk "open source and education" track, with the other speaker being my good friend Greg DeKoenigsberg, formerly of Red Hat and current CTO of the Institute for the Study of Knowledge Management in Education.

Our trip down from Raleigh to Spartanburg began following a Fedora 15 release party held at Red Hat's headquarters, attended by about 60 people. Jared spoke about the release and gave a demo of GNOME 3. Paul spoke a bit about the importance of the Fedora to RHEL pipeline. Cupcakes were consumed by most, and several people had a chance to do some interviews on camera, to be edited into an upcoming Fedora 15 video.

Eight of us made the drive down from Raleigh in a big van, which at the time it was rented had exactly 3.6 miles on its odometer. We made the obligatory pit stops at Bojangles and Chick-fil-A, where banana pudding milkshakes were acquired.

Paul, Jared, and I had a dinner discussion that was a Fedora 15 retrospective -- not from the bits and bytes side of things, but rather from the big-picture perspective. My opinion is that the single largest problem facing Fedora these days is an insufficient amount of visibility and communication into what people are doing, what they are thinking, and why certain ideas or strategic choices are being made or rejected. There is a silent majority in Fedora of people who are quietly just getting stuff done, but I think that we all (and I number myself in this group) need to do a better job of being more vocal, consistently.

On the good side, I think that Fedora 15 represents a huge success from a change management perspective. In the past year, we've turned over Fedora's Project Leader, Program Manager, Infrastructure Leader, and Release Engineering Lead, but nonetheless a quality release was shipped, and was done so in a timeframe that is pretty consistent with past history. People should take a moment to recognize that achievement and congratulate each other.

More from SELF soon....

aggregation and origination

Mark Webbink was Red Hat's general counsel, and our intellectual property guru for many years, and back when I was the Fedora Project Leader, Mark was the guy with whom I worked with on a number of legal-related issues. Two in particular stand out.

The first was the winding-down of the Fedora Foundation and the second was the removal of a license agreement during the firstboot process along with cleanup of what was then called Fedora's EULA.

Mark recently took over as the editor of Groklaw, and today he wrote about the state of contributor license agreements (CLAs) in different open source projects, calling the new Fedora Project Contributor Agreement "a vast improvement over any of the other approaches discussed".

Good stuff!

Mark also writes: "But one of the things the maintainers of the Fedora Project came to realize is that Fedora is primarily an aggregator of projects, not an originator of projects."

In the context of Mark's article, which focuses on the role that a Linux distribution serves as an integrator and curator of many open source projects, this statement is 100% correct. From the perspective of licenses and of growing the commons of open source code, the origination point of a project doesn't matter. The rules for getting that project into the Fedora distribution are the same no matter what.

Today is also the release of Fedora 15, and it's important to remember that the Fedora Project values the innovation of new features and values being the first to bring those features to an audience, and that many features do originate within the Fedora Project itself, or from its corporate sponsor Red Hat.

Let's take a look at just a few of the big Fedora 15 features:

* Large chunks of GNOME 3 originated from within the Fedora Desktop team and from Red Hat employees who hack directly on upstream GNOME, and then was aggregated back into Fedora.

* Systemd originated in the greater Fedora community, which is where Lennart has done a lot of his work on the init system, audio, etc. over the course of many releases.

* LibreOffice is aggregated into Fedora, based on the work of that upstream project.

* The consistent network device naming is aggregated from work that Dell has been leading.

* Boxgrinder is a combination of originated work from both Fedora and JBoss folks, as well as aggregated work from the people who maintain our Ruby stack.

The Fedora distribution serves as an aggreation point for thousands of open source projects. The Fedora Project is also an originator of many of those same code bases.

borrowing a red hat summit idea for fudcon

I'm up in Boston for some Red Hat meetings, and I'm staying in the same hotel that is being used for the Red Hat Summit.

When I checked in and indicated I was with the Red Hat group -- which is for all Summit attendees and Red Hat employees -- I was given a room key on a customized key card with Red Hat artwork, messaging, and the Summit logo.

The name of the company that made the cards is printed on the back, so we can do some research into what it would take. But if the cost isn't prohibitive, I think this would be a cool thing to do at a future FUDCon, since it combines something that people need to have anyway with (if the artwork is cool) a souvenier.

in which i destroy my laptop, and am introduced to gnome 3


Back up your stuff. I spilled a can of Coke on my laptop today, breaking it. It took me about 5 hours to (a) find an old laptop, (b) get Fedora 15 Beta onto a USB, (c) install it, (d) restore all my stuff from backups, and (e) begin the re-configuration process.

If I didn't have backups of my computer, I would have lost years of data, both personal and Red Hat related. I rsync my laptop to an external hard disk every day, and I was able to do so immediately after spilling the Coke and before the machine stopped working, which allowed me to have zero data loss.


I guess I picked a good day to fry my laptop, since Fedora 15 Beta is not even 24 hours old.

I've seen a lot of the commentary about GNOME 3, of course, but I've more or less ignored it since I was still using GNOME 2 and I figured that when I did try GNOME 3, I wanted to do so with as open a mind as possible, thinking about it from the perspective of a new Fedora user rather than simply as someone who has his own particular ways of doing stuff that might now have to change a bit -- kind of like when you get a new car, and some of your little habits have to change.

First of all, anyone who doesn't stop to acknowledge the TREMENDOUS engineering and design effort that is GNOME 3 is simply not being honest. You don't have to like every feature to recognize that a huge amount of work has been done, and that the people who did that work deserve a lot of credit.

Secondly, the laptop that I pulled out of a closet is the one that Red Hat bought me in 2007, and GNOME 3 runs faster on that laptop than GNOME 2 ever did. So from a performance point of view, I'm really impressed. I don't know how much of that is GNOME 3, and how much of it is the rest of Fedora 15's plumbing.

Now I'll mention a few of my initial reactions to GNOME 3, which may be of interest to folks who are considering the usability side of things, and who want more data about where an experienced Linux user fell down.

ITEM 1: When I clicked on my name in the user-switching applet, I was immediately confused by the "Available/Busy" option. If I change that, what happens? What applications are hooked into that? I'm not logged into anything other than my system, why is this here? Why is my desktop trying to manage my online social networking status? How do I get it to stop that?

ITEM 2: I had to use Google to figure out how to restart my system after the Live USB install was complete. I tried some of the options that I saw in the menus, to no avail. Never in a million years would I have thought to hold down alt while in the user menu to get reboot/shutdown to appear. I must have missed something totally obvious, but I felt like a complete moron thinking "Max, you have a degree in computer science and you can't figure out how to turn off your computer".

ITEM 3: I guess this is part of where an open mind is necessary, and a willingness to have my usability norms challenged, but it's strange to not see any actual stuff on my desktop, and to have to go into the file browser if I want to be able to double-click anything. I used to use the GNOME tweak UI package to remove ~/Desktop and to make ~ be displayed as my desktop. I was able to replicate this by editing ~/.config/user-dirs.dirs, but it still doesn't actually show any files on the desktop. That was useful for me, since things were arranged and organized in a way that visually made sense to me and let me know what's important, what file I want to work on next, etc. Now I've got a ton of empty space, and I can't left click, right click, or do anything other than go to the "Activities" menu. I feel like I'm not understanding what's supposed to be a key usability insight or change. GNOME 3 makes me feel dumb.

ITEM 4: I miss being able to easily minimize stuff, though I'm learning slowly that mousing over to "Activities" basically does the same thing. New paradigm understood and being adjusted to!

ITEM 5: Workspace switching from ctrl-alt-right to ctrl-alt-down is only annoying to an old user like me, but wouldn't be to a new user. However, it was not immediately clear to me that there even were multiple workspaces, and I don't quite grok yet what makes a new one appear as an option. Also, it would be nice if there were an easy way to edit keyboard shortcuts. If there is, I can't find it.

ITEM 6: My day to day workflow is contained in gnote, and not having that application startup automatically with the hotkeys just working is very jarring to me. I miss a lot of the stuff (like gnote) that used to be on the panel, including the multi-timezone clock applet. I don't know what (if anything) I can do about this. Again, GNOME 3 makes me feel dumb, like someone who is doing everything wrong and isn't capable of understanding why.


What else about F15 Beta, that isn't GNOME related?

ITEM 7: I really like the current It's probably been a year or more since I actually looked at that site, and it's looking nice! I wish I knew to whom I should give credit for that work.

ITEM 8: Firstboot gave me an opportunity to add my non-root user to sudoers automatically, which saves a step of post-install configuration.

ITEM 9: When I ran the software updating application, it didn't prompt me for my root password. Is that a PolicyKit thing? I know that's not a new feature to Fedora, but with Fedora 15 I seemingly no longer know how to revert it. I like having to enter my root password.

ITEM 10: This ancient laptop of mine has a 50 GB hard disk. The auto partitioning gave me 25 GB of /tmp of / and 25 GB of /home, which doesn't leave me enough space for all of my actual files. I wasn't paying attention, so I didn't notice this until post-install. I know there's a graphical front-end to LVM that I might be able to use to change this, but I can't find it, which ties back to my comments about not being able to find some settings in GNOME 3 that were easily found in GNOME 2.


ITEM 11: I'm not allowed to "launch" more than one instance of an application. If I want a second terminal window, I have to open it from within the first -- I can't simply click on the terminal again and get another.

ITEM 12: Alt-tab only cycles between applications, not windows or instances of those applications. To switch between instances of the same application requires more keystrokes, and slows me down as a user. I was able to solve this by installing gnome-shell-extensions-alternate-tab.