There’s no denying the simple fact. Our team can’t and won’t have explosive growth.
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.)