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

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

Phipps’ recent post, “Is the ‘Open Source Bubble’ Over?“, talks on the same topic and says that the true open source way has always been community and collaboration.  He and Aslett refer to Stephen O’Grady’s post, “The State of Open Source: Startup, Growth, Maturity or Decline?“, which is rich with trend analysis over the years to show that some projects  are in maturity, but overall open source is growing with all the return to community and collaboration.

This is a really exciting point they are making.  As many people know, a hallmark of Red Hat’s activities in open source has always been a focus on upstream collaboration and scaffolding for strong communities.  When we acquire a company with an existing codebase or open source community, you see a clear set of moves.  Codebases are released under open source licenses to spur the greatest open community we can, where Red Hat actively participates.  Communities are grown without an attempt to control the intellectual property.

This re-emphasis of the communities that include vendors and customers acting equally on common needs was described in 2004 by Michael Tiemann in ‘The Open Source Triple Play‘.  I regularly redraw this image to explain how and why Red Hat does business:

I was tickled that Aslett included JBoss as an example of the third stage, which he summarized with the first two:

While the first two stages were focused on collaborative development as a by-product of open source licensing the projects and vendors that characterized the third stage were focused on market disruption through widespread distribution and typically eschewed the potential advantages of collaborative development in favour of control over the future development of the project.

When Red Hat acquired JBoss, the clear methodology they had was to hire anyone from the community who started to do any real work with the open source codebase.  This kept all the copyright in the company, what I once heard JBoss founder Marc Fleury refer to as a “strong IP” position – strength in holding intellectual property.  But this was at the downfall of a strong community – it couldn’t stand well on its own if every active contributor was hired to be  part of the same corporation.  To an extent, this was incurring the cost of a closed development model where you have to pay for every developer hour, while not gaining the supposed benefits of a product that can’t be downloaded and freely distributed without you being paid.

As Simon Phipps ultimately points out, this is the way many of us have been doing open source business all along.  The fact that customers are finally figuring out that there is a triple-play in this for them, too, is many shades of awesome.

So, friends new and old, come on in and play.  The water is warm and the waves are just enough to make things regularly exciting.

8:45 a.m. – Welcome & introductions, Michael Tiemann

9:00 a.m. – Dr. David Upton, Chair of Operations Management, Oxford University

9:45 a.m. – Free and Open Technologies: A Policy Update from the European Union, Karsten Gerloff, President, Free Software Foundation Europe and Graham Taylor, Chief Executive of OpenForum Europe

10:30 a.m. – 15 MINUTE BREAK

10:45 a.m. – Matt Jadud, Assistant Professor of Computer Science at Allegheny College

11:30 a.m. – Wikimedia: Strategic Planning the Open Source Way, Eugene Eric Kim, Cofounder & Principal, Blue Oxen Associates

12:15 p.m. – 15 MINUTE BREAK

12:30 p.m. – Q&A: Creative Commons and the Music Industry, Daniel James, director, 64 Studio Ltd.; Curt Smith, solo musician, singer and songwriter as well as co-founder of Tears for Fears; and musician Brad Sucks

1:15 p.m. – The Stimulus and Standards, Dr. John Halamka, CIO of Beth Israel Deaconess Medical Center and Harvard Medical School and chair of the US Healthcare Information Technology Standards Panel

2:00 p.m. – 15 MINUTE BREAK

2:15 p.m. – Michael Tiemann, Vice President of Open Source Affairs at Red Hat and President of the Open Source Initiative

3:00 p.m. – Open Source License Compliance, Richard Fontana, Open Source Licensing and Patent Counsel, Red Hat, Inc.

3:45 p.m. – 15 MINUTE BREAK

4:00 p.m. – Open Source for America, Jeremy Allison, Linux Evangelist, Google, and Terri Molini, public/investor relations consultant with Initmarketing, the Open Source Marketing Agency

4:45 p.m. – The Open Source Way: Creating and nurturing communities of contributors, Karsten Wade, Sr. Community Architect, Red Hat, Inc.

There are already two lessons learned from this first Open Your World Forum — learning as you go is part of the open marketing experience.

First, the team put together the forum on very short notice and elected to use a known system for presenting, provided by a vendor (Thomson Reuters), rather than research open source solutions. I haven’t seen this system, but I’m fairly certain it is not an open source project.   This is the kind of thing that happens in the real world, where time, money, and opportunity are finite.  The key from here is to get it in the plans to use an open solution next time, and I understand that is the case.  Perhaps John Adams will write a post about the experience for the business channel.

Second, the presenter selection could use some diversity in voices, particularly different cultures and sexes.  As I commented extensively, the presenter crew is 100% men and 92% European in ancestory.  I think we can do a lot better than that, and I’ll do what I can to help find that diversity to add to the width and depth of the voices at future Open Your World Forums.

I’m not having much success, and I think that’s as much about my weakness in this area as a lack of interest or budget.  I should get out the stacks of business cards I’ve collected from previous conferences, but cold calling people for money isn’t really my cup of tea.  Even when they might be interested, for real.  Even when it’s no big thing if they say no.  I’m just not so hot at it.

If you have any inclination or ability here, I’d appreciate help.  Finding sponsors and getting other people involved in the organization of the Summer Coding program has been the hardest part so far.  If we are going to continue to do it beyond this summer, we are going to need more help in organization, finding and working with sponsors, and so forth.

If you can help, please join us on the SIG mailing list and let us know what you think.

