Open Source Software (OSS) is no longer a "weekend warrior's endeavor" [1]. Over the last 20 years, the OSS ecosystem composition has changed drastically. OSS is now fundamental to company operations-not only for the code that they depend on, but also for their role in an ecosystem to which they actively contribute [1], [2]. This is a paradigm shift from the early days when OSS was viewed as a threat that commoditized software to today where individuals and companies work symbiotically. About 77% of respondents to the 2022 State of Open Source survey [3] said they increased the use of OSS in their organizations over the last 12 months. In fact, major companies are now increasingly spearheading the development of state-of-the-art OSS technology (e.g., Kubernetes) [4].
Research thus far, however, has largely investigated the OSS ecosystem from individual contributors' perspective: their experiences in OSS, their motivations to contribute [5]- [11], the different ways to participate [12]- [18], and the challenges they face [6], [11], [19]- [21].
Our understanding of how an OSS ecosystem works and how to sustain it is, therefore, modeled on the "old world" OSS ecosystem, and not the new hybrid reality, where "every software company is an open source company" [22]. We have little understanding of why and how companies get involved in OSS. It is important to understand what motivates companies to engage in OSS for multiple reasons. First, not doing so paints an incomplete picture of the OSS ecosystem, which is arguably one of the pillars of software engineering today [23], [24]. Second, without a clear picture of why companies participate in OSS, efforts to sustain OSS rely only on a subsection of contributors and are less likely to succeed. Third, highlighting the motivations and different mechanisms of engaging with OSS can help other companies recognize the benefits of being part of this hybrid OSS landscape, not only benefiting the company but also making the OSS ecosystem stronger.
Past work that has investigated company involvement with OSS focused on the legal perspective of companies' usage of OSS components [25]- [27], their communication practices when interacting with OSS projects [28], [29], how adoption of OSS matches different company business models [30]- [32], or how companies are using the open source model internally (i.e., innersource) [33]- [40]. These studies do not investigate the motivations of why companies contribute to OSS.
To the best of our knowledge, Linaker and Regnell's case study is the only work that has investigated company motivations-why and when companies decide to open source their products [41]. They identified the objectives that led three organizations (a US media and technology organization, a European-based hardware electronics manufacturer, and the Swedish Public Employment Service) to open source their software. This work serves as a starting point for building a picture of why companies participate in OSS.
In this paper, we aim to create a more comprehensive understanding of company motivations and mechanisms for engaging with the OSS ecosystem by asking: RQ1. What motivates companies to contribute to OSS? RQ2. How do companies contribute to OSS?
By creating an understanding of company motivations (RQ1) we aim to help projects provide an environment that is not only attractive to passionate individuals, but also to companies that can invest in and sustain the project in the long run. Further, articulating companies' motivations to contribute to OSS can also nudge other companies to get more involved. By mapping the different ways companies contribute to OSS (RQ2) we provide guidance to companies that are looking to engage in OSS. OSS projects can also reflect on the wide range of support companies provide and solicit support that aligns with their project needs.
We answer our research questions through interviews with 20 participants from different companies, playing different roles related to OSS (e.g. Open Source Program Office (OSPO) Lead, OSPO Manager, CEO, Ecosystem Strategist) and working at companies of different sizes, including Microsoft, Google, RedHat, and Spotify. We then qualitatively analyzed the data through inductive coding to create a conceptual model of company motivations to engage with OSS and the different ways to do so.
The main contributions of this paper are (1) a comprehensive model of company motivations to contribute to OSS, (2) a conceptual model showing the multi-faceted ways that companies engage in OSS, linked to their motivations, and the benefiting entities, and (3) lessons learned from companies to foster a healthy OSS-company relationship. We hope that our insights on company motivations and contributions to OSS would encourage and provide guidance for more companies to engage in OSS, collaborate in the open, create better software and broaden the economic pie. The lessons we learned from this study will help both companies and OSS projects continue to foster a symbiotic relationship.
Because our study focuses on why and how companies contribute to OSS, we performed semi-structured interviews [42], [43] targeting interviewees with different roles that are knowledgeable about the company's involvement in OSS (e.g., OSPO Lead, CEO, Ecosystem Strategist) working at companies of different sizes (7 small, 1 medium, 9 large) [44] from startups to large technology companies such as Microsoft, Google, RedHat, and Spotify. The following two sections detail our data collection, analysis, and member-checking approach.
Recruitment. We recruited 20 interview participants from 17 different companies of different sizes. We emailed and sent direct messages via Twitter to participants whose contact information was publicly available. Our selection criteria consisted of participants who were either in a leadership position (e.g., Founder, CEO) or in an OSS-related position (e.g., OSPO Lead, Ecosystem Strategist). We first conducted 12 interviews and used a snowball approach to recruit more interviewees. We conducted 8 additional interviews. Table I shows the participants, their roles, and their respective company's details.
Data collection and availability. We arranged meeting dates and times according to each interviewee's availability. All interviews were conducted online. The first author conducted the interviews and started by introducing themselves and the project, and getting permission to record the interview. The interviews were 30 to 60 minutes long. After this, we thanked our participants and compensated them with a 50-dollar gift card as a token of appreciation. The data collection resulted in 20 interviews which were then transcribed. This is in line with the anthropology literature, which states that a set of 10-20 knowledgeable people is sufficient to uncover the core categories in any cultural domain or study of lived experience [45]. The interview transcripts are confidential as per our institutional IRB restrictions. However, to aid verifiability, we have included the interview guide, the codebook with example quotes, and code networks in our supplemental material [46]. Also, Table II gives examples of how the findings mapped to the observations. Data Analysis. We conducted and analyzed the data iteratively and we used ATLAS.tifoot_0 to perform the data analysis. Atlas.ti is a software for qualitative research that assists with analytic procedures by providing tagging capabilities and visualizations (mind maps) allowing the researcher to visually examine features and relationships in the "coded" texts (transcripts). We qualitatively analyzed the transcripts by inductively applying open coding, whereby we identified the motivations and contributions that each participant reported. We built post-formed codes as the analysis progressed and associated them to respective parts of the transcribed interview text. We reached code saturation after 13 interviews where no new codes emerged. However, we decided to finish the rest of the 7 interviews as they were already scheduled and made via personal introductions (snowball). Next, we grouped all the codes into categories using ATLAS.ti network. We held weekly meetings with three researchers experienced in the domain and in qualitative research to discuss and adjust codes and categories until we reached agreement. The first author presented and described each category and the researchers went through the codes and the quotes backing them. We discussed the grouped categories, merged categories into higher-level themes, discussed the relationship between them, and adjusted codes and categories until we reached a consensus. This process took 36 weeks. For instance, we merged the codes "engineerto-engineer communication" and "timely user feedback" under the subcategory name "closer channels". When we found the same meaning for a concept that had been coded differently for more than one excerpt, we discussed it until we found the appropriate concept that represented all the coded excerpts. For instance, within the higher-level category "business advantage," we merged the subcategory, "avoiding technical debt" with "business dependency on OSS" as the need to avoid technical debt stems from the fact that the business depends on OSS. In addition to the motivations and contributions mentioned by interviewees, we also collected lessons learned that interviewees shared with us.
Member checking. After analyzing all interviews, we performed member checking to evaluate the validity of our findings by emailing our participants an editable document with our findings on company motivations and ways to contribute to OSS. Eight participants (P1, P2, P6, P7, P11-13, P20) provided their feedback. All eight participants verified our findings and did so via the Google document as well as an email response. They all agreed with our results, and P1 and P20 provided only rewording suggestions. P20 suggested rewording "joining" dependencies' leadership and governance to "aspiring to join" as they felt these roles need to be earned and voted in by the community (see section III-B2). P1 suggested rephrasing "gaining user fidelity" in the description of "building verifiable trust" to "gaining community trust" (see section III-A2) which to them then might result in user fidelity. We addressed the feedback from both participants by specifically rewording the respective parts of the results using their suggestions.
In this section, we describe our findings on what motivates companies to contribute to OSS and the different ways companies contribute to OSS.
According to our interviewees, company motivations to contribute to OSS fall under four top-level categories: Founder(s)' Vision, Reputation, Business Advantage, and Reciprocity (see Table II). We will discuss what we found for each of these categories in the following sections.
1) Founder(s)' Vision: Founder(s)' vision can stem from the founder(s)' ideology (P1, P2, P5, P7, P12) attributed to a "philosophical point of view at the very beginning (P2)," "the company culture (P5)" and to the fact that "all of the co-founders have a deep history in open source (P12)."
Still, the founder(s)' vision can also be attributed to the nature of the problem that the company is solving and its ties to OSS (P9, P7, P12). In some cases, the reason for founding the company is "to create an open source alternative to large enterprise resource planning software (P9)" which makes the ideology become part of the company's core.
Companies contribute to OSS because of their founder(s)' vision and/or because the problem they are solving is tied to OSS in its very essence.
2) Reputation: Our findings show that investing in OSS can be compared to public relations. For example, P4 compares the motivation to participate in OSS to that of "tak[ing] bits and pieces of the engine room into the open... by like normal PR [Public Relations] conference talks or they could do it like by open sourcing some of these things."
Our analysis revealed that companies focus on building reputation in different ways, which we categorized as follows: VISIBILITY, BUILDING VERIFIABLE TRUST, NETWORKING, ATTRACTING TALENT, and FOSTERING ADOPTION.
VISIBILITY. Our results show that participating in OSS brings visibility to companies of all sizes (P1, P2, P4-P9, P11, P13-P18). For instance, P2 explains "we wanted to be there [OSS project] in our case because this brings a lot of visibility." Companies join OSS to cement their name to a domain, expand their brand, or receive credit as the creator of a technology that is an industry standard.
For example, visibility helps companies signal an understanding of "what [is] actually going on inside (P4)" by showcasing their technical achievements (P1, P2, P4, P7), which helps cement the name of the company in their domain of expertise.
While this is the case for a number of companies, it does not end here. Companies can also leverage OSS to expand their brand beyond that for which they are known for (P4, P11). In particular, OSS can help companies expand their domain of expertise as explained by P11: "so people tend to think of [company name] as like the people who did [specific product]. And we've really moved beyond that."
Visibility can also hold different meanings to differentsized companies. For small companies, visibility can mean "becom[ing] more international (P6)." Whereas, for large technology companies, standardizing a piece of technology is the ultimate visibility goal (P3, P4, P18) because "if you actually came up with this standard, then you also get a lot of exposure (P4)." A good example of this is how "[for example] open-sourcing React has provided more value for Facebook than leaving it to themselves ever could have. Because (a) they get contributions now on that library; and (b) they get the sort of street credit of the founders of React (P3-who does not work at Facebook)."
BUILDING VERIFIABLE TRUST. In our context, building verifiable trust was described as gaining users' trust and/ or gaining the communities' trust. OSS by virtue of its open character, enables companies to openly contribute to a project. Therefore, these companies-especially startups-see OSS as a place where they can showcase their expertise to their users to gain trust (P1, P2, P5, P7, P15, P18). In fact, openly contributing to a project allows users to see the companies' contributions, their quality, and the rate at which they maintain the project. This differs from the proprietary software world, where users have to trust the company as to whether or not a product is being maintained. P15 explains these differences: "If we have a proprietary component..., you have to trust the vendor to know whether or not that's being maintained... Whereas if it's an open source project, I can watch the contribution history and I can know whether or not it's being
Gaining users' trust is particularly relevant when a company is at the forefront of a new technology or concept as explained by P2: "And they [users] say, well, I need someone, I need help with [name of concept]... So it's not that we know about [name of concept] it's that we are defining [name of concept] and for this, you can see that we have this pattern here about the maturity model." This suggests that companies that are working on, or defining a new concept in the open, are more likely to be trusted and potentially hired by users, as users can directly see their contributions and decide on its quality.
While giving your users "open source value (P5)" builds verifiable trust, making it long-lasting requires going the extra mile-listening to and embracing users' feedback: "and what happens when you say, I'm giving you this, and then you deliver this, your users and your customers trust you. And they are more likely to stay with you (P5)."
It is not only startups who seek to build trust, we also found that for large technology companies (P14, P15, P17, P18) "the biggest benefit from contributing is building trust (P18)." However, this trust is specifically directed towards signaling a sense of "accountability to communities (P17)" and showing that "you are willing to sidestep what you think is best and make sure that decision makings include the community (P17)." That built trust is what then enables companies "to be at the table (P18)" and participate in shaping the direction of the projects that they depend on.
In summary, different types of companies have different goals in creating trust; startups (mainly) contribute to OSS to gain users' trust and a user community, while larger technology companies contribute to OSS to gain the communities' trust.
NETWORKING. Participants described networking as socializing with the OSS community, other companies, and/or being in the same space as big-name companies. This allows companies to open the lines of communication for collaborations and partnerships. Our analysis shows that networking can look different depending on the company's goal. Most small companies found networking to be a driver for OSS participation. Some of these companies saw networking as an opportunity to socialize with peer companies and organizations and get to know people in the same space. For instance, P5 depicted networking as being in "that same ecosystem as these other like-minded organizations and practitioners (P5)" and P7 described networking as "socializing on that level of getting to know people, talk to people (P7)."
Other companies saw networking as a way to be in the same space as big-name companies (P1, P2, P6). For example, P6 describes networking for their company as a way to "bring more people to pay attention...and engage our brand to be related with huge companies (P6)." Other companies emphasized networking as a way to ease collaborations. For example, P8 mentioned how networking made "collaboration and partnerships become six orders of magnitude easier (P8)."
ATTRACTING TALENT. Our results show that companies participate in OSS to be seen as a "cool company" to work at, hire talents that are familiar with their tech stack, and bypass the interview and onboarding process. Participant P3 shared that companies that contribute to OSS "get viewed as, like a cooler place to work (P3)." P4 explains that "open sourcing is one of the ways that can make it [company] much more interesting for outside candidates (P4)" and signals to developers that, by joining such a company, they too can work on "cool technology" that has a lot of traction in the world (P3, P4, P8, P10, P13).
Our findings suggest that such reputation is highly beneficial for companies, which can then hire some great people since, as P10 points out, "people who code in public are better coders (P10)." Not only that, but companies also "get an entire class of engineers, who are now familiar with the tech stack that [company] uses (P4)" thus bypassing the interview and training process (P3, P4, P6, P10). This is particularly relevant for large technology companies that have open-sourced a technology that has now become the industry standard. For instance, P4 (who does not work at Google) mentioned that "any engineer that Google hires now will know Kubernetes."
FOSTERING ADOPTION in our context refers to a company's technology being widely adopted. Fostering adoption can be an integral part of building a company's reputation, so much so that the company "would rather focus on broader adoption than just you could say having our name on it (P4)."
For smaller companies, and as described by P2, "the best way to get your technology adopted is by open-sourcing this (P2)." Our results suggest that open-sourcing technology not only provides a readily available alternative to proprietary software but levels the playing field for startups to compete with larger companies.
For larger companies, fostering adoption can look like, as described by P11, "not locking them [enterprise customers] into a proprietary technology" and giving them the option to deploy the same solution using a different vendor. Our findings show, that while the open character of OSS helps foster adoption, some companies do not stop at the mere act of open-sourcing a product. Such companies "strategically give that [project] to a foundation to grow in public, so that more people use a technology (P10)" (P4, P11, P18). Our findings highlight that allowing a project to grow under neutral governing bodies gives additional impetus to wider adoption.
Contributing to OSS helps cement reputation. It gives visibility to smaller companies, allowing them to play in the same space as big-name companies. Larger companies benefit by developing deeper trust with the community signaling good citizenship, which in turn helps in recruiting.
3) Business Advantage: Over the years, companies' mindset has shifted in a way that now sees OSS as an ecosystem of business opportunities rather than a risky endeavor that commoditizes their products [1]: "There's a journey that companies seem to go on from like...thinking they don't use it, to realizing that they do...to a point where companies start realizing they need to give back...Ultimately, they know at this point, that a healthy ecosystem means good business for them, too (P12)."
The Business Advantage motivation is divided into four different subcategories. While companies are driven by a direct business need to contribute to OSS, other motivations (Closer channels, Coopetition, and Innovation) also play a role when it comes to companies' involvement in OSS. We detail these motivations in the next subsections.
BUSINESS DEPENDENCY ON OSS, refers to cases where throughout the companies' journey in OSS, their business becomes dependent on OSS "...to a point where companies start realizing they need to give back because they see that it actually helps them strategically (P12)."
Because the business depends on OSS projects, companies are motivated to contribute to keeping their dependencies healthy (P2-P5, P7, P9-P12, P14-P17). And just like an engine is critical to a car manufacturer: "if something happens to that engine...that works for Ford, right? Or, even worse, it makes it so that Ford can't use the engine the way they were using it before (P3)." Our results show that business dependency on OSS relates to ensuring that the OSS projects a company depends on remain healthy and that the leadership of these projects is not monopolized.
In fact, as described by P9, companies "want these projects [dependencies] to be healthy, alive and well maintained, and sustaining (P9)." To help with sustainability, companies contribute financially (P4) as well as upstream fixes (P17), which in return prevents carrying any technical debt internally (P11).
The technical soundness of a project dependency is not the only aspect of its health. In fact, P7 explains that "part of the healthiness of the project is also making sure that there are different ideas, opinions, and points of view. It's really easy to fall to a kind of monopolistic way on the open source projects (P7)." Our findings suggest that participating in governance and leadership (P3, P7, P15, P11) helps ensure a shared roadmap. Our findings also highlight that, a shared leadership flows both ways. It cannot just thrive on companies' readiness to get involved in governance roles, it also relies on the project having an open leadership and governance that welcomes participation. When the project in question is led by a company and this company realizes that "we cannot be the only ones backing this thing up (P7)," they start seeking "a backing up of different companies (P7)" which in turn becomes a stepping stone for coopetition, which we detail in the next section.
COOPETITION."Coopetition is the act of cooperation between competing companies" [47]. Our findings suggest that in OSS companies can work together on the hard technical problem they all face and compete on other features around the problem.
Our results suggest that coopetition yields more productivity where (1) workload is reduced and (2) products are of higher quality. The workload is reduced (P3, P8, P13-P15) as collaborating helps "do the hard work only once (P3)" and provides a form of resource sharing where "20 engineers will go further working on a project with 80 other engineers from four different companies (P3)."
We also found that the benefits of coopetition are not solely related to productivity. Such practice enables a bigger market share (P3, P15), which in return provides a much larger user base, one that is now empowered to migrate to different service providers that use the same core technology.
Still, according to P3 and P11, the products end up having higher quality because "pulling in people who work from other companies who will use things differently...they'll have different skills...they'll have different ways of thinking (P11)."
CLOSER CHANNELS in our context, relates to more direct communications, such as direct user feedback and, engineerto-engineer communication that promotes timely fixes. OSS is, in fact, a no-middleman land that provides closer channels and engineer-to-engineer communication (P5, P7, P13-P15, P17). The closer channels can take the form of raw users' feedback or customers' collaborations (P5, P14) that is then, as described by P5, "ingest[ed] back into our product delivery process."
Closer channels also mean bypassing the company-tocompany communication protocols and making engineerto-engineer communication the new norm (P13, P14). As described by P13, "it's fairly easy to waste a week on an incredibly dumb bug, that if you actually know everyone in the community... you're going to solve in like, 15 minutes (P13)."
INNOVATION. OSS is, by virtue of its character, a space for innovation that provides a business advantage and drives companies' participation (P11, P13, P16, P17, P19). Our findings suggest that innovation takes the form of more perspectives, more user stories, and diverse ideas that shape the company's products (P11, P17, P19). This innovation boost then makes it more likely "that it [product] will solve problems for more people and not just those 12 extremely bright people in the room (P17)."
For avant-garde companies, innovation can also take the form of getting familiar with projects that can be strategic in the future. For instance, P11 explains: "one of the things that we try to do is contribute to projects that we think are going to be strategic for [company name] in the future, but that aren't necessarily strategic for us right now (P11)."
Companies start to use OSS as a business advantage, but then their journey evolves to contributing to maintain the tech they are dependent on, and they stay since participating in OSS allows them to cooperate with their competition and innovate quicker.
Companies sometimes want to give back to the OSS ecosystem by contributing to the projects they use or other projects to share knowledge and experiences for the greater good of OSS (P2-P5, P7, P9-P12, P14-P17). Our findings suggest that reciprocity stems from the realization that companies have extensively used open source and need to give back. For instance, P7 shared "we took lots of things from open source." P9 explains that if "there's no reciprocity in some ways, even small, then you're missing the point entirely."
In contrast with the contribution driven by the business depending on OSS (see section III-A3), reciprocal contributions are ones that do not necessarily have a direct impact on the company but are rather, as P9 puts it, "the right thing to do."
Reciprocity can take the form of mentoring (P1, P2, P9, P12, P14, P17, P20), "sharing experiences between different groups (P7)" (P6, P13, P14) and advocating OSS by "spreading the word. And letting everybody know that contributing to open source is good. It's good for you and your company (P6)."
Companies want to reciprocate by contributing back to the projects they use and to other projects for the greater good of OSS.
The four motivation themes (RQ1) are what drive company contributions. To further understand the companies' engagement, in the following section, we link these motivations to the multi-faceted ways companies contribute to OSS, highlighting the entities that benefit from such involvement (see Figure 1).
When it comes to contributing to OSS, there is a number of ways to participate. We identified seven categories of contributions across companies: open sourcing TOOLS & PRODUCTS, DEVELOPERS' TIME, COMMUNITY RELATIONS' TIME, ADVOCACY & PROMOTION TIME, TIME ADDRESSING D&I, MENTORING TIME and FINANCIAL SUPPORT (see Figure 1). In our interviews, we could observe that companies contribute by open sourcing "platforms and frameworks (P11)," "tools (P1)," "internal code (P4)," "[product name] community editions (P11)," "SDKs (P12)" and "those things in between, those connectors (P7)." Contributing internal products to OSS is a win-win for both the companies and the OSS ecosystem.
Our results suggest that the internal tool, when opensourced, benefits the whole OSS ecosystem (see Figure 1) by enriching it with active projects that are backed up by one or more companies. For the company, the open-sourced tools provide a business advantage. For example, P7 describes such business advantage as "mak[ing] things easier for everyone using [company product]" and "connect[ing] services that [company] does."
Companies also reap the reputation benefit of open sourcing a novel solution, "a thing that does not exist" as P7 explains. The reputation benefit is magnified when such open-sourced tool is successful and widely adopted. For example, P4 explains "So [product name] is the thing that has the most success, and it's been adopted by a lot of companies... it's very impressive."
Our results also suggest that when the question becomes "how much adoption they can get on what they give away (P10)," companies strategically donate their projects to an OSS foundation, signaling neutral governance. This, in return, helps sustain OSS foundations and the OSS ecosystem as a whole (see Figure 1).
Still, when the donated project becomes an industry standard, the company starts to be seen as the leader in that space which increases the company's visibility and reputation. For instance, P4 explains "because if it [OSS project] becomes an industry standard, then you gain all of the benefits from being part of the standards. And if you actually came up with this standard, then you also get a lot of exposure."
When "the basis of everything is open source dependencies (P4)" contributing time is companies' first response. This takes the form of developers' time (P4, P6, P7-P20), community relations' time (P1, P5-P10, P11, P14, P15, P20), [time] on advocacy & promotion (P1, P5-P9, P11-P16), [time] addressing D&I (P5, P6, P13, P17, P19, P20) and [time] on mentoring (P1, P2, P9, P12, P14, P17, P20).
2) Developers' Time: Our results show that contributing time often starts in an informal manner, led by developers. For instance, P8 explains: "In the process of using, we tend to contribute to things we do use." More specifically, developers' time can take the form of ad hoc contributions such as fixing bugs (P9, P10, P12, P13) or adding a feature (P4, P8, P10, P11), where engineers "contribute where they see a need...[as a] scratching your own itch kind of thing (P4)".
When there are "300 things that depend on this specific dependency (P4)," contributing time in an ad hoc way is no longer a viable option. Companies step to the next level, investing developers' time in a more systematic way. This can take the form of assigning employees to work on an OSS dependency. For example, P11 shares how in their company there are "dozens of people who contribute to [dependency name] on a pretty regular basis." Similarly, P10 explains "I had about between 35 and 50, people whose full-time job was to work on open source projects that the company used."
With the time invested in OSS dependencies, companies aspire their "contributors to eventually try to move into maintainer positions, approver positions, leadership (P11)" (P3, P8, P13, P15) (see Figure 1). This is particularly relevant for critical dependencies where "getting elected to leadership positions in these communities is really important (P3)" and allows companies to "help shepherd these projects forward (P18)." Our results show that by investing developers' time in OSS dependencies, companies are sustaining the very projects that they depend on. This in turn (1) provides a business advantage and increases the company's reputation as one that "believe[s] there's a contribution wheel (P8)" and (2) benefits the OSS dependencies by maintaining a consistent contribution flow (see Figure 1).
3) Community Relations' Time: Participants revealed that companies realize that it is necessary to build a relationship with the community to work in line with OSS, as mentioned by P9: "there are no special benefits to things in the open...if you're not able to build in the community." This realization is at the core of companies investing time in community relations in addition to investing developers' time.
In this context, our results show that companies connect with OSS communities by holding open discussions (P5-P8, P15) which benefit both parties. P5 reported that, by doing this, "[the communities] learn more about what we're doing" and P15 complements it by saying that "[the company learns] what is it that people want." These discussions include "talking about problems (P5)," "answer[ing] questions (P6)," and being open to compromise by "explaining the benefits, try to reducing the risks or problems of that solution, and trying to reach a better one (P7)." Some companies (P1, P11, P20) go the extra mile to help foster community dynamics by organizing "contributor summits (P11)" and "events, where people [contributors] can come together (P20)." According to P20, this helps contributors to "meet each other."
Our findings suggest that contributing time to OSS is not only about contributing developers' time, but also spending time to nurture the community. P20 summarizes this as: "not just people spending time on code, but also people spending time on people" which further magnifies the benefit to the project community (see Figure 1).
4) Advocacy & Promotion Time: Our participants indicated that several OSS projects are tied to the software itself, making a lot of companies' contributions code related. But company participation does not stop at that. As our participants mentioned, they also "contribute to the overall ecosystem by doing advocacy work (P13)" and promote the prevalence of OSS (P5-P8, P11-P16).
According to our respondents, companies advocate for OSS by encouraging participation internally and externally. Internally, companies encourage their employees to contribute to a project of their choice in their free time and compensate such contribution. P5 explains: "we encouraged our staff to contribute to an open source project that mattered to them, and then submit it for reimbursement." Externally, not only do companies "bring to the community, the awareness of how much this [open source] is important (P6)" but they also promote OSS to other companies. This takes the form of leading by example and as P6 describes: "show to other companies in the ecosystem, that even if you're not a product company, you still may be able to invest money, time, people to contribute."
According to our participants, companies also encourage people to contribute by creating and sharing the resources to help them do so. During the interviews, they mentioned that the creation of resources takes the form of "blog posts (P6)" (P5, P7, P8, P16), "podcasts (P7)" (P5), "documentation (P15)" (P6-P9, P11), creating content for "open source month (P16)," creating and sharing survey results (P12), and participating in OSS working groups to codify best practices (P1, P18).
We found that, while companies advocate OSS through attending existing conferences and events (P5, P7-P9, P11-P14), some take advocacy a step further by launching their own conferences, events, or hackathons (P1, P6, P7, P9, P11, P12, P20). These events help attract new OSS players by, for example, launching hackathons to help initiate newcomers to "solving some social issues (P6)" or promoting an OSS technology by "starting a conference... talking about open sourcing cloud (P7)." 5) Time Addressing D&I: The participants (P5, P6, P13, P17, P19, P20) mentioned that their companies invest time and effort in addressing OSS Diversity and Inclusion (D&I) issues.
We could observe that the companies the interviewees work for contribute to the overall welfare of the OSS ecosystem (see Figure 1) by investing effort in "understanding how to be inclusive (P17)," understanding "diversity, equity inclusion initiatives (P20)" and understanding the ins and outs of the "code of conduct (P17)."
Once companies are well aware of the meaning and stakes of D&I, they start thinking about different perspectives: "how to have these sorts of conversations (P20)," "how to support someone who is in, you know, feeling threatened, or unwelcome (P17)" and "how to have recognition and allyship (P20)."
Only after building an understanding, do the companies start addressing D&I issues. For some companies, this takes the form of "investing in more programs and initiatives that we hope will help just to improve that aspect of things [D&I] For other companies, it is more specific, focusing on geolocation diversity in OSS by contributing to OSS in their country of origin (P6). P5 shared that their company contributes to D&I in OSS by partnering "with an organization that helps people learn how to develop. They come from an underserved population" and hiring "developers in countries that are less developed." 6) Mentoring Time: Companies contribute to OSS by participating in mentoring initiatives, whether it be in a formal or informal capacity. By doing so, companies help attract and retain different OSS players, from individuals to other companies. This, in return, benefits the whole OSS ecosystem and ensures the continuity of different mentoring programs (see Figure 1).
When it comes to informal mentoring, our findings show that companies give back to OSS by "mentoring people and always inviting others to contribute (P1)" (P14, P17). This is not only limited to individual contributors (e.g., newcomers) but also extends to helping companies that are not necessarily in the technical industry (e.g., "manufacturing organizations," "hospitals" (P14)). According to P14, this is important since these companies "are struggling trying to figure out how to do this [open source]."
Whereas in formal mentoring, some companies run internship programs both internally and externally such as Google Summer of Code or Google Season of Docs (a mentorship program that nurtures technical writers). Other companies mentor aspiring contributors through these very same mentorship programs (P2, P9, P12). For instance, P9 mentioned "working with specific programs, like Google Summer of Code programs."
At times, these programs can attract contributors and potential hires. For instance, P9's experience with mentorship programs resulted in "candidacies of folks that are willing to work with us." Or, in the case of P2, "some contributors coming from Google Summer of Code (P2)." 7) Financial Support: According to our interviewees, the companies participate in OSS by supporting one or multiple entities in the open source ecosystem. This can take the form of money set aside to support maintainers, foundations, patronage programs, and sponsoring events.
Our participants mentioned that companies participate in OSS financially "maintaining the health of overall open source ecosystems (P15)" by: contributing money to dependencies (P4, P8, P5), hosting patronage programs (P4, P5), supporting maintainers (P5, P12), sponsoring events (P5, P11, P12, P15), foundations (P11, P12, P15, P16) and mentorship programs (P12) (see Figure 1).
Similar to investing time on projects that companies depend on, companies are also "more likely to patron that project if we're using it (P5)." This takes the form of "set[ting] aside a certain amount (P5)" (P8) to help these projects "pay the bills, and just like dedicate time for coding (P4)." A more specific way that companies invest money in dependencies is by directly supporting the maintainers (P5, P12, P15) through, for instance, "hiring open source maintainers full time (P12)."
While providing direct financial support to OSS dependencies helps ensure the health and dependability of specific projects, companies also believe in supporting OSS foundations. For instance, P12 explained that "if we don't also think about supporting the foundations that provide a home for those projects, then we're not really going to solve the problem in its entirety." Our results show that companies "give a lot of money to foundations (P11)" (P12, P15) to "pay for infrastructure (P15)" and "to pay people to do all the things that they do...to support the open source projects (P11)." This opens the door for companies to be involved in "safety and security (P8)" conversations that are usually "exclusive to sponsored members (P8)."
Having described the motivations that lead companies to contribute to OSS and the different ways companies contribute to OSS, we now tie everything together, summarize our findings, and discuss lessons learned from our interviewees on OSS sportsmanship and being a good OSS citizen.
With 97% of companies using and relying on OSS [48], profit aside, companies' well-being is now tied to OSS' well-being where the investment in OSS is not just linked to a short-term profit, but rather an investment in the future. Companies invest in reciprocal contributions such as mentoring and advocacy and promotion, as well as addressing D&I issues, and go as far as archiving OSS code in the Arctic for future generations [49].
Companies are realizing that OSS is also about innovation, being part of the collective brain power, being a humble participant, and doing good for the community. Company participation in the OSS ecosystem is multi-faceted, beneficial to different entities (see Figure 1), and intertwined with different motivations (see Figure 2). Figure 2 depicts how the different types of company contributions (right-hand side) flow from the different motivations (left-hand side).
Increasing reputation by contributing to OSS was one of the most prevalent motivations. Companies increase their reputation not only by open-sourcing tools and products and investing their developers' time but also gain visibility by investing in non-code related activities (e.g., advocacy & promotion, mentoring).
While companies also contribute time (developers' and community relations), financial support, and software to maintain their business advantage, being a good OSS citizen is a pertinent driver for a variety of contributions. In fact, companies see the benefit in being a humble OSS participant where they do not just take from, but also give back to the community (see reciprocity, Figure 2). One key aspect was taking the time to address issues of Diversity and Inclusion (D&I). D&I is an important topic in open source yet a challenging one to address. When companies, that have the tools, resources, and experience, take the initiative to champion D&I in OSS, it is a significant step forward.
Being a good OSS citizen (see Table III) was seen as key to healthy OSS participation. One way to do so is by "contribut[ing] in the way that makes sense to the project, which may or may not always be, again, what the company would want (P20)." This entails placing the community's needs first and helping out with maintenance tasks.
In order to participate in an OSS ecosystem, an open source program in a company needs to be "able to speak multiple languages (P10)": risk management, engineering benefits, legal & compliance, and sponsorship, to be able to advocate OSS to "different levels of leadership. And showing how open source helps the business (P18)."
Finally, it is good to have an abandonware strategy. To create a sustainable project, companies need to open-source projects they use and care about internally. It is also important to have a contingency plan if the project does go out of sync internally by "transfer[ing] it to people who care about them [abandoned project] (P4)." Ensuring that the project does not become a company monopoly and has affiliation diversity is a good step in avoiding abandonment crisis.
Construct validity in qualitative research is related to the definition of constructs. One issue could arise from asking incorrect questions which we mitigated by piloting the interview script with the research team. Another issue pertains to the qualitative coding process. To mitigate this and avoid misinterpretation, we compared new emerging codes with the existing code set [50] and met frequently with the research team to discuss and clarify the codes. Additionally, the final code set was reviewed and finalized by the research team. To maximize credibility, we depict examples of evidence from observations to findings (see Table II).
Internal validity is related to capturing reality as closely as possible, which in our case is company motivations and contributions to OSS. The characteristics of our sample may have influenced our results. Half of our interviewees were part of the OSPO team within their company even though we did not push for such a split. The sizes of companies from which we interviewed participants were balanced (7 small, 1 medium, 9 large). We reached saturation after the 13 th interview. We also performed member checking to validate our constructs and received validation from all eight of our respondents.
Reliability refers to the extent that our results can be replicated. In short, it is difficult to replicate qualitative research since human behaviors, feelings, and perceptions change over time. However, we maintained consistency by constantly comparing the analysis with already existing codes and having weekly meetings to discuss and adjust codes and categories until we reached an agreement. We also performed member checking with eight participants who confirmed our interpretations. Finally, the results presented in this paper are related to Open Source participation, thus, we do not expect that all our findings will apply to other contexts.
Theoretical saturation. A potential threat to validity regards reaching theoretical saturation. The quality, rather than the size, of the sample of participants, is essential to increase our confidence in the findings. We interviewed 20 participants with different OSS-related roles. The 20 participants represented 17 companies of different sizes, from big technology companies, such as Microsoft and Google, to growing startups. We kept interviewing participants until no new codes emerged (13 interviews). Moreover, we conducted seven additional interviews and we did not find any new constructs. Although we cannot claim theoretical saturation, our sample helped us uncover a consistent and comprehensive account of the nature of company motivations to contribute to OSS and uncover the different forms of contribution. "You really have to think of the community first...we can't just bulldoze our way into getting what we want. We have to think about how what we want benefits the community" (P11) "We try to pick the things that would be having a bigger impact, bigger benefit for the whole of the community" (P7) Prevent maintainer burnout: Participate in maintenance tasks P7, P17, P18, P20 "Something needs to be shiny, for you to do it on your free time...companies that have the means to provide people to work on open source should be doing those things" (P7) Keep the contribution wheel spinning: Where you consume, contribute P4-P9, P12, P20 "Everyone should be contributing back, everyone should be making sure that they are not just the receiving end, they are receiving and producing end of the open source" (P7) "We generally believe there's a contribution wheel, so we owe, if we can upstream something or contribute back to a project we use, then we will" (P8) Prevent corporate abandonment: Open source projects that your team cares about P4, P17
"We do want to open source things that play into our own brand of the company...If it's something that is a core part of our teams' function, that's also great because it's something that they [we] will continue working on" (P4) Have an abandonware strategy: Transfer ownership of OSS projects that you internally moved away from but the community cares about P4, P6, P10, P15, P17 "If we stopped caring about them [open sourced projects that the company moved away from], then we should transfer it to people who care about them" (P4) "Eventually, you stop using the tool internally. But you know, have partners and customers that are using it...you can just kind of gradually pull all your engineers off of it, and let them have it. Um, you know, so this is what's called the abandonware strategy" (P15) Avoid company monopoly: Invite other companies in P3, P5, P7, P11, P15, P17 "Part of the healthiness of the project is also making sure that there are different ideas, opinions, and points of view, it's really easy to fall to a kind of monopolistic way" (P7) Be a polyglot in promoting OSS: Speak risk management, engineering benefits, legal & compliance, and sponsorship P7, P10, P14, P16-P19 "An interesting challenge for a successful open source program in a company is to be able to speak multiple languages, to speak to the risk legal people about risk strategy and, you know, compliance, to speak to the engineers about the benefit of being in the goodwill...and then to speak to the CFO, about, here's how we save money, here's how we make money" (P10)
A vast majority of prior literature in OSS has focused on individuals' experiences, from their motivations to participate [5]- [11], [51] to challenges faced when participating [6], [11], [19]- [21] and their perception of the OSS ecosystem [52]- [54].
Differences between individual and company motivations. Individuals' motivations to contribute to OSS has been extensively studied [5]- [11], with the literature review by Von Krogh et al. [7] being the most comprehensive and Gerosa et al. [5] work, which builds on [7] being the most recent.
From all the individual "intrinsic" motivations (Ideology, Altruism, Kindship, Fun), only Ideology has a company equivalent. Founder(s)' vision is an individual's Ideology turned corporate. Founder(s)' Vision as a motivator for participation was identified for small companies where the founder(s)' beliefs carried onto their company, defining its culture and DNA.
All individuals' "internalized extrinsic" motivations (Reciprocity, Reputation, Own use), except Learning, have their parallel in companies. Reciprocity is a common motivation for both individuals and companies, where both actors aim to give back to the community to reciprocate the benefits they got from OSS. Individuals participate in OSS to improve their own Reputation [5] and companies their brands. For an individual, gaining reputation can be a segue to getting hired by companies who themselves participate in OSS to attract talent. Companies benefit by hiring individuals who have been working on the project allowing companies to bypass recruitment and onboarding costs. Companies' business advantage maps to individual's own use but adds a more nuanced definition, since business advantage also includes drivers such as coopetition, having closer channels, and improved innovation. Individuals' "extrinsic motivation" (getting paid, career) do not directly map to companies. Companies do not get paid (or have contracts) to contribute to OSS, instead, they are the ones who may sponsor OSS projects. However, companies do indirectly profit from OSS participation as a result of an improved reputation and recruiting talented individuals.
Company participation in OSS. When it comes to companies adopting OSS processes, prior literature investigated innersource adoption [33], [35]- [39], and the motivations and challenges of applying it [34], [40], [55], [56]. Researchers also identified compliance best practices to help companies avoid legal/IP risks when using OSS [25]- [27]. OSS-related business models used by companies have been analyzed and compared as a way to understand the benefits and risks of each model [31], [32], [57]- [59]. Similarly, the literature showed how companies' usage of OSS relates to their business models [60]- [62]. Companies use OSS to increase their productivity and product quality [63]. This, in return, encourages companies that started with closed in-house software [64] or hardware [65] to open source them by following a specific pathway [66]- [69]. This results in more hybrid communities, where the intensity of companies' involvement helps understand their impact on volunteer communities [70]- [74].
Butler et al. [29] investigated the communication practices between companies and foundation-owned OSS projects (e.g., questions on a mailing list when reporting a bug) and the reason behind using public channels (e.g., mailing lists, changelogs). They identified the ways for companies to communicate with OSS projects and reasons for making it public. While Butler et al. focused on companies' communication practices when making a contribution, we focused on the multi-faceted ways companies contribute to OSS and identified all the kinds of ties that companies create with OSS and the motivations that lead the company to join OSS. Still, in their case study, Linaker and Regnell found 12 objectives for deciding what software to open source and when. While Linaker and Regnell [41] work focused on a specific type of contribution (open-sourcing software) we focused on a broader perspective, aiming to build a comprehensive motivation model that drives all kinds of contributions, their ties to the motivations and the entities that they benefit.
Our work complements this body of research by focusing on companies as OSS contributors instead of looking at individuals. We also identify the ways to engage and the reasons that lead companies to engage with OSS. We contributed a comprehensive model of company motivations to contribute to OSS beyond open-sourcing products. Indeed, we show that the ways to contribute are multi-faceted, are tied to the motivation of the companies, and may influence different entities.
Understanding the why and how companies contribute to OSS helps create a more comprehensive picture of the different players in the OSS ecosystem. Our results reveal that participating in OSS helps companies gain a business advantage and also grow their reputation. Reciprocating by giving back to the community is another key motivator. Smaller and larger companies often differ in why they participate in OSS. For example, when considering reputation as a motivation, smaller companies participated as it allowed them to gain reputation and to participate in the same space as big-name companies, whereas larger companies reported that OSS engagement signals good citizenship helping cement their reputation in the community.
The OSS renaissance is well underway. Open Source has its roots in the Free Software movement, which emerged as the antithesis of the commercial software movement. Without going into the discussion comparing these movements, it is possible to notice that OSS grew and expanded far beyond the weekend warriors. OSS is no longer produced and maintained by a dedicated few, but rather now is a space for different players of different capacities to thrive together-triggering the positive feedback loop of technology and business innovation.
While tech companies are invested in OSS now more than ever, non-tech and low-tech industries are also seeing the value of OSS (e.g., financial companies) and are establishing Open Source Program Offices (OSPOs) to systematize their contributions and policy implementations. Universities (e.g., John Hopkins, and Rochester Institute of Technology) are also participating by investing in OSPOs to centralize their OSS activities and simplify inter-university and company-university collaboration. Organizations such as UNICEF and the United Nations are looking to work with the OSS community to help reach their sustainable development goals [75], [76]. With a major part of national infrastructures being dependent on OSS (e.g., toll booths, hospitals), municipalities such as the City of Paris have their own OSPO and are contributing city-level digital solutions (e.g., Lutece [77], [78]) and it is only a matter of time before we start seeing nationwide efforts to invest in OSS and government OSPOs.
Implications for companies. Our findings can help nudge companies to contribute to OSS by understanding the benefits of OSS for their business, their branding, and the overall OSS ecosystem. Companies can then identify the motivations that are important to them and prioritize their contributions accordingly. Our mapping between the motivations, ways to contribute, and the benefiting entities, can help companies be more systematic about their OSS presence. Not only that, but the lessons learned from our company participants can serve as best practices for engaging with the OSS community; practices that help foster a high level of sportsmanship and a symbiotic OSS-company relationship. It is important for companies to recognize that they may be a crucial part of the sustainability of the project, as many interviewees mentioned reciprocity as a motivation to join. Reciprocity not only works as a "social responsibility" mechanism but as a way to guarantee that the project will be healthy, which in turn benefits the company. We expect that our results enlighten companies, motivating more organizations to see the benefits of engaging in OSS.
Implications for OSS projects. When company involvement in OSS is done right (Table III), it creates a symbiotic ecosystem where both parties mutually benefit. OSS projects can use our findings to help attract company participation and solicit contributions for their project needs.
By understanding companies' motivations, projects can provide an environment that is attractive to companies. For instance, reputation is a driver for companies to contribute, so if the project's community is "an abusive community, even companies don't want to get involved (P18)." This is an additional impetus for projects to foster a healthy, respectful community to attract company participation. To retain these companies, the project can provide open leadership and governance, one where everyone is "welcome to provide input on the governance and directions of the project (P9)." This can nudge companies to depend on and contribute to a project in a more systematic way, "know[ing] that they're contributing on a level playing field (P11)." Implications for researchers. Interventions designed to help sustain OSS need to take into account the different OSS players, their goals, and how they contribute. Our study complements the expansive literature on individuals' experiences in OSS by investigating companies as players. Researchers can investigate other OSS players (e.g., Universities, Government bodies), the interplay of these players, or the role OS S can play in facilitating collaboration between these parties. Looking at the other side, it is also important to understand the perspective of individual projects and contributors when they are a part of a company-owned or company-sponsored ecosystem, and how the motivations from the different sides align.
In conclusion, we hope our results encourage and provide guidance for current and new participants in the OSS ecosystemspecifically companies-to engage, collaborate in the open, create better software, and broaden the economic pie.
https://atlasti.com/