I was writing a post about why you must work in the open to get more volunteers and I ended up writing this post about why I don’t work in the open.
So I think there are some very valid reasons for not working in the open:
- Personal. Not all projects are open source projects, especially personal ones. Where I’m going for Valentine’s Day or how to get my son to do better in school are not “open” projects. They could be, but they’re not.
- Not mine to share. There’s a lot of things I think should be shared with the world but they aren’t my stories or plans to share. I’d be violating someone else’s sense of privacy in order to share. I think your 2015 project goals are good enough to share with the world – and more people would join if you did – but you may not feel the same way.
- It’s not an open source project. Lots of projects in this world are not run in an open source way. If you are not looking to build a community, and you are not an open source software project nor a nonprofit nor a public entity, I think this is a totally valid way of working.
And then I think there are some reasonable reasons (maybe right, maybe not) for not working in the open:
- Partners. At Mozilla, we often cite partners as a reason why we can’t share plans. I think partners just make it much harder. You either have to figure out how to do it in a way that doesn’t expose their identity or you have to convince them. It’s a valid reason but one that could often be different if you worked on it.
- Buy in. It takes time to figure out how to accurately describe an idea, what you mean and why you want to do it. It helps to get feedback from a few people to help make your initial communication clearer. Simon Phipps opines that if there’s a strong majority in a project, discussing an idea first with a few is a way to get something enough backing to push it forward.
- Getting clear. Sometimes you have to float your idea by a few people to get clear about what you really need to do.
- Not enough time. Some times we don’t do things in the open when we are out of time. For me, this is especially true when it’s not my project but I really think it could benefit from being open. Like a fundraising project at school. If they created a web page and a mini social media campaign, I’m sure they could be tons more successful. But I don’t always have time to help them figure out how to do this. I think this crosses into “The Ugly” when it is your own project. If it should be in the open, and you want a community to help you out, you have to take the time to grow that project. You’ll recoup your time later.
And then I think there are some not so great reasons for not working in the open:
- Not enough time. I hear this one a lot. We have to get this out next week or next month. There’s not enough time to articulate it clearly enough to open it, to answer everyone’s questions, to mentor, to accept contributions. This might be ok once in a while but I hear it more and more.
- Not distracting people. I feel this one a lot at Mozilla. Mozilla is a huge community now and we all want to keep up with everything. So every time you float a new idea and a million people weigh in, you feel like you are distracting them from everything else. But I think it’s ultimately their decision whether or not to be distracted.
- Not announcing other people’s plans. I put this in the ugly category because I often feel like my hands are tied in sharing until someone else shares their plans. Especially in technical documentation and evangelism, you are supposed to talk about other people’s work but not until they are ready. And you want to plan projects, outreach or events around their news.
- Not committing to something. Especially for your organization. It takes great skill to “float an idea” in the open. To not commit to it while still considering it. To be able to say, we are considering this and then to be clear if you decide not to go forward. The fear is that it makes you look indecisive. It makes people waste their time. It causes inappropriate press cycles. But if you can’t float ideas in the open, if you only talk about things that are already committed to and planned, you miss a huge opportunity to include people in the creative cycles and to make them feel like it really is their project.
- Not having company commitment. Especially when you are getting paid to work on an open source software project, it’s hard to float random ideas before you have your company’s or your boss’ commitment.
- Not making inappropriate news waves. There’s a lot of stuff I’d really love to talk about in the open and I don’t because I don’t want to read about them in the press. Right after I started at Mozilla we had a couple of these incidents. People’s personal blog posts turning into major news cycles. It wasn’t fun for them. I don’t want it to happen to me. (Unless it’s something I want in the news!)
When you choose not to work in the open, what are your reasons? Are they Good, Bad or Ugly? What are your suggestions for how those of us who want to work more in the open can all do better?
During my FOSDEM talk, I spoke about how your phone company, hardware and operating system control what apps you have access to. Some phones bring internet access to those with no access but without the choice and freedom we expect on the web.
For example, in Zambia people are getting free internet from Facebook but they only have access to certain websites. As Eric Hal Schwartz from DCInno says, it’s a bit scary:
anyone in Zambia can get free access via the Internet.org website or its Android app to a limited number of websites and apps. While this is of course great for those who otherwise would have no Internet access at all, the arbitrary limits put on what they are allowed to do online arguably cedes way too much gatekeeper power to the companies behind the offering.
Kudos to Facebook and their partners for bringing internet access to people that didn’t have it. Hopefully they will also give them freedom and choice as well.
There’s a Free and Open Source Software Track at Grace Hopper this year! Submit your proposal now and come join us.
Grace Hopper is the largest gathering of women technologists and it’s a super energizing conference. They are expecting 11,000 people this year – which I find kind of scary. But my experience at Grace Hopper has always been very welcoming – a place to see old friends and a great place to meet new people. I always see quite a few women from the industry that I know and I always meet a couple of more – usually a couple each time that I still remain in contact over the years. It’s how I met the HFOSS folks and where I met Corey Latislaw who is now a Kids on Computers volunteer. I also always see at least one speaker who makes a huge impact on me. One year a keynote speaker made me cry and laugh several times all in one talk. Another year, the President of Harvey Mudd College was on the imposter panel. She talked about how she felt like an imposter asking for a $25 million donation when the people all around her were much more successful and wealthy. GNOME owes part of its financial success that year to her. Because of her stories, I had no problem going and asking all of the advisory board member companies if they could double their contributions.
Heidi Ellis and I are co-chairing the Open Source track and we’re both excited to bring the new things happening in the open source world to a larger audience. We want to get more of the women at Grace Hopper involved in free and open source software. Or at least aware of the opportunity. Please consider submitting a proposal to the track. Formats include presentations, lightning talks, panels, workshops, and birds of a feather.
Men and women are welcome at Grace Hopper although I warn you (both men and women!), if you’ve never been, it feels very strange at first to be at a technical conference that is almost all women! There are also a lot of students at Grace Hopper and that too adds to the energy and the unique feel of Grace Hopper.
One of the best pieces of advice I got was “Find out if they are an email person or a phone person and communicate with them that way.” These days you have to add text messages, hangouts, whatsapp, irc, etc to the list, but the same principle holds true.
I’ll give you an example of how this can go wrong if you don’t “speak the right language.” Someone recently called the GNOME Foundation Board and identified themselves as press and asked to speak to me. Note that the board doesn’t have a phone. It’s just a virtual mailbox because organizations are supposed to have phone numbers.
If he had emailed the list, I’m confident he would have been forwarded on and gotten an answer (or been told no) within 24-48 hours. Instead he called.
I read about it in the board meeting minutes.
Here’s an overview of the proposed agenda/topics for this meeting:
* Adboard meeting at FOSDEM 2015
* Next steps for the Outreach Program
* Responding to a phone press inquiry asking to reach S. Peters
I replied back that if he was looking for me, he should be able to find my contact information easily on the web but that they were welcome to forward him to me or to the press list. Now note that they can’t forward it. It’s a voice mail in a virtual voice mail box.
So the next week I read in the minutes:
* Responding to a phone press inquiry asking to reach Stormy Peters
* Comment from Stormy: “There is a press mailing list to deal with press inquiries. And if they are looking for me, they should be able to find me but you are welcome to point them my way.”
* ACTION: maybe Rosanna can check with the caller to see what he wants and see if we need to get back to him by press contact, or if he really wanted to reach Stormy in particular?
Now, before you say how absurd, why didn’t they call him back, I want you to think back on all your communications over the past week. If you are like most people, I bet there’s at least one email, text message or voice mail you haven’t answered yet. And one of those unanswered messages is probably in a medium you don’t like to use much. People that know you well, know whether to send you a text message or an irc ping if they need a quick answer from you.
I think this is especially important when it comes to team communications.
If your team usually communicates over mailing lists and irc, and you set up a video meeting, does that fit their culture? If you set up an irc meeting, does that fit their culture? And if not, are you purposely trying to drive cultural change? Did you tell them that?
I tried holding all my extended team meetings as irc meetings instead of video meetings last year in order to involve more volunteers. It didn’t work. I’m guessing it’s either the meetings themselves that are either not in the culture or the meetings were not useful or our internal structure of teams didn’t match what volunteers thought of as projects.
Project communication goes beyond meetings and includes things like announcements, discussions and decisions. Should announcements be emails from a single person or newsletters or blog posts in your project’s culture? Should discussions happen on irc or mailing lists? Should they be logged? Should decisions be made on mailing lists, in meetings or in bug tracking tools?
How does your team communicate? How do you change those channels when you need to? Or can you?
I made a resolution to read a book a week in 2015. As long as you are making resolutions, you should make them fun, right?
In January I read a great nonfiction book about New Orleans’ neighborhoods and culture, a good historical fiction book that takes place during World War II and a bunch of easy reading military scifi.
The first book I finished this year was All the Light We Cannot See. My book group chose this book and it’s a good story. It takes place during World War II and is told from the view point of an orphan boy who ends up in the army on the Nazi side and a blind girl whose father is the master locksmith of the Louvre. The girls’ father is one of 4 people given a replica of a jewel or the real thing and told to hide it. The boy is part of a crew designed to find and take down radio transmissions. The story is well told; the characters are well developed and the book is true to history. I recommend it.
I also said I’d read one nonfiction book and blog about it. For January, that book was Nine Lives: Death and Life in New Orleans. This is the true story of nine people’s lives in New Orleans from Hurricane Betsy to Hurricane Katrina. I really enjoyed the book – partially because I have met one of the main characters, partially because I’ve been to most of those neighborhoods and mostly because it’s a good book. I blogged about it on Can You Cross the Street.
Then I got my military science fiction fix:
- Against the Odds (The Serrano Legacy Book 7) by Elizabeth Moon. If you like Elizabeth Moon and you’ve read the rest of this series, then you should read this one. She does a good job of developing a universe of cultures and characters encountered with the issue of immortality. If you haven’t read any Elizabeth Moon books, you are probably better off starting with one of the first books in a series set in the same world (this one or this one) or my favorite Elizabeth Moon short story, Chameleons. You can find it in The New Space Opera 2.
- Rich Man’s War. This is the second book in a series and the opening premise is an interesting one. What if we outsourced all education to companies and young people started out with a debt that was inversely proportionate to how much they had learned? The book is good and the story and characters are consistent but the characters don’t have a lot of depth. I read it and will most likely read the next books in the series some day.
- Lines of Departure. This is the second in the series and after the first one I didn’t think I’d read any more of them. They were a bit too much about military life and way too many battle scenes, even for a military sci fi series. And not enough character development. However, I was intrigued enough – and missing the characters enough – that I read the second one. It was still good but still just too much fighting and military life. And I really hope this is not what happens to humanity. Infighting, squabbling and fighting aliens. Not much of a future.
I perused the following books:
Tried to read …
I also tried to listen to The End of Power, the first book that Mark Zuckerberg choose as part of his 2015 resolution. It was really hard to follow when listening to it in 10-15 minute chunks. I gave up on listening to it and I’m reading it now.
What did you read in January?
I had breakfast with Cate Huston and I told her that I was working on a blog post called “Should you build an app or a website?” She opined that perhaps mobile apps, both native and web, are better because they have constraints. When you have a small screen, you have to have a good UI. You can’t offer users every possibility, you have to make some decisions and choices for them on what they might want to do.
Cate talked about an art teacher who constrains kids to black and white charcoal, then to a drawing started to someone else and then to a drawing torn in half. They are more creative and come up with more inspired work because they have artificial constraints.
When I think about really single purpose, simple websites, I think about Google’s home page.
There’s a few apps like that too.
What do you think? What would your website look like if you knew that everyone had to look at it through a 640×320 screen and could only interact with it using touch sensitive gloves because it was raining ice chunks outside?
Can read or can’t eat books?
What I love about open source is that it’s a “can” world by default. You can do anything you think needs doing and nobody will tell you that you can’t. (They may not take your patch but they won’t tell you that you can’t create it!)
It’s often easier to define things by what they are not or what we can’t do. And the danger of that is you create a culture of “can’t”. Any one who has raised kids or animals knows this. “No, don’t jump.” You can’t jump on people. “No, off the sofa.” You can’t be on the furniture. “No, don’t lick!” You can’t slobber on me. And hopefully when you realize it, you can fix it. “You can have this stuffed animal (instead of my favorite shoe). Good dog!”
Often when we aren’t sure how to do something, we fill the world with can’ts. “I don’t know how we should do this, but I know you can’t do that on a proprietary mailing list.” “I don’t know how I should lose weight, but I know you can’t have dessert.” I don’t know. Can’t. Don’t know. Can’t. Unsure. Can’t.
Watch the world around you. Is your world full of can’ts or full of “can do”s? Can you change it for the better?
Many app developers are secretly hoping to win the lottery. You know all those horrible free apps full of ads? I bet most of them were hoping to be the next Flappy Bird app. (The Flappy Bird author was making $50K/day from ads for a while.)
The problem is that when you are that focused on making millions, you are not focused on making a good app that people actually want. When you add ads before you add value, you’ll end up with no users no matter how strategically placed your ads are.
So, the secret to making millions with your app?
- Find a need or problem that people have that you can solve.
- Solve the problem.
- Make your users awesome. Luke first sent me a pointer to Kathy Sierra’s idea of making your users awesome. Instagram let people create awesome pictures. Then their friends asked them how they did it …
- Then monetize. (You can think about this earlier but don’t focus on it until you are doing well.)
If you are a good app developer or web developer, you’ll probably find it easier to do well financially helping small businesses around you create the apps and web pages they need than you will trying to randomly guess what game people might like. (If you have a good idea for a game, that you are sure you and your friends and then perhaps others would like to play, go for it!)
Traditionally, open source software has relied primarily on asynchronous communication. While there are probably quite a few synchronous conversations on irc, most project discussions and decisions will happen on asynchronous channels like mailing lists, bug tracking tools and blogs.
I think there’s another reason for this. Synchronous communication is difficult for an open source project. For any project where people are distributed. Synchronous conversations are:
- Inconvenient. It’s hard to schedule synchronous meetings across time zones. Just try to pick a good time for Australia, Europe and California.
- Logistically difficult. It’s hard to schedule a meeting for people that are working on a project at odd hours that might vary every day depending on when they can fit in their hobby or volunteer job.
- Slower. If you have more than 2-3 people you need to get together every time you make a decision, things will move slower. I currently have a project right now that we are kicking off and the team wants to do everything in meetings. We had a meeting last week and one this week. Asynchronously we could have had several rounds of discussion by now.
- Expensive for many people. When I first started at GNOME, it was hard to get some of our board members on a phone call. They couldn’t call international numbers, or couldn’t afford an international call and they didn’t have enough bandwidth for an internet voice call. We ended up using a conference call line from one of our sponsor companies. Now it’s video.
- Logistically difficult. Mozilla does most of our meetings as video meetings. Video is still really hard for many people. Even with my pretty expensive, supposedly high end internet in a developed country, I often have bandwidth problems when participating in video calls. Now imagine I’m a volunteer from Nigeria. My electricity might not work all the time, much less my high speed internet.
- Language. Open source software projects work primarily in English and most of the world does not speak English as their first language. Asynchronous communication gives them a chance to compose their messages, look up words and communicate more effectively.
- Confusing. Discussions and decisions are often made by a subset of the project and unless the team members are very diligent the decisions and rationale are often not communicated out broadly or effectively. You lose the history behind decisions that way too.
There are some major benefits to synchronous conversation:
- Relationships. You build relationships faster. It’s much easier to get to know the person.
- Understanding. Questions and answers happen much faster, especially if the question is hard to formulate or understand. You can quickly go back and forth and get clarity on both sides. They are also really good for difficult topics that might be easily misinterpreted or misunderstood over email where you don’t have tone and body language to help convey the message.
- Quicker. If you only have 2-3 people, it’s faster to talk to them then to type it all out. Once you have more than 2-3, you lose that advantage.
I think as new technologies, both synchronous and asynchronous become main stream, open source software projects will have to figure out how to incorporate them. For example, at Mozilla, we’ve been working on how video can be a part of our projects. Unfortunately, they usually just add more synchronous conversations that are hard to share widely but we work on taking notes, sending notes to mailing lists and recording meetings to try to get the relationship and communication benefits of video meetings while maintaining good open source software project practices. I personally would like to see us use more asynchronous tools as I think video and synchronous tools benefit full time employees at the expense of volunteer involvement.
How does your open source software project use asynchronous and synchronous communication tools? How’s the balance working for you?
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.