The Good, the Bad and the Ugly of why I don’t always work in the open

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.

The Good

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.

The Bad

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.

The Ugly

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?

5 Replies to “The Good, the Bad and the Ugly of why I don’t always work in the open”

  1. Most recently within Mozilla I was asking a group of folks (non product related) to meet openly and the reason they justified meetings being closed was because while there were topics that should be open they also discussed individual conflicts and other issues that require privacy. I suggested they split off those topics to a separate call or even to private email so they could work in the open as much as possible.

    I also provided some examples of nearly identical teams/governance in open source projects that were already working in the open and getting around the private bits just fine.

  2. I think Mozilla’s meetings are a large part of what makes it hard for us to work completely in the open. If we banned all meetings for a month and made everything happen on email mailing lists and bugzilla, we might slow things down, but I bet we’d be more open.

  3. Not sure you should compare making valentines day plans (or anything like that really) to working in the open at mozilla. it has nothing to do with anything.

    Basically when you work at mozilla there is zero good reason not to work in the open. Valentine day is not work. Personal stuff is not work.

    The bad and ugly reasons are mostly accurate, but using wrong and misplaced points to prove something else always get me and makes no sense.

    On the other hand, after several years at Mozilla, I have noticed that the more I work in the open the easier it is. At first it feels wrong to work too much in the open. Its too dangerous, you know.
    But when you try it it makes everything easy. People have to listen to you, its public, its discussed. Ideas are talked about. Things work. People work. Working in the open helps a lot.

    1. I think the personal reasons are valid ones to be closed. But if you want Mozilla ones, I’d take things like many employment issues.

  4. Good post Stormy. Open is most excellent but it’s not the ONE way.

    Buy in. & Getting Clear: I’ve been putting thought to this as have an idea I want to take through a Lean Startup process. I’m still not decided if I will develop in the open from the get go or not. So lean startup says no to Stealth Mode but rather a Quiet Mode as you ask as many people about your early concepts as possible and use feed pack to test and adjust your Business Model out. SO hat to me implies being open as the reason for not worrying about people stealing ideas apply also to the code. The product follows quickly once you seem to have a good match idea/problem match. I have to figure where I am with my idea in terms of business model and when to go open. I want to get to MVP (or better minimum loveable product, MLP) quickly to get more feedback and think doing that in the open helps enhance the feedback loop.

Comments are closed.