Teaching open source: Team operating principles that can be used on any project | Opensource.com

Teaching open source: Team operating principles that can be used on any project

Posted 25 Apr 2012 by 

Mary Ann Bitter (Red Hat)
Rating: 
(3 votes)
Team operating principles: the open source way
Image by : 

opensource.com

submit to reddit

Matt Jadud and Mel Chua have been friends of opensource.com from the beginning. Together with others they "are working on (the) Craft of Electronics, a curriculum for college-level electronics in a craft-first (and theory-sometime-later) format, through learning from, participating in, and contributing to the open hardware movement."

In efforts to explain what it means to operate in the "open source way," Matt wrote a set of guidelines for their team. We thought he was on to something so we’ve taken the liberty (with Matt’s blessing, of course) to build on what he started. We think they make fine tips for anyone contemplating a project the open source way.

1. BE BOLD

Do not be afraid to contribute. There is rarely any need to repeatedly ask for permission to suggest things, edit things, or throw things out. We typically work with systems that automatically preserve the complete history of what we are doing, so that we can all /be bold/ in making changes to our own and others' work. Anything that doesn't work well can always be reverted--so no change has even the remotest chance of being "damaging."

We are all full peers in this dialog. Don't hesitate to join in. It does not matter what you do or do not know; it does matter if you are silent, and that isn't what we're looking for.

2. TRUST OTHERS

Remember, our processes and practices include mechanisms for rolling back ideas that don’t work out. Making mistakes quickly and with no fear of reprisal is part of how we innovate so rapidly. So don’t stand in the way. Trust your teammates like you want to be trusted.

It is easy to say, “That will never work.” It’s very hard to continue trying when others shoot down your ideas before you have a chance to see if they bear fruit.

3. GIVE and GET GOOD FEEDBACK

Feedback is critical to any open source effort. Bad feedback—or taking feedback poorly—can derail a project completely. After all, nobody wants to help (or be helped by) someone who is ungracious.

When you give feedback, make sure it is useful. This does not mean that all your comments have to be positive—but make sure your criticism is constructive. Instead of simply panning an approach, offer alternatives. If you find yourself thinking ‘this will never work,’ try to think of a modification that will solve the problem, and suggest that instead. This is how the best ideas are born.

When you get feedback, accept it gracefully. Be open to other ideas. Part of working with a team is abandoning the idea of the lone genius. Part of working the open source way is accepting that projects are on-going and ever-improving. Even the most ground-breaking innovation can be bettered. And sometimes the best ideas—like mice and men—may go astray. Be ready to hear the replies of others, and willing to respond to and work alongside their contributions—whether you agree with them 100% or not.

4. THE OPEN SOURCE WAY

Opensource.com calls it the open source way, and there are five (maybe there are more) basic tenets:

We believe in an open exchange.

We believe in the power of participation.

We believe in rapid prototyping.

We believe in meritocracy.

We believe in community.

5. RELEASE EARLY, RELEASE OFTEN

We're going to be working in the open. That means we'll be discussing ideas before they're fully baked, and the intent is that we will generate a better final product by sharing our thinking and work at every stage of development (as opposed to waiting until it is "finished.") In fact, the explicit acknowledgment of this model is that nothing is ever done, it is just due. When something is due, we have to deliver it and evaluate it afterwards. After that, revision happens.

We release our work early (even if it is partial), and we release it often (or continuously, if it is open). While we may debate things with vigor, and triage ideas like they're going out of style, we know that whatever we come up with is just another step.

What are your thoughts?

And, in the open source way, we consider this a work in progress— as we’ve added to the original, we welcome your comments. What are other good directives for working together as an open team? Let us know what you think in the comments.

To see Matt Jadud's original email visit the Craft of Electronics mailing list or read Mel Chua's blog post.

submit to reddit

Mary Ann Bitter is a Creative Strategist for Red Hat's Marketing Communications & Design team. She lives at the intersection of business and design and believes the open source values have never been more relevant than they are today.  She is passionate about problem solving, the open source way, and working with people who give a damn.

What is open education?

Hacking computer science education at Khan Academy