Whittling from the set of slides I used for Ignite CLS West, I cajoled them in to six slides that still follow the principles of presentation I want them to follow. Big font, few slides, can be given in ten or forty minutes.  As part of my standard procedure, I included a set of notes for each slide.  The idea is to make the works more reusable, as well as help me keep on point when talking.

http://quaid.fedorapeople.org/presentations/Presenting-The_Open_Source_Way.odp

http://quaid.fedorapeople.org/presentations/Presenting-The_Open_Source_Way.pdf

We’ll also sort the student ideas, generate the list of approved proposals, work with the students throughout the summer, and make sure you hear back about how things went.  You can learn more about the model we are using in this blog post, Summer Of Code Swimchart: Now With More Generic.

We need to start talking, soon.  I know it’s pretty late in your budget cycles and academic planning year.  But you would be surprised what a pool from a number of us can do.  It’s worth talking about, at the very least.

What are the resources you can supply?

• Money to pay stipends to students for spending focused time on these FOSS projects.  This is a cross between a summer job and an internship.
• Someone to help coordinate and to contribute as part of the Fedora Summer Coding special interest group (SIG).
• Mentors, especially if they work actively in sub-project or area the sponsor is supporting.

What do you get out of it?

• Positively impact FOSS projects.
• Get your brand in front of smart students who want to work on FOSS.
• Work on a community program that demonstrates how open source business is done.
• See something you’d like coded be completed.
• Other positive brand associations.

Can’t miss.  Can’t hurt to talk to us about it.  If you want to contact me directly for whatever reason, please do.

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.

Sustainable open source engineering refers to the process of supporting a collection of free/libre and open source software (FLOSS) over a very long period of time while following the open source way.  This means:

• Patches to the software collection must be pushed upstream where it makes sense; your engineers need to be the ones to know and make the call.  They are the ones who have to track and maintain the delta with the original upstream for many years.
• Provide a open mechanism for vendor partners and customers to collaborate on sustainability.
• Do all this in an open and transparent fashion.

Anything important not covered by this list?

Where a typical value of FLOSS is to allow for a small(er) investment as a contributor to yield a large(r) return as a user or vendor, sustainable FLOSS engineering turns this on its head.  The older the code base, the higher the cost to contribute.  Unless you happen to be already running the software because you are a customer or a vendor supporting that version, in which case the “obtain, install, understand” steps are already completed.  This is where the mechanism for collaboration comes to play.

Red Hat is the premier example of this.  While we get enormous value multipliers in resourcing current upstream projects and the Fedora Project, we commit enormous resources to sustaining Red Hat Enterprise Linux (RHEL) for seven years.  We’re so good at this practice that we routinely work with hardware and software vendors to train their engineers with our sustainable engineering teams.  If you have a big chunk of iron to support customers running RHEL on for seven years, you want your engineering teams to know how to collaborate on sustainable open source.

That should give you a hint of the example of other companies that practice this type of sustainable engineering.  Any large hardware (IHV) or software (ISV) vendor with products that customers run for more than a few years.  IBM and Hitachi, for example.

At this point I’ll note that fauxpen source/”open core”/dual-licensed-as-closed models are not good examples.  These are companies that are practicing business models that take some portion of their software source, usually an important part, and withhold it from being FLOSS.  Without a pure open source product chain, from R&D to sustainable-state, they are going to incur the costs of closed source development without the benefits of being at the center of a mechanism to collaborate with customers and partners.

What do you think are good examples of businesses practicing sustainable FLOSS engineering?

These are the sort of things I find myself microblogging about on twitter and identi.ca, which may explain why my blog has been going dark the last few months as I’ve been more micro than macro.

This 15 October marked my eight year anniversary with Red Hat.  I celebrated by presenting to people in our Raleigh, NC office about the open source way.  It all comes full circle, eight+ years later people (enterprises, governments, SMBs, academia, all of that) are still coming to the acknowledged and trusted open source leaders to learn how to get this done.

1. It’s not evil.  Despite a propensity to paint Red Hat as having dark, secret motives by some members of the world, the evidence is clearly to the contrary.  Being a public company, we have to act in the best interest of shareholders.  That means keeping stuff confidential that could affect the stock price, etc.  That’s fairness and ethics.  But we also know and have clearly demonstrated as a company that we make more money for our stockholders by following the open source way.
2. We make money by doing the right thing.  Why other people have not figured this out, I don’t know.  All the open core/fauxpen core/dual-licensed business models haven’t been working as well as everyone who is their proponent claims they would do.  Our pure-play open source model is really the only sustainable one.  Why? It doesn’t incur the cost of closed source the way the other models do.
3. We’ve maintained our culture throughout the years.  Every month there are new hires at Red Hat who, bless they souls, come from Big Grown-Up Companies who Know How to Sell Software.  *sigh*  You can imagine, keeping the proper open source way culture flowing requires dealing with internal as well as external onslaughts, pressures, and personalities.  At this company, the technical people have a serious influence on adjusting the mindset of the very smart people we bring in who haven’t yet fully absorbed the open source way.
4. We make some of the best technology while participating and catalyzing in the best communities in the world.  I love the people I get to work with outside of the Red Hat walls, and I’m there able to gain some credence often because of the power of @redhat.com after my name.  Everytime I add to that brand, I know I give many more than myself that same power-of.  That same is true when I wield the power of @fedoraproject.org.
5. They’ve taken a misfit genius like me and turned me in to something useful to the world.  ‘Nuff said.