Where it comes to talking about all the technologies involved, I admittedly fell a bit short. I haven’t been keeping up on every TLA in the related technical spaces around oVirt and KVM, and I didn’t get through a full research on all the topics before the presentation. One of my strategies, though, is to just run this presentation to learn what is and isn’t appropriate for a presentation. So I told the audience it was a new presentation, thanked them for being beta testers, and acknowledged that some in the audience certainly know more on the topic than I do and I appreciate chiming in with answers.

Which happened a few times, thank ye gods and goddesses.

In addition, I chopped up the original 21 slide presentation in to 91 slides, with each slide covering one topic. This is similar to one paragraph for an idea when writing. The decision to do this came from a late-Saturday-night discussion with Josh Berkus, who has some fame and skill in presenting. (Once I learned that a slide of mine from a State of Fedora Lightning Talk had made it in to Josh’s deck-of-shame – slide 5 in this PDF -  I figured it was worth  a rethink-of-approach. Hey, we all make mistakes.;-D ) The 91-slide version was not optimal, but it was better than the 21-slide version.

Now, to help this slide show be more useful, I will do my part in filling out the notes sections where I actually know what I’m talking about. Jason Brooks is working on a consolidated deck that improves on this one, and I’ll get my notes in to that one as the canonical.

Although a brand-new presentation, I think this one went over pretty well. All of the material I know by heart and can speak on extemporaneously (i.e., for many hours on end). For this reason, my notes section is unusually (for me) empty. I’m going to work on filling out those notes – that makes it more useful for others to reuse, thus adding more fuel to the Creative Commons licensing – and I’ll make a generic version available in TheOpenSourceWay.org presentations directory.

This was a good enough talk that I think it can be useful again in other locations – it really does a good job of distilling a huge amount of the information you need to start, sustain, and grow an open source project. I’ll be submitting it other places, hopefully more people agree with Gareth and put me on somewhere!

• FOSS Mentoring on Friday, I talk at 3 pm.
• SCALE: The Next Generation on Saturday at 11:30 am, Malakai, Saskia, and Mirano are presenting for the youth event.
• In the Cloud and Virtualization track on Sunday at 11:30 am, I’ll give a second talk on oVirt.

So my Friday talk at 3 pm is,”How to start and sustain an open source project of any size“. I’ll be going through the start/sustain bits, and trying to do some actual work with the audience. I’m hoping some of the audience will be interested in starting a project, or already working on it, and we can do some work for their efforts as a group.

Also on Friday I’ll be attending the Fedora Activity Day (FAD) that starts at 10 am – I’ll be there to help and learn.

My daughters are joining their friend to give “Ultimate Boredom 2.0” at 11:30 am on Saturday as part of the SCALE: The Next Generation youth conference. I think the talk title is an allusion to how much they think they will bore you (ultimately), which must be greater than the two other times they have given a similar talk (2.0). In addition to talking about how they’ve participated in open source projects, they’ll cover some of their favorite free/open source software – last I saw the presentation covered GIMP, OpenShot, TuxPaint, and Hydrogen.

Finally, on Sunday morning at 11:30 am I’ll be giving, “oVirt – Infrastructure and management platform for the data center“. This is a general what-is-oVirt, how-did-it-come-to-be, where-might-it-be-going presentation, similar to the one Carl Trieloff gave at the start of the oVirt workshop in November 2011.

See you in LA!

This event is the open sourcing of the code behind the Red Hat Enterprise Virtualization (RHEV) management console. These assets have been rewritten in Java from the original implementation by the team that was originally from Qumranet before their acquisition by Red Hat.

As with the rest of the open source virtualization stack (Linux kernel, KVM, etc.), we all benefit the most from a strong, sustainable open upstream. Having that upstream dominated by one vendor will greatly restrict the innovation possible by the project. For this reason, Red Hat went out to a number of interested parties, offering a seat on the initial board (which is later filled meritocratically) for any organization willing to put 10 resources to work on the project. For the initial board, that list is Canonical, Cisco, IBM, Intel, NetApp, Red Hat, and SUSE.

I got involved in this because the project’s technical director, Carl Trieloff, called on our Community Architecture and Leadership team to help with community scaffolding for the launch and beyond. Since then I’ve been building the ovirt.org website, setting up the communications, creating and filling the wiki, helping with the source repository, starting an open services infrastructure team so all community members can help, and organizing this workshop with Robyn Bergeron.

