Case Study—This is a case about how Mozilla, the open source browser company, set out to reconnect with ‘collaborating in the open’ to regain its competitive advantage. This case describes how a multi-disciplinary research team used ethnographic, market, and data analysis to articulate and clarify the problem, and build a strategy towards revitalizing Openness at Mozilla. It will aim to prove that the subsequent change achieved could only have been accomplished by a mixed method research approach. And importantly show, how the team used data to prove the distribution of findings, coupled with ethnography to shine light on the why and how of those findings. The case study will do this by discussing the key insights and how these fueled recommendation and subsequent change in the organisation.
The project presented many problems: from convincing stakeholders of the need to fully explore the problem, to connecting widely different research methods and gleaning insights that built strongly on all strands of research. Overcoming these issues together, the team managed to outlay the key problems and opportunities for Mozilla and build a strategy which has affected real change in the company and is now being implemented by a team of 20 employees. We call this strategy Open by Design. Which, to us, means being open, purposefully.
David (not his real name), a contributor to Firefox through 4 years, was getting ready for his day. The sun was shining outside, spring was clearly in the air. This morning, as all mornings, he went to his small study with his coffee and turned on his computer. David enjoyed his morning routine immensely. The hour or two, before heading to work, where David could plug in and work on some of the projects he loved. This was his time, no one could tell him what to do and he decided what mattered. Mostly over the last 4 years it had been working on Firefox, but many other open source projects had from time to time taken his attention, but he always came back to the browser. The people there were his friends and his peers. He knew many of them personally. This morning should be like the rest, but as he sat down David felt different. Lately he had begun to reflect on the work; increasingly the core contributors he had worked with had left the project, overall there were more staff and fewer contributors, and it had become increasingly hard to get things through and see your code in the final product. Most of the time it felt like he was banging at an increasingly closed door. He remembered fondly the old days. Actually, he thought to himself, he wished things were different, but he was starting to question his ability to change them. He starred at the blinking white cursor on his dark terminal screen for a while, an empty window waiting for his command. He looked solemnly around the room, and instead closed his computer. For the first time, in 4 years, David got up from his chair without checking in on IRC or Github, and went straight to work. This morning definitely felt different.
David, is one of many contributors who over time left the Firefox project. Open Source projects have a natural churn but this was different, Mozilla was feeling like it was experiencing a decline in contributors. And this at a time where it needed them more then ever.
BACKGROUND
When in 1998, Netscape made its code open source, it was not just a fun gimmick, it was groundbreaking. Essentially the company had just ‘given away’ their source code. (Festa, 1998). Back then a hopeful software engineer commented to CNET journalist Paul Festa:
“You’re starting out with an industrial-strength browser and now you have many qualified developers working from it. I imagine Netscape’s developer teams can’t compete with Microsoft in terms of resources, but with Netscape working with outside developers, I think you’re going to wind up with a very good product” – interview from 1998 (Festa, 1998).
He would be proven right in his prediction. While the first years of Netscape, and then subsequently the Mozilla project, were tumultuous, a small group of employees and contributors battled through and after 6 years they released Firefox 1.0. (Shankland, S., 2018)1.
When Mozilla released Firefox 1.0, it was a better, simpler browser – and the only alternative to the then current monopoly holder; Internet Explorer. The success of the project was not immediate, but over time, it grew, and once momentum took off, there was no going back. The browser market changed forever2, and in so doing, Mozilla had proven that Open Source, or open collaboration, could work at scale.
It was clear to anyone who watched the subsequent growth of Firefox (Levy, Feb 2008) that open source was Mozilla’s main competitive advantage. Throughout the browser wars, Mozilla’s Firefox consistently prevailed over the competition through a deep focus on open practices and democratised ways of building technology. Contributors (volunteers on the project) translated the browser into over 124 languages3; a key browser feature was invented by a contributor – the Tab4 – allowing users to easily work across many sites at once. Contributors tested the product and provided crucial support to users with questions. They multiplied the strength of the few Mozilla employees and made the browser the free, open browser that millions of users use today. The success story of Firefox had been turbocharged by open collaboration and open source.
The success of Firefox and Open Source inspired many upcoming entrepreneurs in the tech industry, including some of the major players today. As such, by 2015, open source was no longer a radical movement, having grown industrial in scale (Newman, 1999). Companies like Google, Facebook and Microsoft (Nomas, Marts, 2018), currently use open source licenses to release their code (as an example Google currently has over 2,000 open source projects released).
While we may not think much about it in our daily lives, many of the key platforms we all rely on today are open source; from Android to WordPress. Companies adopted open source widely and, in so doing, explored new and different configurations of what open source could be, thereby further developing open source structures and archetypes. (Kripalani, 2017, Open Tech Strategies, 2018)
Over time, Mozilla had integrated open source as a key part of its identity as well. However, as the company grew, things increasingly became open source in name more so than in action and while code / documentation was released, there was less and less focus on engaging the communities around the projects. Slowly, the company began building things internally and with dwindling focus on building the communities around the projects (Discourse Post, 2017).
No one person at Mozilla set out to minimise collaboration outside the company; many factors contributed to the shift. While open source had proved great for smaller projects; the company was now larger, and the projects were mature products, with a substantially increased complexity of code and hundreds of millions of users.
” The general feeling in the community is that Mozilla has lost its way and doesn’t care about community anymore. This may impact influencers more. Which is really not good as these are the people who recommend what to install. We have lost a lot of those people to Chrome.” – Sr. Product Manager – Firefox.
The stories of how the company had won through open source still fueled the company culture (Briody, 2015), but the stories and narratives were no longer prevalent, and more crucially, they were hidden away deep within certain pockets of the company.
“We now have a significantly large enough population of folks at Mozilla that don’t have that (open) history, that don’t know the history of Mozilla being built by contributors… ” – Sr. Staff Engineer – Firefox
The sense that Mozilla had lost its focus on its main competitive advantage – collaborating in the open – was becoming an increasing concern to employees and leaders.
This change presented a very real conflict for the organisation. While the company had grown in size from when it first released Firefox, it was obvious that it would never be big enough to directly compete with its main competitors on resources nor funding.
Figure 1. Top US R&D spending 2011-2016. Source: Bloomberg.
It was clear to leadership that there was no single winning strategy that didn’t include collaborating with the ecosystem of the open web, the very same ecosystem that had helped Mozilla succeed before.
In 2016, the leadership took a stance and set a clear goal for the company; Revitalize Openness at Mozilla. To deliver on this ambitious goal, CEO Chris Beard brought in long term board member Katharina Borchert.
Knowing what questions to ask
The goal of revitalizing openness at Mozilla meant identifying and implementing opportunities for Mozilla to make ‘collaborating beyond company borders’ a competitive advantage again.
While the overall impact of the problem was clear to leadership, the cause and effects were less so. Over time, the projects and people focusing on open collaboration had shifted and moved. As a result no one had a clear overview of how much, who, where, or why, open collaboration was happening on projects across the organisation; nor why or if it wasn’t being as effective as it used to be.
Identifying new opportunities first meant that some exploratory questions had to be answered. The group narrowed down to three key research questions:
- What is the current state of open collaborations at Mozilla?
- What, if anything, has changed overtime?
- What are other successful examples of open collaboration that Mozilla can be inspired by?
Choosing the right lenses
Based on the goal at hand, it was clear the problem needed to be understood from many different perspectives. The team wanted the work to have a solid grounding, so a multi-disciplinary team were brought together to deliver a mixed method exploration; consisting of ethnographic, market and data analysis researchers.
METHODOLOGY
In the end, four streams of research were initiated to answer the project’s research questions (Edwards, 2010, Greene, J.C., 2006).
1. Internal Interviews & Observations – The in-house ethnographic research included 38 interviews with staff across Mozilla. Questions focused on: the interviewee’s role in the company and their work with contributors, the perceived value of external collaboration or “working open” to Mozilla, and potential opportunities for ‘open collaboration’ within their field. The interviews were conducted on site, where possible, and remotely over video conference software, where not. All interviews were recorded, transcribed and archived. This stream of research was initiated before the others, in order for the team to validate the key research questions and build stakeholder support for the project from the get-go. This early round of stakeholder input enabled the team to move beyond the ‘researcher mindset’ and ensure the problem space was validated organisation wide (Swanson, R. & Holton, E., 2005, p 10-18).
2. Competitor Research: Competitor analysis of leaders in the space – An early finding from the staff interviews was a general feeling that Mozilla had fallen behind on open source ways of working and size of community. It therefore became clear there was a need to understand external companies’ success in open collaboration. Competitor analysis and interviews were done with 7 leaders in open collaboration to explore how they were strategically using open methods in their business. In total 30 interviews were conducted with staff from across the companies. The seven companies were: Automattic, Arduino, Kubernetes/CNCF, 23andMe, NASA, Aleph Objects and Sage Bionetworks. The interviews focused on their internal structures, motivations for external collaboration and the resulting impact. The interviews were conducted in collaboration with Copenhagen Interaction Institute of Design (CIID).
3. Contributor Survey – Focusing on our existing contributor base, and ensuring their perspectives were represented, was a core focus for the team. To this end, a survey instrument was employed. The team had in 2016, through interviews and observations, explored motivations behind contributions. This research was used as a basis for the survey design, thus ensuring that the instrument was built on well-grounded findings5. The survey was designed to explore what projects contributors were working on, how they engage with Mozilla and why. The survey target audience consisted of three segments: active contributors, past contributors, and never contributed (lurkers). To reach all three, the survey was distributed widely among the communities and had over 1700 respondents, of which, 1019 were complete (n=1019).
4. Data analysis of past contributions over 16 years – Getting to understand the historic data of contribution was the real challenge for the team as it had never been done before. Luckily one of the teams working directly with contributors had recently begun early explorations with a outside company named Bitergia. Together they started to measure code contributions on the platforms Mozilla primarily used (Bugzilla and Github). Together with Bitergia, an ambitious project was initiated to see if this prototype system could provide contributor data on all Mozilla hosted projects. In the end, the team succeeded in providing data on code contributions across Mozilla’s many projects spanning the previous 16 years and sorting out employee data from non-employee data. The subsequent quantitative analysis of the data sources focused on the development of Mozilla products and technology, including: source code repositories, issue tracking systems and asynchronous communication systems. The study was structured across several areas of inquiry: activity (volume of activity of contributors), community (people contributing), processes (efficiency of dealing with issues), attraction / retention (how the project attracted and retained its contributors), levels of contribution, and gender diversity. In order to cover most contribution areas, public data sources from code (git, github), bug tracking (bugzilla, github issues) and discussions (mailing lists and discourse) were also used6.
Breaking down the methods by research questions
To ensure the team had a clear overview going into the research project each method was mapped out against the key research questions. Each stream of work had its own research design documentation [including sub research questions].
Table 1. Research Questions by Method
| Research Activities / Key Research Questions | What is the current state of external collaborations at Mozilla? | What, if anything, has changed overtime? | What are other successful examples of open collaboration? |
| Internal Interviews & Observations | What are staff perspectives on external collaboration at Mozilla? What motivates or blocks staff from engaging today? |
What are staff perspectives on external collaboration at Mozilla? | What opportunities and challenges do staff see for external collaboration? |
| Data analysis of past contributions over 16 years | What is our current state of affairs (who does what, where)? | How have contributions actually evolved over time? | |
| Competitor Research | What benefits and challenges are realised by external collaboration? | ||
| Contributor Survey | What is our current state of affairs (who does what, where)? Who are contributors are and why they contribute? |
Understand what projects people are working on today and why? | Who are the contributors and why do they contribute? |
Timeline
Below shows when the different research projects were conducted in relation to each other.
Figure 2. Timeline of research activities.
Tiburon Workshop
To bring the streams of research together, a week-long workshop was held in Tiburon, CA. The participants in the workshop consisted of the Mozilla project team and CIID as well as selected key stakeholders from across the organisation who had been involved or interested in the work throughout the research.
ANALYSIS
The analysis of all the different research streams presented its own challenge – as different researchers had been on different projects, pulling together the findings to identify commonalities or variations was crucial in order to tell a coherent story and to gain the required insights.
The Tiburon Workshop was viewed as the team’s chance to pull together insights from across the research streams and to build the final strategy recommendations. A great deal rested on the team’s ability to deliver in this single week.
In preparation for the workshop, each research stream was tasked with pulling together an ‘interim results report’ as well as some key learnings / recommendations as pre-reads.
Every workshop participant also had to write their own summary of insights, going into the week, therefore allowing all participants to have detailed understanding of findings across the reports. Another smaller, but highly beneficial tactic the team employed, was getting a large space for the group and covering the walls in floor to ceiling foam boards with the key research findings, allowing the team to physically see the results throughout the week.
Table 2. Tiburon Schedule
| MondaySetting the week up.
Review and synthesis of research begins. |
TuesdayContinued work, including review and synthesis.
Insight areas deep dive. |
WednesdayConnecting the insights from different research streams into one set of findings with multiple sources. | ThursdayWhat does it mean: From insight to Opportunity. | FridayStrategy deep dive. Agreeing on recommendations and ways forward. |
Figure 3. Analysis week.
By the end of Wednesday, it became clear that two days was not long enough for the team to cover opportunities and recommendations. As a last minute change, a small group were assigned individual insight areas and asked to write up suggested actionable next steps and recommendations. These would act as a foundation for the team’s discussions the next day. This last minute change in program meant more work for the team members who worked through the evening on building the draft recommendations, but, as the team came back together Thursday it was clear that this work had paid off. The draft recommendations became a great foundation for discussions and, subsequently, most of Thursday was spent reviewing, and further building upon them, as a team. This ensured that, by end of Friday, the team had successfully been able to work from insights in to opportunities and then through to strategic recommendations that outlined how we could achieve the final goal; Revitalising Openness at Mozilla.
While synthesis workshops are always notoriously hard to structure, a few key lessons were learned: firstly, ensure you have enough time to wrap up findings. Secondly, ensure there is broad agreement to recommendations, allowing all to have input[the goal is to build consensus]. Thirdly, allowing stakeholders to start talking about findings immediately after the workshop. This helped build momentum for the work and – even if not perfectly presented – can become a change making catalyst, in and of itself, within the organisation.
Figure 4. Analysis week.
FINDINGS
By September the team was able to present the first ever, in depth look on open collaboration and contribution across Mozilla. The findings were intriguing and helped break through several mental glass ceilings that had existed within Mozilla for years.
While the total findings include more than can be shared in this case study; what follows will cover a few of the key highlights and how they influenced the final strategy and recommendations.
Understanding the History and Status Quo
Contribution at Mozilla is steadily growing – The first thing the team identified was how some of the prevailing assumptions across Mozilla (and within the research group) were simply not true. The internal interviews showed a general acceptance that Mozilla had become worse at working in the open but the data analysis, however, showed that contributions, over time, had actually increased slightly. Breaking this mental model of declining external participation was one of the most important insights from the work as it allowed the conversation within Mozilla to change from one of hopelessness and negativity, in to one of opportunity.
Key Finding: The question needed to be asked differently; instead of asking ‘why did we lose our external collaboration’, Mozilla needed to understand ‘how do we ensure all projects, across Mozilla, ‘learn from the projects which are doing well? ’
Figure 5. Chart: commits by non-employees over time, per quarter.
The perception of a declining trend had, however, not come from nowhere; Fewer projects were working in the open across Mozilla, leading staff to experience an overall downtrend. Only 6 projects now accounted for over half of contributions by non-employees. Contribution, it seems, had not been declining, instead it had concentrated around fewer projects, with some of those projects doing much better than others.
Mozilla is not one community – The findings from the internal interviews had shown a mental model of contributors as a singular network; ‘the Mozilla community’7.
However, the research showed us that there is not one ‘singular’ Mozilla community. In fact contributor activity on projects tends to be siloed. We were able to identify 6 distinct siloed communities that had little to no overlap between the contributors.
Their differences were not related simply to one specific project nor skillset, but also to motivations, operational norms, social capital, feelings of affiliation, and more.
Key Finding: Understanding the differences between contributor communities and the reasons behind their respective behaviors is fundamental to improving engagement, retention, and providing collaboration opportunities of mutual benefit.
Figure 6. Factor Analysis of Project Contribution / Affiliation (self reported) showing 6 distinct groups. Source: Communities & Contributors Qualitative Survey, 2017
An internal hunger for Open is paired with a sense of skepticism – The organisational research identified a real internal interest for open ways of working – something that had been hypothesised to no longer be part of the Mozilla culture. Out of the 38 interviews conducted internally, 35 spoke positively about the opportunities and experiences of external collaboration. One Staff Engineer expressed it best:
“The benefits of external collaboration are that it brings in bold experiments – and much more diverse sources of input than any company could do themselves: people from different countries, socioeconomic backgrounds, different vocations… There’s an open source saying that “with lots of eyeballs, all bugs are shallow”. The raw numbers brought to bear on fixing problems – and on discovering problems that can thus be fixed.”
However, findings also showed that Open Source practices had become increasingly decentralised in the organisation and had, subsequently, lost internal status and recognition.
And although the overall data showed an increasing trend of contribution, the staff interviews highlighted many things, internally, that no longer worked, as well as new opportunities that had never been taken advantage of before:
- Product decisions made behind closed doors does not allow us to take advantage of the diverse community. A staff engineer commented: “Firefox ships to many people, but highly technical people are making decisions within Mozilla that may not resonate with a wider field of users.”
- A move from open to closed tools (discourse, 2017); the integration of slack was highly beneficial for staff but took staff off IRC and into closed networks (slack) the contributors couldn’t easily access.
- Short term goals (quarterly) of staff did not leave room to think about community or ecosystem engagement and led to misalignment with community interest.
The hunger for open was clear, but mental models showed a fair deal of skepticism around the reality of open source: Open collaboration was never an easy fix. A Sr Engineer commented:
“There are people who make an enormous number of bug contributions, but most of them are just noise… yet there are people who show up once every three months with five lines of code to fix something that would have cost us a lot of man hours.”
Identifying new opportunities of open collaboration
Key Finding: To succeed in revitalizing open at Mozilla, the team would have to answer: How do you find the value in the noise?
The research didn’t just shine a light on the current status of contribution and openness at Mozilla, it also highlighted areas of improvement for the company. These are some of the immediate opportunities that were discovered.
Internal mental models of contributors relate to individual contributors, at the exclusion of thinking about the partners and companies we can collaborate with…- Consequently, we focus on intrinsic motivations for contribution, rather than extrinsic and economic motivations for partners. Partnering with companies and organisations has allowed a company like Arduino to evolve products to meet needs of its diverse users. And for both, Automattic and Kubernetes, the contributing engineers are to a high degree employed by partners – therefore, ensuring wide implementation amongst the set of contribution organisations, allowing the projects to build a strong case for becoming a standard technology or product. Furthermore, focusing on partnerships was a way for all of the companies interviewed to minimise cost and spread risks.
“NASA wants companies to form and generate these products because we don’t want to generate them ourselves and we get an advantage if they’re commercialised and the price goes down,…we had to shut down Space Shuttle because we couldn’t sustain the custom companies (red: internally)” – Deputy Director – CoECI NASA
Different projects attract different profiles of contributors and lend themselves to different forms of contribution – The findings highlighted big differences between type of contribution, motivational factors, and demographics across projects. This, along with the insight that contributor experiences should be designed for the target audience, made it clear to the team that Mozilla’s previous ‘one size fits all’ way of doing open source, or open collaboration in general, did not work. The community is simply too diverse and differs too greatly across projects.
Figure 7. Project Affiliation by Motivations for active contributor
Designing for community diversity supports ecosystem growth – Ensuring that a diverse set of people can be invited to participate in projects turned out to be a key focus for other companies. The companies had instigated many methods to improve this – from a welcoming presence for new contributors, through to allowing contribution across a range of skill sets and ensuring that their community managers focused on spreading the message of diversity and tolerance in online and offline forums.
Matt believes in open source democracy, but not open democracy. He’s not excited about tolerating trolls … he’s not so committed to openness that he would let it affect the organisation or culture. – Simon Phipps, Managing Director Automattic – Meshed Insights / Open Source Thought Leader.
When the team compared this insight to our data analysis findings, the results did not look good. Especially on gender, Mozilla performed poorly. Gender diversity is a known issue in open source, but the Mozilla community was found to be performing worse than others (who were already performing badly).
Table 3. Comparison of female contributors in source code repositories for several FOSS projects10
| OpenStack | Linux Kernel | Hadoop Ecosystem | Mozilla | |
|---|---|---|---|---|
| All history | 839 (10.63%) | 1,150 (8%) | 129 (7.5%) | 822 (5.5%) |
| Last year of analysis | 422 (11.53%) | 330 (9.9%) | 71 (8.5%) | 282 (6.5%) |
Key Finding: Focus on diversity and inclusion as a way to ensure open source community health.
Focus on the community experience – The external research showed how other companies had built open practices into their processes by, building experiences for contributors, thinking modularity into their processes, and understanding the value of the crowd in the contribution experience.
From the very beginning, Arduino has focused on enabling people to realize their ideas. Over the years their determination to continually improve the user experience and make it accessible for ‘newbies’ has created an inclusive system that appeals to a larger audience. Continual and assiduous community engagement, through teaching and rapid prototyping, has been crucial in developing their design & feature strategy.
Key Finding: Design the contribution experience to ensure retention and engagement.
OUTCOMES
This project provided the first ever exploration into the true value of contribution at Mozilla. Over 16 years of historical data was analysed, as well as a wide survey of existing contributors and staff interviews. For the first time, it was possible to build a full picture of ‘contribution’ whilst also allowing contributors to tell their stories. This research helped steer Mozilla away from making decisions based on assumed mental models. It also gathered employees around the call to action to re-invent ‘open collaboration’ and usher in a new era of Open at Mozilla based on deep research.
The findings formed the basis of a new strategy for Mozilla towards open collaboration; dubbed Open by Design. It steered the company to focus on 4 areas of improvement based on the research:
1. Build out processes for engaging partners as well as individual contributors.
Compared to other Open Source organisations, Mozilla’s internal mental models were shown to skew towards thinking of contributors as ‘individuals’ at the cost and exclusion of thinking about the ecosystem and partners we can influence. This led to a new program being created, now referred to as the Open Source Strategy program. Its purpose is to identify external partners fostering collaboration on Mozilla’s open source projects.
2. Engage in open practices across the product life cycle, with a deep focus on experience design.
The findings showed a current lack of systematic evaluation of community input, as well as a lack of focus on how we design for engagements with contributors. This has led to the creation of a Service Design team currently working across open source and crowdsourcing projects to design the experience touchpoints for external collaboration.
3. Introducing an in-house process for identifying what models of openness to implement, depending on audience and needs.
A key finding from the research showed that different projects attract different profiles of contributors, which leads to different forms of contribution. This drove the Open Source strategy program to start exploring how Mozilla thinks more differently about how it structures new Open Source programs. Following on from this, the team recently launched the Open Source Archetypes8 work which is now being employed by our internal R&D group.
4. Introducing best practices in Open Innovation and Open Source
Including diversity and inclusion for Open Source group health metrics and community development best practices. The findings underlined that designing for community diversity supports growth and health in the communities. It also showed that there is a general lack of success metrics for open source projects. The community development team has, in recent months, focused on solving for this; including, partaking in CHAOSS9 efforts to deliver health metrics for Open Source and focusing on D&I best practices, including a monthly community call to share the results.
SUMMARY
This case study aims to show some of the unique benefits of combining research methods, such as data analysis and ethnographic research. It further aims to outline that a team of data analysts and ethnographers can benefit from collaboration, not only with each other, but also with business strategists and market researchers.
The team would never have got the buy-in it needed (as proven by the ethnographic research conducted in 2016) with only one lens on this problem. Data was needed, but data alone could not tell the full story.
Achieving the diversity of skills may not always be possible but, when we strive to, it can bring the exploration of business problems to new levels of impact.
LEARNINGS
Leading a large research project such as this was challenging for all involved. Not only was it the first time that Mozilla had invested so much time and money into understanding its communities, it was also the first time that the team worked with such a diverse set of expertise and backgrounds.
Ensuring we had C-level buy in for such a large-scale project took time and, in hindsight, it would have been beneficial to spread the research over a longer period.
This project is a great example of how an interdisciplinary research team can achieve true company change through the application of mixed method research as well as, employing data science and ethnography to show, not just the distribution of findings, but also the why and how. It helped the team and the wider company to see the value of mixed method, by looking beyond the data and crucially explore the deeper reasons and connections behind it.
Rina Tambo Jensen is an experienced design researcher and service designer working for Mozilla in San Francisco.
The team
Rina Tambo Jensen • Lead Researcher
Patrick Finch • Strategy Lead
George Roter – Community Development Lead
Susy Struble • External & Internal Project Manager
Pierros Papadeas • Open Source Expert
Rube?n Martin • C&C Project Manager
David B. Schwartz • Researcher
External Partners
CIID (Copenhagen Institute of Interaction Design) • External Research
Bitergia • Data Platform Analysis
Mozilla’s Contributors
And as always to our great volunteers all across the world!
NOTES
1. https://www.youtube.com/watch?v=yyyoz3yGqrw
2. https://upload.wikimedia.org/wikipedia/commons/7/74/Timeline_of_web_browsers.svg
3. https://pontoon.mozilla.org/projects/firefox/
4. https://allthatiswrong.wordpress.com/2011/01/14/opera-did-not-invent-tabbed-browsing/
5. The initial contributor story presented in this article is also taken from that work
6. Note that some sources couldn’t be gathered for this study and are not considered in this report: Mercurial repos not mirrored in github (mainly l10n), contributions through MDN, SUMO or AMO sites and Marketing tools. Firefox and Gecko code were considered as the same group for this version of the report, we will look into separating them for the next iteration.
7. https://wiki.mozilla.org/Community
8. https://blog.mozilla.org/wp-content/uploads/2018/05/MZOTS_OS_Archetypes_report_ext_scr.pdf
9. https://www.linuxfoundation.org/blog/chaoss-project-creates-tools-to-analyze-software-development-and-measure-open-source-community-health/
10. Female contributors is the fraction of developers identified as female, leaving out those identified as male, or unknown.
Definitions
- Active: To have contributed to Mozilla or related project in the last year.
- A Contribution: Is also self reported and could be reported via our different contribution
- Community: Used to refer to the survey population.
- Contributor: The case of the survey a self selection definition. I.e. if people have said they have contributed we assume this is the case and ask them about it. There may therefore be some self selecting bias in this group. We’ve mitigated for the bias by cleaning up Actives who have not noted any contribution areas or types.
- Contribution Area: The area within Mozilla or related project they contribute too
- Contribution Type: The activity they contribute with to that area. Full list seen in contribution types.
- Inactive (sometimes Past): Have contributed to Mozilla or related project longer than one year ago.
- Never Active: People who have signed up for information but never interacted with Mozilla or related project.
REFERENCES CITED
Andersen, K.
2009. Ethnographic Research: A Key to Strategy. HBR.
Bourdieu, P & Wacquant J.
1992 An invitation to Reflective Sociology. Washington University.
Swanson, R. & Holton, E.
2005 Foundations and Methods of Inquiry – Research in Organisations. Berrett-Koehler Publishers.
Greene, J.C
2006 Toward a methodology of mixed methods social inquiry . Research in the Schools, 13(1), 93-99.
Brewer, J., & Hunter, A.
1989 Multi-method research. Thousand Oaks, CA: Sage
Edwards, Gemma
2010 Mixed-method approaches to social network analysis. Discussion Paper. NCRM.
Newman, N.
1999 The origins and future of open source software.
West, J., & Gallagher, S
2006 Patterns of open innovation in open source software. Open Innovation: researching a new paradigm, 235(11).
Thakker, D. et al
2017 Tracking the explosive growth of open-source software. TWC. April 7 2017.
Shankland, S.
2018 Mozilla’s radical open-source move helped rewrite rules of tech. CNET. 2018, March 29.
Discourse Post, Kairo,
2017 Thoughts on Mozilla using Closed-Source Software. Discourse. https://discourse.mozilla.org/t/thoughts-on-mozilla-using-closed-source-software/19000/9
Bertel King, Jr
2016 March 28, 2016, Makeuseof.com: “Is Android Really Open Source? And Does It Even Matter?
Raúl Kripalani
2017 An analysis of the licenses used by 75+ Open Source projects across 35 companies
Jim Hamerly and Tom Paquin with Susan Walton
1999 Open Sources: Voices from the Open Source Revolution”. O’Reilly
Steven Levy
2012 The Browser Wars” 09 Feb 2008 – https://www.wired.com/2008/09/the-browser-wars/
Mozilla
2018 Open Tech Strategies – https://blog.mozilla.org/wp-content/uploads/2018/05/MZOTS_OS_Archetypes_report_ext_scr.pdf
MICHELUCCI, P, & DICKINSON J. L.,
2016 The power of crowds. SCIENCE.
Paul Festa
1998 Net elated over Netscape giveaway – January 22, 1998 – https://www.cnet.com/news/net-elated-over-netscape-giveaway/
Oshri, I., de Vries, H. J., & de Vries, H.
2010 The rise of Firefox in the web browser industry: The role of open source in setting standards. Business History, 52(5), 834-856
Wang, T. et al
2005 The Revival of Mozilla in the Browser War Against Internet Explorer. – https://www.researchgate.net/publication/221550584_The_revival_of_Mozilla_in_the_browser_war_against_Internet_Explorer
Swift, M.
2011 Browser wars: Mozilla’s Firefox challenges Microsoft’s IE, Google’s Chrome. MecuryNews. 2011, Mar 12
Briody, E., Meerwarth Pester, T., & Trotter, R
2012 A story’s impact on organizational-culture change. Journal of Organizational Change Management, 25(1), 67-87.
Gino, F.
2015 The Unexpected Influence of Stories Told at Work. – 2015, Sep 15 HBR