A recent conversation on a Mozilla mailing list about whether IRC channels should be archived or not shows what a commitment it is to remain open. It’s hard work and not always comfortable to work completely in the open.
Most of us in open source are used to “working in the open”. Everything we send to a mailing list is not only public, but archived and searchable via Google or Yahoo! forever. Five years later, you can go back and see how I did my job as Executive Director of GNOME. Not only did I blog about it, but many of the conversations I had were on open mailing lists and irc channels.
There are many benefits to being open.
Being open means that anybody can participate, so you get much more help and diversity.
Being open means that you are transparent and accountable.
Being open means you have history. You can also go back and see exactly why a decision was made, what the pros and cons were and see if any of the circumstances have changed.
But it’s not easy.
Being open means that when you have a disagreement, the world can follow along. We warn teenagers about not putting too much on social media, but can you imagine every disagreement you’ve ever had at work being visible to all your future employers. (And spouses!)
But those of us working in open source have made a commitment to be open and we try hard.
Many of us get used to working in the open, and we think it feels comfortable and we think we’re good at it. And then something will remind us that it is a lot of work and it’s not always comfortable. Like a conversation about whether irc conversations should be archived or not. IRC conversations are public but not always archived. So people treat them as a place where anyone can drop in but the conversation is bounded in time and limited to the people you can see in the room. The fact that these informal conversations might be archived and read by anyone and everyone later means that you now have to think a lot more about what you are saying. It’s less of a chat and more of a weighed conversation.
The fact that people steeped in open source are having a heated debate about whether Mozilla IRC channels should be archived or not shows that it’s not easy being open. It takes a lot of work and a lot of commitment.
The Mozilla Summit is coming! On June 15th,  50 Mozillians got together for a planning session and I discovered just how much Mozillians focus on getting great things done!
We met to help shape the Mozilla Summit (a 2,000 person conference happening later this year) in a way that would move Mozilla forward. We spent the first day talking about top issues and the second day planning out the topics and sessions.
Photo sent to me by Shez (But Shez is in the picture so not sure who the photographer is!)
Of all the trips I’ve taken this year, I think the Mozilla Summit Planning Assembly was the one I looked forward to most – a chance to help shape the future of Mozilla and have great conversations with people who are passionate about the same things I am! I also admit I was really worried that we were too big of a group to get anything done. Turns out I was not alone. We all showed up ready to set the content and agenda for the Mozilla Summit.
A day of tough discussions and building trust
We had some excellent conversations Friday night and Saturday. We did a number of different exercises designed to start conversations and pull out key themes. For example, we started out  Saturday with an “unpanel”. Four people sit in the middle of the group. They have a conversation. There’s an empty chair as well and whenever someone in the audience wants to join the conversation, they slide into the empty seat and one of the four sitting there self selects to go back to the bigger circle leaving an empty chair as an invitation for the next person. While at first it didn’t seem very different than a big group conversation where you passed around the mic, it turned out to be a great way to keep the audience engaged in the conversation. Every one was listening hard. The topics we covered were varied but a lot of it centered around non paid staff vs paid staff relationships – culture and responsibilities. We also talked about things like whether there’d be technical roadmap decisions made at the Summit, how people like to communicate, etc. One of the key takeaways for many of us was that we were all worried about similar issues!
Over the course of the day, two themes arose:
Old timers and new hires are having a hard time trusting each other at Mozilla. I’m sure I didn’t get all the nuances but it felt to me like old timers think new hires might not have the “Mozilla DNA” and might not have an appreciation for our mission and open source methods. And new hires think old timers are stuck and so concerned with consensus they aren’t always getting things done.  Over the weekend, I think we made great progress in killing that stereotype and building good relationships that bridge the gap. (Lukas Blakk wrote about this experience as well.) I have to admit that personally I’m not sure where I fell on this stereotype other than feeling rather annoyed at both groups and some how personally responsible for both stereotypes. As a hiring manager, I’ve hired many of those new people. As a long time open source community member, I feel like it’s my job to make sure the “open source” way is considered and well represented.  I also think that part of the problem is how members of each group introduce themselves and represent themselves to the world – more on that later.
Mozillians like to get stuff done! By the end of the day, we were all extremely uncomfortable with all of the discussions, panels and world cafe exercises with no clear idea of how it was going to produce an agenda for the Summit. Luckily our leaders and the Unconference organizers heard all of our concerns and when we turned up the second day, we got to create a rough outline of an agenda and topics for the Summit!
Getting down to work
On the second day we did a “World Cafe” exercise. We had about 7 rooms and 3 time slots and everyone wrote in the topic they wanted to cover in one of the slots. We then did some consolidation and managed to squeeze everything into the ~20 slots.
The idea was to cover themes or topics we thought should be covered at the Mozilla Summit. Each session was to identify Session Title, Goals and Outcomes, People for Followup and What has to happen between now and the Summit. They were all captured in etherpads.
All the sessions I went to had great conversation. It was rather tricky to focus on how that topic would be covered at the Summit instead of just discussing the topic. We tried to focus on how the conversation would best happen at the Summit: what type of presentation it would be, how much should be a proposal vs a discussion, if it was one presentation or a theme, etc. Some times the topic you signed up for was not the topic your group ended up proposing. I attended discussions on communication, diversity (Dino and Lukas have a great diagram for a starting conversation!) and helping companies that aren’t used to “open” work with effectively with us.
Then Mark, Debbie, Mitchell, Kate and Mardi grouped all of the topics into themes – interestingly “People” had the most topics. Other themes included Strategy, Product, Process and Purpose.
So now we have themes for the Summit. And a lot of proposed topics.
I found it really valuable to spend this time as a group planning for a big event. When you are going to bring 2,000 people together (in groups of 600) I think it’s essential to spend some time uncovering what the real issues that we need to discuss are.
My take aways:
In addition to the bigger goal of planning the Summit, I took away a few more key things:
It’s important to work together, preferably in person. We built a lot of trust over the weekend – trust that would have taken much more time to build during our regular day-to-day lives and over the internet. I hope we can take that experience and bring it to the Mozilla Summit.
Mentors. After a conversation with Gandalf, I came away thinking part of the solution might be holding mentors more accountable and some how measuring their success over time. We also discussed short term mentorship projects too.
How you introduce your self matters. With a few exceptions, most of the volunteer Mozillians introduced themselves as being “a community member” or a “Rep”. Most of paid staff introduced themselves by their functional role or team, “Firefox for Android”. This is natural as while we all feel like part of the greater Mozilla community, paid staff has in general been hired to do a particular role. But I feel like it’s a big part of the disconnect.
Lots of communication formats are needed. Lawrence Mandel pointed out that not everyone does well speaking in front of large groups at conferences, so whatever format the Summit takes, it needs to enable lots of communication vehicles, meetings, parties, irc, etherpads, newsgroups, … a way for everyone to find enough of their comfort zone so that they can be comfortable enough to participate fully.
The Mozilla Summit Planning Assembly was one of the trips I was most looking forward to attending this year and it lived up to my expectations! I’m very excited for the Summit now! (And for all the planning that still has to happen before then!)
The Starfish and the Spider compares two types of organizational structures. Spider organizations have a central command structure, like a CEO. If you detach one of the spider’s legs from the head, the leg can no longer function. It is not autonomous. Starfish organizations have very distributed command structures. Cut off a leg and it will continue to function and will even grow other legs and turn into its own starfish. Each type of organization has its benefits and drawbacks and each are useful at different times. One key to success is understanding what type of organization you are in, its strengths and weaknesses and when you might want to act more like the other type. Hybrids are also possible. For example, GE Â under Jack Welsh transitioned from a spider to a spider/starfish. Traditional companies tend to be more like spider organizations and open source software projects tend to be more like starfish.
Some of the points in The Starfish and the Spider made me wonder whether money can change an open source project into a more traditionally organized and closed project. And if it has that potential, what we can do preserve the best of open source while introducing money.
As I discussed in “Would you do it again for free?“, I’m very curious about how open source organizations work and in particular how factors like motivations, companies and pay change them. I’ve theorized that pay can change an open source developer’s motivations. It’s not usually bad for the project (especially if the payment is in the form of salaries) unless the money goes away. If the money goes away, if for example the developer gets laid off, then I think the developer will quit working on the project but will switch projects, not quit working on open source software projects all together. (Assuming they were working on open source software before they got paid to do it.)
But what happens when money gets introduced suddenly into an open source project? I think it depends on how the money is used and how much its distribution changes how the project is run. In most cases, access to money has greatly helped open source software projects in a number of ways.
Developers. There are a lot more developers working full time on projects like Linux and Firefox than there would be if no one was paid to work on them. And those developers contribute more than just work. They bring ideals and values to the project.
Team building & communication. More resources means being able to bring more people together – and not to just hold the conference but to actually pay for people’s travel expenses if needed. GNOME, Apache and Mozilla all help pay for contributors travel to key events when needed.
Infrastructure. Money can also provide for project infrastructure, hardware and hosting costs.
Skills. Money can also be used to bring in resources that open source software projects have traditionally had a hard time recruiting or finding in their volunteer staff such as marketing and business development.
Given all the benefits that additional resources can bring a project, I think having access to money is definitely a good thing for open source software projects. (And I’ve spent a lot of time personally helping projects effectively raise and use money through efforts like fundraising for GNOME and serving on the Board of Directors for the Software Freedom Conservancy.)
I do think there are a few things to keep in mind though.
Money often concentrates power. This is not so much an issue when the money is used for salaries, but more an issue of when resources for things are not accessible to all project members. Or the process for getting access is not communicated well. The Starfish and the Spider shares the example of how the Apache Indians were ultimately defeated. The Apaches were definitely a starfish organization. Tribes followed their leaders because they believed in them. If a leader was killed, people would continue to fight and a new leader would emerge. How were they defeated? By cows. The Americans gave the Apache leaders cows. Once they had cows, they controlled a valuable resource and became an authoritative leader and the power structure became hierarchical instead of flat. Once the organization was hierarchical, it was easier to control. So it’s important to make sure that control of resources reflects or supports the project structure.
It’s hard to spend money. Many open source software projects, especially those with relatively small amounts of money, struggle with how to spend the money effectively and fairly. If you have $500 and a project with 10 people, how should you use it? You could reward everyone with a dinner at a conference, but most of them would probably rather you spent the money on the project. You could pay to fly someone to the next hackfest that would not ordinarily be able to afford to attend. With a little bit of money (I heard under $10,000), it is often hard to spend the money. It’s more work to figure out how to spend it and use it, than it’s typically worth. Especially if the project doesn’t have an organizational entity associated with it.
Most financial transactions require an authorized person. In most countries, signing a deal with another organization requires someone to sign the deal. So to enter into any kind of business relationship whether as a client or a partner or a provider, an organization must have someone with authority to sign for the organization. And for tax and liability reasons, you need an organization to collect money and sign agreements. It’s possible to give that authority to someone in a way that’s consistent with the values of a starfish organization, but it requires some thought.
Money can do a lot of good for open source software projects but some thought needs to be given to using it in a way that will do long term good.
Many of us working on free and open source software have strong values and we want to make the world a better place. I’m comfortable predicting that the rate of vegetarians, recyclers, hybrid vehicle owners and just general environmentally conscious people is higher than average in free and open source software projects.
But how much can you restrict your partnerships to those that perfectly align with your values? Is a company evil if it doesn’t match your values in all areas? I personally buy products and have business relationships with companies that I may not be 100% aligned with. (Although some may be too far from alignment.) Sometimes it’s because I haven’t done any research – I buy gas where it’s most convenient not from the most environmentally conscious gas provider. Sometimes it’s because there’s not much of an alternative – if I want high speed network at home, Comcast is my option. Sometimes it’s because I think that while they are not perfect, they are providing a service that makes my world better.
If you partner with someone who doesn’t share all of your values, assuming the partnership goes well, you have a chance to influence them. My friends are much more likely to listen to my opinions than someone I’ve never had a coffee or a beer with.
Now, I realize that open source software projects are often less in the position of partnering and more in the position of accepting donations. But again, I think your chances are greater for being a positive influence if you are working with them than if you are not. You should examine the organization’s motives and make sure if you are part of a political play, that you are comfortable with that move. I still remember the wealthy individual trying to build a big chain store in the town I lived in who donated a house to a family in need. While it was a great donation, and I would thank him for it in person if I saw him, I also know it landed him on the front page of the paper in a positive light at a very controversial time. Should the family have turned down his donation? Probably not. Should those that were anti-big-chain-store have done something differently. Probably.
But the fear of being associated with a company that’s not perfect or of being used as part of political play should not hold us back from investigating options and starting partnerships.
I think open source software projects often hold themselves back. They don’t investigate partnerships that could be beneficial because the other organization is not perfect. Proprietary software is not evil – a lot of really great innovation has been led by proprietary software companies. And doing business with an organization that has proprietary software will not make an open source organization any less good. There will be no perfect organization just like there is no perfect person. You have to recognize the opportunity for good in people and organizations and work with them where it can make sense for both of you.
Make the world a better place through partnerships because if you insist on doing it all yourself, it’s going to be a long road. Personally, I want to visit the stars someday, so I hope those that share a vision of star travel work together even if they don’t always agree on how to do it. I want to live in a world where everyone has access to computing power and the internet and control over their experience and their data. I think in order to do that, we’re all going to have to work together. And we’re going to have to work with those that might agree on pieces of our plan but not the end vision, and that will be ok. The super helpful Comcast guy might not share my vision of the world, but he helped me make it possible for me to continue working on it.
At a party, if you notice someone has food stuck in their teeth, you probably wouldn’t go “HEY! You have food stuck in your teeth and it looks GROSS! I hate it. I think you should go brush your teeth right now!”
But we do that all the time in open source.
Someone writes a new blog post or a new piece of code or forgets to post something … and we criticize them in public. Because it’s open source, right? Instead of emailing them we think their blog post is wrong, we leave a blunt, often rude comment. Instead of IMing them and asking if they’ve considered the privacy implications of their change, we write a public blog post that details how wrong their strategy is. Instead of congratulating them on their new product website and emailing them a few suggestions that would make usability better, we write a long critique in a blog post of our own.
When we do this, this public criticism, we change their ability to respond to it. Now they must respond in public, often defensively. If the feedback was private first, it would be easier for them to change quickly and nimbly. (Or maybe they don’t need to change at all. Maybe we missed something.)
There is a time and a place for public critique. But it’s often not the first place the critique should happen if we want to effectively influence projects.
Most effective people on open source projects communicate privately first.
They communicate via private emails, IMs and even public IRC channels, which are less public than web pages and public mailing lists because they aren’t archived.
So the next time you read something and have burning feedback, consider your audience and how you might most effectively drive the change you are looking for.
One of the things I love most about the open source communities I’m a part of is that when I ask a question, I just don’t get the answer, I get taught how to find the answer.
A few weeks after I started as executive director of the GNOME Foundation, I asked Dave Neary for someone’s contact information. Actually, it might have been the third or fourth time I asked him for someone’s contact information. He sent me back an email with the contact info I wanted. And a detailed explanation of how he found it. So the next time, I was able to find info like that myself.
I love that when you ask someone in open source a question, they not only answer it, but explain how they found the answer. (I realize some people find that annoying. I really appreciate “learning how to fish.”)
It’s the same empowering attitude that drives people to blog about a problem and how they solved it or found the answer. They are teaching others how to fish.
Think of the last time you walked up to a complete stranger, stuck out your hand and said, “Hi, my name is …” Depending on how often you do that, it was probably a scary moment. Before you walked up to the person, you had to steel your nerves, decide what you were going to say, and then approach them.
Joining an open source software project is a bit like that. You have to send a mail to a huge list of random people. Or file a bugzilla bug that goes to a ton of random people.
And then imagine the immediate response is “WONTFIX” with no comments. That’s like if the person you got up the nerve to introduce yourself to said, “Not interested.”
I once spent weeks convincing a friend she should help out on an open source software project. She did. And she sent in her work to the mailing list and the first response was full of harsh critique. None of the follow up messages made up for that first message. I never did convince her to push her work forward. Nor to participate in open source again. (She does know exactly what she’d say to that first critic if she ever met him in person!)
What can we do to make sure people trying to shake our hands get a better reception?
When I first started using email, I had a part time job in the computer science department at Rice University. A new grad student joined the department and a few days after he started, I noticed it was his birthday. Knowing he was unlikely to know many people in town, I sent him an email that said, “HAPPY BIRTHDAY” all spelled out in big letters made out of asterisks. He wrote me back “Thanks a lot”. Now in my world, “Thanks a lot” was always said “Thanks a *lot*” with a slightly sarcastic twist to it. I emailed him right back to ask him if he really liked it or if he was being sarcastic. He said no, of course, he really liked it.
So if one happy birthday email can be that confusing, imagine what can go wrong with a complicated email about project directions and motivations … Especially when it’s going out to a mailing list that has hundreds of people on it. That’s what most of us in the open source space deal with every day. Some of us do it better than others. Some days we do it better than others. But we all work at it every day. It’s the way we communicate with our friends, peers and co-workers.
Please meet the Mozilla Conductors
A few months ago, several of us at Mozilla had a conversation about how we could best help people learn how to communicate well online. We have new people joining the project all the time and they have to learn how to communicate on mailing lists, IRC and bugzilla. Those of us helping them realize daily what a challenge it can be. As much as we don’t think about it, cc’ing the right people, quoting previous mail messages and keeping the conversation from getting argumentative are not easy things.
We were looking for a way to help everyone communicate better, exploring all sorts of crazy options like classes and consultants, and realized we had the best resources right inside our project. We have people that are really good at fostering online conversations. They’ve been doing it for years; quietly (and not so quietly) leading and directing the conversations and projects they are part of.
So we sent out a bunch of emails, came to a consensus and created the Mozilla Conductors!
Mozilla Conductors help Mozillians with difficult online conversations. We offer advice, suggestions, a listening ear, moral support and, in the case where the discussion is public, occasionally direct intervention. But the goal is to help everyone communicate effectively, not to be enforcers. If you end up in a difficult online situation, you can reach out to Conductors via the mailing list or to any individual in the group to ask for help. Maybe you just need a sounding board or  help figuring out how to phrase a particular idea or how to make someone particularly difficult go away. The Conductors will help brainstorm, ask questions,  provide ideas and help. And where we are on mailing lists, we commit to helping  keep the conversations constructive.
We are not an officially appointed group. We are a peer nominated group. We are a group of people from across the Mozilla project. We are a Mozilla Module.
Please help us make online conversations productive and Mozilla a success!
High context cultures value personal relationships over process. You have to know someone before you can trust them and work with them. They also tend to be less explicit and rely more on tone of voice, gestures and even status to communicate. Typically Asian countries are more high context than Western countries. Think Korea and Japan.
Low context cultures are process driven. They rely on facts and processes. Their communication style is much more direct and action-orientated. They are orientated towards the individual rather than the group. Western cultures like the US and Germany are considered low context.
So if you start a project and send email to a bunch of folks and ask them to just jump in and contribute, which group do you think will get going more quickly? The low context culture folks. As long as you define the process and procedures, they are willing to work alone and with people they don’t know very well. That’s how open source works. So our projects are optimized for low context cultures.
What happens to the high context folks when invited to participate on a mailing list? They have a hard time sending emails and contributions to people they’ve never met and have no relationship with. (Imagine walking up to a random person on the street and critiquing their dress style. It’s that kind of awkward.) Would they make good contributors? Absolutely! Do we need to find other ways other than “join the mailing list” to get them involved? Absolutely! For an example of what’s worked well, see the great work that Emily Chen, Pockey Lam and Fred Muller and others have done with GNOME Asia.
As I think about developer engagement at Mozilla, I realize we need to have different plans for different cultures. It’s even more important to be present in person for high context cultures. To establish a personal relationship before you invite them to join your project. (Or ask them to use open technologies or spread the word.) We should be following up in different ways, setting up different programs for different countries. Luckily the Mozilla Reps program will help provide the infrastructure for this.
How do you think we should encourage high context cultures to get involved with open source? If you are from a high context culture, how did you get started?
For example, at the HFOSS Symposium today I talked to Graylin Kim who is working on the New York Senate Open Legislation Service where people can look up any bill that is being discussed in the New York Senate, get a permanent url to share and discuss on their own websites or grab all the data via REST. The idea is to encourage more citizens to get involved in legislature. Developers can get involved at http://nysenate.gov/developers or #nyss_openlegislation @ Freenode.net for OpenLegislation
I also discovered that Ease, a slide share program for GNOME, that is currently being developed by Nate Stedman. (An earlier version, Glide, was created by an RPI student, Rob Carr.)
