Meet the Colorado Mozillians …
We spent the day co-working at the Boulder Hub.
Tom Tromey (Developer Tools), Justin Crawford (MDN), Teri Charles (Web QA)
Stormy Peters (MDN), Chuck Harmston (Marketplace)
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:
And then I think there are some reasonable reasons (maybe right, maybe not) for not working in the open:
And then I think there are some not so great reasons for not working in the open:
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 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?
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?
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:
There are some major benefits to synchronous conversation:
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.