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.

“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.

The details:

• What: Lindependence Hour to discuss GNU/Linux, software freedom, and open source.
• Where: Santa Cruz Coffee Roasting Company, 1330 Pacific Ave., Santa Cruz, CA. http://www.santacruzcoffee.com/
• When: Wed. 29 Dec. 2010 from 6 pm to 7 pm PST (1800 to 1900) — repeats last Wed. of the month.
• Who: You, if you use or want to use Linux, such as Fedora, Ubuntu, or Android.

Any planning that I do will also include Fedora components, so we’ll keep those details on the Fedora wiki.

Here’s his list of what is “the secret of success for Canonical”:

1. “Methodically produce incremental upgrades to its OS.”
2. “It is transparent about its goals and plans.”
3. “It releases its software on schedule.”
   1. “In fact, this incremental approach is Ubuntu’s most potent competitive weapon against rivals Microsoft Windows and Mac OS X.”
   2. “[I]ncremental releases on a reliable schedule is a quality that appeals to IT departments.”
   3. “That allows IT to test and roll out OS updates much easier and quicker.”
   4. “Ubuntu has established a disciplined upgrade cycle, made it a top priority, and stuck to it. Canonical releases a new version of Ubuntu every six months.”
   5. “This type of transparent, methodical, and incremental upgrade cycle is the future of software.”

If you are familiar with open source development methodologies, you will realize you can substitute just about any successful FOSS project for “Canonical” and “Ubuntu” in that article and it means just about the exact same thing.  In fact, the six month release cycle, which Fedora has been following for as long as Ubuntu (longer if you figure in Red Hat Linux before), we may have inherited that from GNOME, who probably learned it from Mozilla! In fact, the six month release cycle has been followed by Fedora since we inherited it from Red Hat Linux.  The story I hear is that GNOME adopted a time-based release schedule from Red Hat Linux, and others (Mozilla et al) followed suit.  In other words, Ubuntu’s process of incremental, transparent, and rapid and regular scheduled releases is the great-grandchild of Red Hat Linux in the 1990s!

Hiner’s whole list looks like it was derived from “Producing Open Source Software” (Fogel), yet the article reads as if this is something in OSes that only Canonical has figured out.  In fact, what he describes is part of the whole reason Red Hat Linux became Fedora and Red Hat Enterprise Linux.  Don’t think for a minute Canonical didn’t notice and learn from that, too.

Here is my corresponding list from The Open Source Way for each of the virtues that Hiner ascribes to Canonical:

1. Do not forget to release early and release often and Embrace failure
2. Practice radical transparency from day zero and Take extra extra extra care to have all discussions in the open and Take even more care to do all design and decisions in the open
3. Use a predictable schedule type and stick to it and Release early and release often is for more than just code

In case you are wondering, I didn’t learn all that by watching Canonical or any other single entity

It seems that really what Canonical has done best is convince or allow the media and others to think that they are Linux.

Chris Blizzard pointed out to me that is also the case for Red Hat, that it is equated with Linux and FOSS development.  Yep, and I don’t like it when that happens, either.  In fact, one important part of the Fedora Project legacy has been making it clear there is a lot more to a freed OS than just one brand.

(Article updated regarding the six-month release cycle history after I received several corrections.  Apparently I also forget how much the FOSS world learned from Red Hat over the years.)

Our Fedora presence is growing, both in depth of roots in the area and the scope of what we are trying to do.  A local Fedora Ambassador is organizing the Fedora Project expo presence.  There are a few stalwart Fedora community members flying in from afar, and Larry, the kids, and I are making the full pilgrimage via wifi-and-XO-laptop-sporting minivan.

In addition to contributing to the Fedora effort, I’m going to be representing Red Hat in talking about “Being a catalyst in communities – the scientific facts about the open source way“.  I’m really excited because the SCALE organizers have asked me to present that as the Saturday morning keynote.  Yeah, you heard that right – first keynote for little ol’ me.  Instead of flying in a rock star from remote, a local boy is going to represent.

Where last SCALE 7x was the first time we ran the revamped Fedora Activity Day (FAD) program, the FAD model has been richly tested and proven over the last year.  A FAD is a focused work effort by Fedora contributors, usually around one or two topics.  This year we are going to run our second SCALE-based FAD on Friday.  We’re still looking for a topic, so if you are thinking of coming there is still time to influence the planning and preparation.

On the Friday before the expo weekend are a host of other SCALE mini-events, including the Women in Open Source (WiOS) summit.  Our daughters, who did a lot of hard work as self-described Fedora Mascots last year, are presenting “Ultimate Randomness – Girl voices in open source” at WiOS at 10 am.  They are going to talk about how they use and contribute to open source, then take questions from/have a discussion with the audience.

I also see other talks from the ecosystem around Fedora and Red Hat, including Richard Fontana on “Improving the Open Source Legal System”.