So this is what I’ve been up to, which I really should have been writing about, but … ah, life.

Right now we are looking for someone who can take over significant focus on Fedora, as well as provide skills in community consulting and strategy for other Red Hat efforts.

Myself, I’m looking for another rounded, senior-level person who can apply the open source way – thinking & doing – as well as help make practitioners out of other people. Just spread this word around – someone out there hasn’t thought her or his self in this role yet, but could be.

Looking at this role, it is an example of job skills and merit that can be learned and earned while working on open source projects. You may not be currently in the field of “community relations and management”, but you may already have all the skills needed to teach and do the open source way inside and outside of software projects.

And you certainly don’t need to have come up through the Fedora Project, but that can’t hurt. Historically, we do what anyone would do – hire the people we know are great at doing the job we want done. Your work in Fedora should reflect that. If you have other open source project experience, it’s out there. If you’ve been practicing the open source way correctly, you’ll be able to show us that experience using open content in public archives.

Check out the job posting. I’m not in control of the process, but I think the location could be flexible for the right person, so it’s worth considering even if you don’t want to move to Raleigh and be our voice-in-the-seat-at-Red-Hat-HQ.

If you are someone who I would recommend anyway – so I would be biased toward you in a selection process – I’d be more than happy to pass you into our resume system with a recommendation.

(Updated to fix my incorrect interpretation of the job requirements; having worked in the Fedora Project already is a written job requirement.)

One reason I’m going to FUDCon is to connect with people about open source cloud communities. While there isn’t enough momentum for an entire conference (yet), consider that at FUDCon Tempe this year there were enough discussions of cloud-related topics that they practically formed a track.

What will the cloud discussions at FUDCon Milan be?

I know of a few cloud/virtualization-related developers who are attending:

• Two folks from Red Hat’s Brno office who work on the Aeolus Project, Francesco Vollero and Michal Fojtik.
• Marek Goldmann, who works  on BoxGrinder as an oddfellow.
• Some other folks from Brno who may work on other parts of the operating system platform that are relevant to the cloud, at a very deep level?

OK, that’s not a very long list.

Who else is going? Who can we invite?

What interest can we generate? Anyone want to do  do a “build a cloud with Fedora” or something that attracts systems folks?

What is interesting for developers who want to build on top of these clouds as infrastructure and platforms?

One of us from the Cloud SIG can talk about the general activities in Fedora, so I count at least four cloud related talks in those I’ve listed here.

Partner Technical Evangelist

Red Hat has large cachet with upstream, open source developers, and our relationship with mainstream, corporate developers is fair but scattered. Strong in the Java area, nice developer studio, but what’s the cohesive story? How do we interact as a whole with software vendor (ISV) partners and developers who work for our customers?

It seems likely that the above job will interact and work in those areas. In fact, the role is described as rather senior – perhaps someone with the right skills and personality could wrestle serious improvements to the Red Hat developer experience for customers and vendor partners? This role is inside of the ISV ecosystem team probably because of a need for evanglism to ISV developers as well as customer developers.

When I use the term corporate developer, I mean the person who builds and supports applications that run inside of enterprises and SMBs, written by the staff for the staff. These are folks who are looking for:

• Best practices for developing on top of  Red Hat Enterprise Linux (RHEL).
• How to package and deploy software the Red Hat way.
• Tutorials on how to use developer-focused tools in a Red Hat environment, from JBoss through Eclipse to Red Hat Enterprise Virtualization (RHEV).
• Forums to find answers and ask questions.
• 24×7 non-interactive support and solutions, so they can get their work done at their own pace.

You or anyone you know interested in this sort of work? Contact me or just apply yourself.

As I approach my tenth year at Red Hat this coming October, I’m currently focusing on helping wherever I can with our new and existing cloud community efforts, from Red Hat OpenShift to the Fedora Cloud SIG. I’m also working more deeply on The Open Source Way, externally as the canonical upstream location for how-to and why-to do projects within community, and internally as a community consultant across Red Hat. More activity coming on The Open Source Way mailing list, if I have anything to say about it.

“What’s wrong with the actual Fedora lists?” Robyn asked me. “We’re just not being very true to our roots when we have a special list just for Red Hat folken.” There’s a very real risk that people will reckon the list receives priority by other Red Hatters (it might, that’s the point!) and is elitist (“Too good for our lists, eh?”)

