Let’s not kid ourselves: the free and open source community is not all laurel (yanni?) leaves and Kumbaya. There are arguments all the time.
Vi vs. emacs. Restrictive vs. permissive. Open vs. proprietary. Heck, on most days, I have had discussions about one or more of these topics before I’ve finished my morning coffee.
When you add business interests in the mix, the arguments add a whole new layer of motivation because now we’re talking about money and sales.
It’s a pretty violent metaphor, this notion of what happens to your open source software project if one or more of its members might get hit by a bus. Or a truck. Or whatever motor vehicle of doom happens to be barreling down the road of fate. At first thought, one might simply want to urge people to look both ways when crossing the street.
But the bus factor is a real concern for many open source projects, because too often a lot of the work finds itself in the hands of just a few people, who in turn become very critical to the project’s success.
Whether it’s a favorite sports team, a school, or just a group of friends, there is something about human nature that seems to drive many of us to display our affiliation.
We do this, typically, by displaying plumage that is synchronized. If I am a fan or a particular team, and I see someone wearing a matching jersey, then I can identify with that person in some way, even if it’s the first time I have met them.
This week is our annual Red Hat Summit, a time when many of our nearly 12,000 employees put their work down and come together to work with customers and determine how best to work together moving forward.
This may seem pretty antithetical to the goals of a team like ours, where free and open source projects are the focus, not commericial support and training. But actually customers get just as much benefit talking with the community projects as they do the sales and engineering teams.
Throughout IT is the notion that when you are promoted to being a manager, you should somehow be able to do the things you have been doing. If you are a coder, you should be able to code and manage. If you are a writer, writer, sysadmin… the same theory holds.
The manage-from-within notion is something a lot of community managers have to contend with every day. It is an especially fuzzy boundary because, typically, community managers aren’t really managing people at all, but rather guiding resources and providing support. So why shouldn’t they get to also work to their strengths?
Because nothing could be further from the truth.
Given the rapid growth of open source, it seems reasonable to expect that undergraduate students in computer science or software engineering programs would graduate with an understanding of open source and the ability to make project contributions. However, most students are not being taught core tools and concepts such as licenses, version control, and issue trackers as part of their degree program.
This special episode of Community Central shares the results of recent research anthropologist Matt Bernius conducted for Mozilla on the state of undergraduate education around open source software. Matt will also discuss the gap between undergraduate computing education and community expectations, and explore both the reasons for the gap and approaches to bridging it.
This is a question community managers hear a lot. Everyone wants to grow their project and we all want to hear what worked (or didn’t) for others. One of the benefits I have by working for Red Hat is being part of a large community of community managers and community oriented people. Stormy Peters put this question to that group last year:
We are all working to grow the communities around our projects, in particular diverse communities (diversity of company, gender, geography, etc.). What’s the single best tip you’ve gotten for attracting new contributors? Who gave it to you? Or, alternatively, what’s the single thing that’s made the most impact on attracting new contributors to your project?
She got a lot of great answers, some of which I’ve collected here.
One of my biggest pet peeves is coming into a meeting somewhere or talking casually with co-workers and realizing that a decision was made on a project that I was involved with and I didn’t know about it.
I will say right up front that 99% of this peeve are my own hang-ups: a combination of a lot of FOMO and more than a little frustration at myself for not keeping up with my own e-mail deluge. Most of the time, it turns out, the decision was made out in the open in an e-mail thread or chat session and I just didn’t see it.
Plus, I just need to loosen up a little.
“Should we open source this project?” An easy question to ask, and a hard one to answer. The goal of this article is not to answer the question, but maybe to give some tools that you can use to find the answer when the question arises.
The first question to ask is why the project leader is interested in open source in the first place. Typical answers might include “because we want a community” or “because we want to be the Firefox of our field.” But when you dig deeper, there may not be a clear understanding of how an open source project can benefit your company’s goals.
The creation of an open source strategy is about finding that benefit. In short, you want to understand why open sourcing this project will benefit the company.
This morning, I was asked to give a few tips about staffing a booth at a technology conference—or, indeed, any conference. This got me thinking—there’s things that I do at a conference that come out of years and years of experience doing it wrong, and then tweaking it the next time.
I’ve been to a lot of conferences. And I’ve spent hundreds of hours staffing the booth.
To skip to the punchline, everything flows out of deciding what the conference is for. If you know what you hope to get out of the event, everything else flows out of that.