See you there, especially Saturday morning right after registration.

Fedora Mascots make the booth look even cooler.

The project is going to run a MediaWiki instance and git+gitweb, maybe with a few plugins, and that’s it to start.  Mailing lists?  Possibly soon.  Other stuff?  Possible one day.  So, room to grow with a relatively simple site.  Not intending for a huge amount of traffic to start, ability to scale should be built in.  Modest data/database needs expected.

The thing is, I’m spoiled by Dreamhost, where I host all my personal projects.  I’m happy enough with them for that.  They use Debian and a (I think) a custom toolbox that us customers use to do a wide range of activities.  I can hit my registrar to register a new domain name, then host it,  load it up with a selection of LAMP software such as MediaWiki and WordPress, and have access via ssh to make web site building easier, all of this within about 30 minutes via the Dreamhost web app.

While I’m fully capable of taking a bare metal box, spinning up RHEL or Fedora, and configuring everything from DNS to LAMP, I don’t want to.  And Red Hat no longer pays me to be a sysadmin.

If you know of something that fits the bill, email me or drop a note in the comments on this post.

The below how-to information is copied directly from http://fedoraproject.org/wiki/How_to_install_Moblin, and is used here thanks to the CC BY SA 3.0 Unported it is licensed under:

Moblin is a lightweight Linux desktop environment especially suited for small form computers (netbooks et al).

Installation is straightforward.

Using the command line

1. Open a terminal (shell).
2. Install the Moblin group: su -c 'yum install @moblin-desktop'

Using the graphical package manager

1. Go to System > Administration > Add/Remove Software.
   • Note: the name of the Add/Remove Software application is PackageKit.
2. In the left side pane choose Moblin desktop.
3. Click Apply to install the package set.

1. Rip out whatever logic you have in ~/.bashrc for displaying the git branch at your command prompt.
2. Copy the script supplied by the git package to where you can make it an executable, such as ~/bin :
   • cp /etc/bash_completion.d/git ~/bin/git-completion.sh
3. Make the script executable :
   • chmod 700 ~/bin/git-completion.sh
4. Add these two lines to ~/.bashrc :
   • source ~/bin/git-completion.sh
   • export PS1=”[\u@\h \W"'$(__git_ps1 " (%s)")'"]\$ “
5. Reload your bashrc file :
   • . ~/bashrc

Enjoy having a peek at where you are in your git directory:

[kwade@calliope lookatgit (debug)]$ git branch
* debug
  help
  master
[kwade@calliope lookatgit (debug)]$

Early on a Saturday morning this July, Mel and I arrived at the Community Leadership Summit to help with setup. We found folks such as Amber Graner, Grant Bowman, and Jono Bacon working on the last morning touches for the day’s events.

When we walked up, the crew was rolling out two side-by-side, 30in by 8ft (72cm by 2.44m) sheets of white butcher paper.  Pen and ruler in hand and at Jono’s direction, they were making hash marks along the top edge.

“What’s this for?” I asked.

“We’re going to hang this on the wall for the BarCamp sessions,” someone explained to me.  “We’re marking a grid on this paper, then people write their session titles on these papers and hang them up using sticky-wall-putty stuff.”  The ‘papers’ were little 5in by 7in (13cm by 18cm) with a small Community Leadership Summit logo across the long edge.  There was still plenty of room to write, but it gave the pages a nice consistency and crispness:

I was able to quickly get the vision in my head of what Jono had in mind.  It would be a bit of polish that, for some of the audience and especially anyone new to the BarCamp format, gives a feeling of professionalism and attention-to-quality.  When people walk up and see the session grid all laid out, it is an attraction.  In the end, it looked about as I figured:

The irony is, a few weeks before I was on #cls on irc.freenode.net, where I told Jono a bit about how Fedora does BarCamp days.  For the session grid, I said, “We mark columns on a blank wall with blue masking tape, because blue is better.  Then we write our session title on 8.5 by 11 (A4) paper, taping it to the wall with another small piece of tape.  This makes it easy to move sessions around, combine them, etc.”  It’s also inexpensive, quick and easy, and gets the job done so we can move on to other things more quickly … such as having the sessions.  Here’s an example from a FUDCon:

There are a few more good pictures to look at, including people rearranging talks (that’s me in the middle, left forefinger on an item), a tight view of the finished schedule, arranging sessions in action, another view of the schedule showing all the masking tape glory, and someone pitching a talk in front of the in-progress schedule.

As it happened, I ended up finishing the grid, using one of the 5×7 papers as a guide.  I made a few suggestions along the way, but primarily, Jono had the vision, and I could see the value to be gained in following him through the process.  For example, while drawing row lines with a long ruler, I had a chance to reflect on this situation I was in the middle of.  In essence, I began writing this article at that very moment.  For another, I wanted folks there to know I could go along with the flow and help them enact their vision rather than spend effort advocating for my own.