I don’t disagree with those concerns, and here’s what I’m thinking for reasons and mitigation:

1. People inside of companies using software to get their work done may perceive external community lists as outlaw places, as unsafe (because some discussion might touch upon confidential materials, devolve to attack/defend, etc.), and – honestly – scary unknown territory. Speaking with colleagues for support (“Hey, Jo, how do you …?”) gives people the feeling that the responsiveness of the community is going to be proper to the situation – no one other than a Red Hatter can know how important it is for Foo Bar from Sales to get her presentation to work on her Fedora 15 laptop. (That, I believe, would be the perception by people of why to use an internal-only list; hard to battle that perception without first getting them in to a  common forum – albeit a private one – to hammer out the real issues.)
   • For example, I know folks who first had to be hand-held through using internal IRC, then they got their entire teams to use it, and after a number of years, were willing and interested in venturing in to the open community IRC. I am confident that final step happened only because the earlier ones came first – for some people, the long-time in non-public space is perhaps the only way they’ll make the transition.
2. Desktop Linux users often get help from their local user groups, from special for-newbies-only mailing lists, and so forth. I would consider an internal fedora-users mailing list to be a similar, hand-holding gateway – ask questions here first, and if we can’t get an answer and need help from a Fedora list, either we’ll help you do that or ask for you.
3. If managers know their team members can ask questions on a private, confidential, internal list, they may be more likely to permit Fedora usage. Otherwise, there is little value in switching from the corporate standard build (CSB) of Red Hat Enterprise Linux (RHEL).
   • Sometimes people really do need the kind of software that can only be found in a latest Fedora. For example, I’ve heard from some of the big movie animation studios that while they run RHEL on their render farms, they may use Fedora on their desktops if a designer or developer needs what can only be found in a super-modern Linux distribution. Having support when you need, where you need it from, is a good thing.
   • Similarly, folks who aren’t paid to be available helping on external Fedora lists are in fact paid and empowered by Red Hat to help other Red Hatters. It would be great to get that help to happen out in the external lists, but maybe it just has to start somewhere else first.
4. Communities need private spaces, maybe this could be one?

I would make a goal of the list to be, help internal users to gain the confidence and competence to go the external community instead. The internal list could be a training community, and those who want to graduate go on to make other Fedora lists better with their experience and point of view.

For those of you who would love to see dozens or hundreds of Red Hat worker bees who run Fedora participating on the users@fedoraproject.org mailing list … this is the only way I can think of so far that might yield more of that.

Ultimately I’m asking all of you out here first because while I know other Red Hatters might like and use the idea, it is your perception that I can never adjust by just showing you the private archives to prove it’s a reasonable approach to take. If I’m going to ask you to take our word for yet-another-hallway-discussion-being-OK, I should at least ask you before I start the hallway discussion group.

I’m curious if your company or organization does something like this. What do you think of this idea? How could it be made better? How can I mitigate the risks more?

Comments are open.

Part of the way to scale ourselves we have always done, which is to engage with other community leaders and leverage each other.  Recently I had a new idea that we could fill out our circle on education and open source by inviting people who are passionate about K12 to work within our team as external contributors and entirely in the public sphere.  Read on if this is interesting to you.

Our team’s definition includes that we are failing if we are growing too quickly by adding paid bodies to manage projects instead of building projects that scale themselves.  A project or program truly done the open source way should be able to survive and thrive without a person paid to be at the helm or shoring up all the work.  So we baked it in to our team’s methodology (and that explains why we work on ten full-time things at once, because once done right each might become a not-full-time thing that comes from and benefits many others.)

One could argue, quite correctly, that our team is currently extended in to the community via all the community leaders we are in regular contact with, where we mutually support in varied ways.  Primarily in Fedora and TeachingOpenSource.org, but others as well.

What I’m imagining is a person, or a few people, deeply passionate about open source, young people, and education.  We recognize that a big selling point for people is that FOSS can save cash-strapped schools a lot of budget.  However, we think the higher goal is to teach open source participation.  It’s as easy as contributing to a Wikipedia article or testing and sending feedback on Sugar activities.  The point is to show kids that they can tinker with their own knowledge, and we start by showing the teachers how to tinker.  They already tinker with what they can – many teachers jump around a textbook if they see fit.  Our goal is to make them feel the same way about technology and the wider world of information, that it is something they can manipulate, model that manipulation to their students, and kickstart a new generation of makers, autodidacts, and teachers of learning it yourself by doing it yourself.

