Developer relations is the combination of activities, programs and tactics to get developers using or developing for your organization’s product or ecosystem. The goal of a good developer relations team is often to make your organization’s product or ecosystem the first choice for developers. (You may be doing this just to sell more of your product or you may be doing this because you believe your product’s mission helps make the world a better place. You are still trying to get more developers using your product.)
What’s the goal of a good developer relations plan?
Your developer relations plan needs a goal that you can focus on. You need to be able to measure the results of your activities so that you know what you should do more of and what you can do less of.
Some potential goals for a good developer relations plan might include: (Some of these by Patrick Chanezon.)
Increasing the adoption of your organization’s product. Example: more people using Firefox.
Providing an opportunity for developers to profit. Example: an app store for developers to list their applications.
Growing the number of people that benefit. Example: training companies, consultants, app providers.
Reducing the cost and risk of using your product.
Increasing the percentage of developers that are developing only or mostly for your product.
Increasing the network effects in your ecosystem.
Decreasing the cost of adopting your platform or increasing the cost of leaving your platform.
Creating an environment where developers just assume they’ll use your platform.
Encouraging third party tools, trainers and consultants for your platform.
Creating a community of volunteer advocates.
Some developer relations groups also act against the competition. I don’t think that’s a long term strategy. Your product and ecosystem have to be good.
What are the stages of a developer relations audience?
You can move from one stage to the other using many different techniques. Breaking down the stages a bit further, you can map how specific evangelism activities like blogging or talking, might take you from one to the other.
Who should you have on your developer relations team?
While we usually talk about developer relations as teams, we also need to look at their functions. While each team has a primary function, functions are often shared between teams. Mozilla has outreach and content teams. Google is also organized this way, as presented in a talk by Patrick Chanezon.
Outreach. Creating awareness of the product or ecosystem among developers. Most outreach efforts include evangelists. These are people that go out and speak, engage with others, teach enough to get people started, write blog posts, let large numbers of people involved. They are typically most involved in the outreach and awareness part of the program.
Content. This includes tutorials, documentation and examples. Making sure that developers that are interested in the platform have the materials they need to learn it. This team should include technical writers, educational experts and programmers. These are the people that are most involved in the online training part of your program. They write documentation that lets people learn how to use the technology. Sometimes they write the examples. Sometimes they create training or online tutorials.
Support. When developers start using your product, they will need people to help answer their technical questions or help resolve the bugs they find. This team usually consists of support engineers. They are around to answer questions, help people get going, create code examples. Often when bootstrapping, this function comes from the evangelists but it’s really a different type of personality and role. This team is most likely to provide valuable feedback to the product teams.
There’s another couple of roles worth calling out.
Program managers. A successful developer relations program often relies on programs. These might be things like a world wide community run, simultaneous events or a “free phones for apps” program.
Key stories/participants/case studies. These are people that have a story that successfully highlight what you are trying to do. And, while they might not be evangelists, they are competent spokespeople. You talk about them, point people at them, highlight them, enable them to tell their story and help them spread it.
Event managers/coordinators. Smaller groups might have several volunteers. Larger organizations might have lots of volunteer meetup or hackathon organizers and maybe even a paid staff team to support them.
Community management. Whether or not you have an official community manager, there are probably numerous people helping out with “community management” whether it’s onboarding new contributors, reviewing patches or answering questions on the mailing list.
What are the key components? What types of tools and projects are useful?
It’s useful to first look at your project’s strengths. Do you have a large community? Strong contributors? A highly followed blog? A strong culture of global meetups? A clear brand?
Some of the projects and tools you might consider are:
Programs that support your goals. For example, Mozilla ran Phones for Apps.
Messages/materials. Developer relations can either include product marketing and press or work closely with those teams to develop messaging and materials that support the goals and the audience.
Events. Events can include everything from monthly meetups to hackfests to large annual conferences. Many teams often divide events into the organization’s events, sponsoring others events and sending speakers to events.
Training. As people join your ecosystem or start using your product, they are more likely to stay if they can get the training they want. Cloud Foundry has “dojos” – a place at several member organizations where interested developers can go train with a more experienced member for six weeks.
Examples. A key component of learning is being able to see how something is done and copy it. At Mozilla we created Demo Studio to allow people to share and build on others work on the web.
Documentation. Documentation is key to a project for two key reasons. One is discoverability and the other is learning and support.
Contributors. Depending on the type of product or organization you are supporting, you may want programs in place to specifically support contributors. This may be as simple as swag or as involved as official titles and budget for programs and travel for them.
Feedback mechanisms. An important part of many developer relations teams is providing feedback mechanisms for users to give feedback to the product teams. It helps to put into place objective tools and mechanisms for this.
QA forums. Question and answer forums like StackOverflow have become critical to how developers expect to find help when they are working. Having a standard place where your experts will be will help.
Membership. Often membership can support the different groups you want to grow. You can have users groups, contributor groups, advocacy. You can use titles, mailing list membership, swag and travel funds to distinguish and reward them.
Discussion. A place where people can come and chat and “hang out” with your community is important. Q&A forums often give them answers but not a sense of belonging. Also discussion groups are often an easier way for really new users to get started.
Advocates. Recognize our key advocates and give them a megaphone. Connect them with the press and speaking opportunities.
What does your Developer Relations plan and group look like? What would you add to create your ideal plan?
When you hear that a 13 year old, black girl is giving a keynote at OSCON, what do you think?
Wow, she must be a child prodigy, what did she do?
Who are her parents?
She got that keynote because she’s a 13 year old, black, girl.
I’ve heard all three options and a few in between.
The truth is that Keila Banks is pretty awesome. She’s an accomplished blogger/technologist and her 10 minute keynote (to a 4,000 person audience!), “The Undefinable Me”, is well worth watching.
And Keila’s parents are pretty awesome too. They have given Keila lots of support and encouragement as she explores the opportunities around her. They are as inspirational to me as a parent as Keila is.
I was standing on stage last week when I realized that the words out of my mouth were in direct contradiction to advice I normally give. Nothing like having a couple hundred people and a video camera staring at you as you try to figure out what you really mean.
Just do it
In the past, I’ve pointed out that it’s really hard for people to make their first contribution. Think back to that very first time you posted to a mailing list or newsgroup. It was a bit intimidating. You don’t know how many people will read it. You don’t know how people will respond. And it will be public forever. That’s pretty intimidating.
So I urge that you just have to do it. And community managers and mentors need to help people to Just Do It.
Make it Count
And then last week, I said first impressions count. So make sure your first point is one you want people to remember you by. And in the context of my talk, I said you should especially pay attention to first impressions if you are in the minority. Do you want to be remembered for that crazy red shirt? Or for the great question you asked about the target audience that started an awesome debate?
When I first started at GNOME, they added me to Planet GNOME and my very first post was about traveling alone. I wish I could take that back. It’s not a bad post. It just has nothing to do with GNOME and it’s not what I wanted the whole community to know first about me.
You can recover from less than stellar first impressions. All the GNOME posts I’ve written since then about the GNOME Foundation and projects have surely made up for that first off topic post.
The balance between Just do it and Make it Count is even harder in some circumstances.
Representing multiple groups. If you feel like you are representing others, especially as a lone representative of a minority group (the only woman, the only American, the only Asian), you will feel like your actions have to be even better, and that your first impression has to be good.
More experience. I also think that more experience makes it harder to “just do it”. Once you are seen as an expert, posting to a mailing list is probably no longer scary. However, you might feel like your work is held to a higher standard and that more people are watching you. (And I think this ties directly to the Impostor Syndrome.)
Other disadvantages. I also think it’s hard to just do it if you have another disadvantage. For example, if you first language is not English, it’s much harder to make that first post.
What’s your balance?
How do you find balance between “Making it count” and “Just doing it”?
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?
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?
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?
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.
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!)