For folks like me, the Fedora process has appeal.  First of all, it doesn’t require me to be there at 6:30 am to execute it.  It’s low resource usage, low technology, and a low barrier to entry.  Everyone could see how the sticking of signs was done, for example, and people could move things around, add and combine, without having to ask permission or how-to.  Sessions weren’t even combined on to a new sheet; the two or three were stacked together in one time slot.  The process invites contribution.

For another large group of people, the extra polish that Jono was doing provides the something special that makes them feel they are where they belong.  The central leadership, single vision accessible to all present, and sense of being ready-to-roll is important to those people.  It invites participation.

All of these ways of being and doing are natural, expected, and desired.  Diversity breeds innovation, quality, and a wider pool to fail … and learn from it.

This led in to a week at OSCON where I did a bit of thinking and talking about how people could be choosing their Linux distro.  Not through the idea of finding the “team” where they can be a “fan”.  More an idea of putting forward our best faces, in authentic stories written, told, and captured.  Maybe that’s the sort of service Linux.com DistroCental can provide – a way that shows people new to Linux what the day-to-day of being in one community and another is actually like.

California love, y’all.  Peace out.

I want to expand on that a bit, particularly around packaging, because my super-smart developer friends are correct about Java/Ruby/Python/PHP/et al packaging being great and sufficient … but only within their own realm. It really does fall apart as soon as you want to move outside of that realm to the shared world.

If you think of a Linux distribution as a grocery store, that’s a fair analogy.  People grow food at a farm (upstream projects), it is packaged and shipped to the store (RPM, DEB, FHS-compliant TGZ), and consumers come to the store to get the tasty food.  (It’s an incomplete analogy, because the open source consumers may also be the farmers, and the store is more like a farmer’s market in some ways, but let’s just call it imperfect and move on.)  Some people shop in the Fedora store because they like how we arrange the packaging on the shelves, and some people prefer the Slackware store for the same reason.

The grocery stores have come up with some standard ways to deal with food products.  We do it slightly differently depending on our own experience and customer-base.  Most food is packaged for shipment in boxes that are variations on the cube.  Even the apples that are stacked in a pyramid in a bin arrive at the store in an apple box.

These cube shapes are chosen because they:

• Stack tightly for shipping.
• Can be made of lightweight, inexpensive cardboard that can hold much more weight than you would think.
• Are of the right size that an able employee can move them around the store while still being stackable on a pallet.
• The packaging can be recycled and turned in to more cardboard.

Inside of the shipping boxes are often more boxes (except, for example, apples and beach balls, which come in a big box but are presented to consumers in really big bins.)  These boxes are made for the shelf to display and attract consumers.  Thus:

• They are polished and pretty.
• They stand up on precious shelf space; when a manufacturer pays to get a more prominent location on premium shelf space, the manufacturer wants to maximize the value of the effort/money spent.
• The package tell customers what the food is for, what is in it, what others think about it, when it expires — built-in advertising and information.
• The boxed packages fit nicely in the shopping cart, grocery bags, and on the shelves at home.
• Good packages conform to standards that make them reusable in the home and recyclable in to future packaging.

So along comes a new company, let’s call it Java.  And another company, let’s call it PHP.  Java, well, they’ve got this great modular idea so their packaging can fit on any shelf while using minimum shelf space.  The packages are triangular, they stack really nicely, using this cool new tool to strap them together.

Oh, the cool strapping-together tool isn’t freely available?  I have to get a set of tools for each store to strap your special boxes to my shelves?  And that tool isn’t open source?

Sorry, that doesn’t fit on my shelf and I’m not going to retool my entire operation for your “unique” needs you think you have when you could have just iteratively built on top of what works already, but you are welcome to sell your stuff out front with the Girl Scouts.  There is always room out there, and many businesses get their start that way.

Now, PHP has these cool sphere packages.  They are easy to put together by anyone around their custom package-contents, and they move down the pipeline pretty quickly compared to good old square packaging.  While they don’t sit well on the store shelves, well, we can just add more bins for them, right?

Sure, until the whole store is nothing but balls and bins and balls bouncing from bins.  Staff are running around trying to get everything to stack right, no one can read a label because it’s often turned upside down on the sphere, and you can barely tell what are the old balls and what are the new, better, faster, more secure balls.

For a Linux distro to work, hundreds of pieces of software have to work together.  They do such a good job that you can make a following selling cookies in front of the store.  But if you really want to be big/useful to your users/something more than appears a few times a year, it is really helpful if you can be in a package that fits on the shelves and in the lives of your consumers.

Once you accept the idea of packaging, relying upon system libraries, making something that can actually be buildable from source and is truly redistributable, and do it successfully for one Linux distro, then you are 80% of the way there.  Adding another UNIX-like OS to your packaging is easier.  All of this won’t make it easier to deploy on non-UNIX-like OSes, but it also won’t make it harder.