Here’s how I imagine such a community leader role description would go.   Think of it as a first draft.  What would you add?

And more importantly, would you be interested in doing one of these roles?

FOSS in Education Community Leader Role Description

You have a passion about free and open source software (FOSS) and education.  In particular, we are looking for people who want to work in the primary education years, sometimes shortened in the United States as “K12″ to signify thirteen years of primary education.  You can focus on one or more niches in the K12 area, such as public schools, charter schools, private schools, homeschools, foreign or second-language schools, etc.

In this role you will be expected to:

• Choose one or two niches to focus on.
• Attend weekly or bi-weekly bi-monthly meetings on IRC with other members of the community leadership team (CLT), as set by consensus.
• Set goals for the quarter and year, and report status and progress back to the CLT.
• Potentially travel (regionally, nationally, or internationally) for education conferences.
• Interact with school boards, principals, teachers, and staff at all levels about teaching open participation and collaboration.

You should have or be willing to develop skills in these areas:

• Research and writing.
• Public speaking.
• Community organizing, which is done from within and not on top of.
• Fedora Linux and Sugar on a Stick.
• Being a catalyst so others are able to do things (versus doing everything yourself).

The role includes on the job training in being a catalyst in communities (PDF includes full speaker notes.)

While you retain copyright on all your work, you are contributing all your work to e.g. TeachingOpenSource.org under the Creative Commons BY SA 3.0 Unported license.

A last story if you’ve read this far …

Once upon a time there were two build systems and two sets of packaging standards around Red Hat and Fedora.  They were very similar, but were in fact forked from when Red Hat Linux was split in to Fedora Core and Red Hat Enterprise Linux.  Primarily, the Fedora packaging standards, tools, guidelines, and processes greatly evolved in the first few years of the fork, compared to their kin inside of Red Hat.  When the Fedora Project brought all the Core packages out to the open community infrastructure, the Red Hat engineering teams had to retool and reunderstand these new systems.  They adopted the packaging guidelines that were driven for six releases by open community process.

There are many examples of this, where everything from code to content to policy and processes that are developed in the Fedora Project are adapted or used directly by other parts of Red Hat.  Red Hat Enterprise Linux (RHEL) is a primary example of that, but also consider how important the entirely community run Extra Packages for Enterprise Linux (EPEL) project is to Red Hat and our customers.  If you don’t know, it’s very important.  I don’t know a service or support person who doesn’t direct customers to EPEL on a regular basis (until the customers figure it out, and maybe take the next step of participating directly in EPEL for shared benefit.)

So the deal is this:  while there can be zero guarantees or promises, you can look to history to tell you there is a very good chance that your doing work and helping set our policy on K12 FOSS education will find it’s way up in to the education strategy that we work on for Red Hat.  Our team’s role is very strategic, more than probably any other similar team exposed by Red Hat to open community work.  You can take advantage of our sharing nature and our desire to use your smart and capable brain to help us figure out this part of the future in K12.

People always say, if you complain about something in FOSS be prepared to do something about it.  We can offer you an opportunity to become a catalyst and center of gravity around K12 and education and teaching participation in FOSS, which means a chance to make a difference in exponential and surprising ways.

Interested?  Comments are open below, if you are ready to get used to the always-in-the-open discussions.  If not, contact me directly and let me help you help us … help you … help everyone.

Note: It should be clear from this site’s URL that these are my own, personal opinions and don’t necessarily represent those of Red Hat, my team at Red Hat, the Fedora Project, TeachingOpenSource.org, or pretty much anyone else in the entire universe.  I am noting this because I want it clear that I am not giving any kind of picture in to Red Hat’s hiring plans.  Also, I am not describing actual Red Hat strategies any more than discussing Linux kernel strategies tells what will be included in the next RHEL update.  I am writing this post as a way to better explain my idea to my own team, meaning that team is vetting this idea at the same time as you are.  Thus, even my own opinion here is subject to change.  This note is here because I’ve never discussed open strategy in this context and I want to set our shared expectations about what is going on here.

(Updated 2010-08-17 to meetings suggested as bi-monthly (twice a month) and decided by consensus.)