Adopting InnerSource

Chapter 4. Living in a BIOSphere at Robert Bosch

With Georg Grütter, Diogo Fregonese, and Jason Zink

• Year, place founded: 1886, Stuttgart, Germany

• Area(s) of business: Automotive, consumer goods, industry technology, energy and buildings

• Revenues: ca. €78.1 billion (2017)

• Offices: 440 subsidiaries in 60 countries, 125 R&D locations

• Number of employees worldwide: 402,000

• Number of software engineers: 20,000

• Year of InnerSource adoption: 2009

Robert Bosch GmbH is a large corporation active in areas ranging from mobility and industrial solutions to energy and building technology and consumer goods. Like any true startup, Bosch was founded in a garage; it all began in Stuttgart, Germany, in 1886. Since then, Bosch has grown to over 400,000 employees, called “associates,” who are distributed across 120 research and development offices spanning five continents. Due to the extremely distributed nature of the company, Bosch, like any other distributed organization, faces challenges in achieving collaboration across business units (often called “silos”), across different locations, and across different time zones. For such a large company to remain successful, it is essential to facilitate and improve collaboration. In pursuit of that goal, two associates in corporate research who were interested in free and Open Source software started playing with the idea that the Open Source development model could address many of the issues associated with distributed development. And so the seed for the Bosch Internal Open Source (BIOS) initiative was planted.

Why InnerSource

Being a large organization, the company owns many assets such as buildings and machines, but what is far more important is the knowledge base that the company has built up over the years: sharing this knowledge among its associates is key for the company to innovate and continue to prosper. Like any company, Bosch continuously aims to improve its processes to achieve better efficiency. The BIOS initiative fit well with that goal. The company saw a number of benefits of the Open Source development model, and hoped to achieve these through the BIOS initiative:

• InnerSource helps to increase the efficiency of distributed software development, by fostering collaboration across different business units, and to increase knowledge sharing.

• InnerSource offers an internal training ground for staff to learn how to participate in Open Source communities, which is becoming important for any software organization.

• InnerSource as a modern approach to software development helps to attract talented software developers. Bosch is moving to become an Internet of Things company, and as such it depends on being able to hire new developers.

Further benefits were discovered as the BIOS project succeeded. In particular, we found that developers were more innovative because they could develop software for other teams without requiring approval and resources from those teams’ managers.

Starting the BIOS Journey

Like many other large companies that are distributed across the globe, Bosch has experienced the common challenges caused by geographic and time distances, which can make software development processes quite inefficient. The stories of several hugely successful Open Source projects—the Linux kernel being a prime example—which mastered the challenge of distribution did not go unnoticed. These successes inspired a few associates to study how Bosch could benefit from the lessons learned in Open Source software development, not just internally but with the ultimate goal of making Bosch a successful player in the Open Source arena itself. At the time, Bosch didn’t have any expertise or experience with engaging in existing Open Source projects and communities, or starting new ones. Instead, they started a number of other Open Source–inspired initiatives, including a wiki to share knowledge, an issue tracker, and an internal research project which, among other things, explored how software development within Bosch could benefit from adopting Open Source development practices: the Bosch Internal Open Source (BIOS) initiative. The prospect of increasing the efficiency of distributed software development was what convinced management to support this initiative.

The BIOS initiative was started in 2009 and has evolved since then. We can identify roughly two main phases.

Establishing and Growing the BIOSphere

The first phase started with the official sponsorship of the BIOS initiative by the company’s executive management in 2009. In this phase, the BIOS initiative was positioned as an “experiment,” and was put under the stewardship of Corporate Research, who were in charge of the overall research project. As such, they managed the budget and bore final responsibility. The initial experiment started very small, with the specific goal to evaluate whether the application of the Open Source development paradigm could help overcome the challenges of distributed development, and in particular, help to overcome any bottlenecks to efficiency. For the first years, up to the end of 2015, “entry” of new communities was guarded by a formal review committee. The number of communities it could approve was limited by the committee’s budget for funding community leaders and contributors.

This first experiment booked a number of successes (which we will describe), eventually leading to an extension in 2012 that provided another three years of funding for the BIOS initiative under the same conditions. The original question as to whether Open Source development practices could be leveraged within Bosch was answered positively, so the program left the research stage. The initiative’s stewardship changed from Corporate Research to the Corporate Engineering Department as a result.

BIOS Values

The BIOS initiative was originally set up as a bubble within the company, a “safe space” in which to apply and experiment with the Open Source working model. We called this safe space the “BIOSphere.” Rather than focusing on Open Source tools and technologies, the main focus was on re-creating the culture that underpins Open Source development. Within BIOS, the culture is based on five values:

Openness

We make it easy for any associate to join and contribute to a BIOS community. We lower the barriers for entry into BIOS communities as much as we can.

Transparency

We aim to be radically transparent and share our work products, our communication, and our decision making with all associates in the company. So, while openness is about getting people in, transparency is about being sure that all product and process artifacts are accessible.

Voluntariness

The decision to join and contribute to a BIOS community is left to each associate. Associates should work within BIOS because they are intrinsically motivated, not because their manager told them so.

Self-determination

Associates are free to choose what to work on, which tools and processes to use, and when they work on the projects.

Meritocracy

Power is vested in BIOS project members based solely on their merits, that is, based on the quality and quantity of contributions made.

These values stood in stark contrast with how Bosch ran other projects at the time. It was quite obvious to us that this would engender quite a bit of friction and risk undermining the “safe space.” In order to protect the bubble, we created a protective layer around it by introducing two mechanisms that were instrumental for the success that BIOS eventually enjoyed: the BIOS Review Committee and the BIOS Governance Office (BGO).

BIOS Review Committee

The first mechanism was what we called the Review Committee, which comprised vice presidents of the engineering business units. This was the interface between the pilot BIOS communities and management. It served as a gatekeeper to the BIOSphere in terms of which communities would be a part of it, thereby giving managers a constructive way to influence what would happen within the bubble while avoiding micromanagement. The Review Committee also made management support for the BIOS initiative official and thereby provided the necessary executive air cover.

Any Bosch associate was able to propose a new community for the BIOSphere. The Review Committee would meet twice per year. One of these meetings was used to review and approve (or decline) new community proposals; the other meeting would be used solely to review active communities. Proposed communities are evaluated based on a set of clearly defined criteria—the “BIOSness criteria”—so as to ensure that accepted communities contribute to the aim of the BIOS initiative:

• A proposed community must have a clearly defined vision and mission in line with the overall mission of the BIOS initiative. This served two main purposes: first, it ensured that the community goals were aligned with Bosch’s overall goals and strategy, and second, it ensured that the BIOSphere would be used only for communities that helped the BIOS initiative in its initial mission. (The initial mission was to evaluate the suitability and effectiveness of Open Source practices in the confines of the corporation; the mission evolved as the benefits of InnerSource became apparent.) We especially examined whether the community’s topic was attractive for a large enough group of associates to increase the chances of actually receiving voluntary contributions.

• The community must have a full-time community leader so as to ensure that there was someone who would try to build a community and inspire others in the company to join. Having a clearly identified community leader would also help ensure the community would be viable and prevent hosting “zombie” communities that would simply take up resources but not contribute to the goals of BIOS.

• The proposed community must adhere to the five BIOS values described earlier.

• The community must be geographically distributed. Because the remit of the BIOS initiative was to evaluate how the Open Source development paradigm could help improve collaboration across locations, it was important to ensure that the space created for this purpose would be used with that aim in mind, rather than providing a playground for just any project.

• The community must be cross-departmental. Similar to the previous criterion, the aim of BIOS was to stimulate cross-departmental collaboration, and thus BIOSphere resources should be reserved for those communities that aim to achieve that.

The Review Committee also had the option to retire (or “sunset”) a community, but that happened only once during the six-year period that the Review Committee was active, and in that particular case, the community itself chose to retire due to a lack of participation.

BIOS Governance Office

The second mechanism to keep BIOS on track was the BIOS Governance Office (BGO), which provided a legal framework within the organization and developed the ground rules for the BIOSphere, including the entry criteria discussed earlier. The BGO was responsible for the BIOS license, procurement of hardware and software, and contractings between communities and contributors wherever they were needed. The BGO also tackled organizational tasks, such as organization of Review Committee meetings, coordinating the overall communication between the various stakeholders (such as Bosch management and the community’s leaders and developers), managing budgets, and documenting and maintaining a body of knowledge about BIOS. Finally, the BGO supported developers who were applying for a new community by helping them develop a community vision that was aligned with the BIOSness criteria and, once approved, supporting them with building and evolving their respective communities.

The initiative had an annual budget of about 1.5 million euro, which was used to fund community leaders and contracted contributors. A small portion of it was used to buy hardware and software, specifically when it was not in the standard product catalog at the time. Such technology included development boards such as Raspberry Pis or BeagleBones, smartphones, smartwatches, and other gadgets. Because this was completely within control of the BIOSphere and purchases wouldn’t have to go through standard processes, such purchases could be done much more quickly. All BGO tasks were handled by only a single person. Thanks to the BGO, the administrative overhead for developers was minimal, which allowed them to focus their limited time on development. There is a parallel here to Open Source projects; while many community members focus on contributing code, it is not uncommon for some members to support the community by looking after administrative work.

Attracting Contributors

The vast majority of developers working within business units are allocated to one or more projects, and as such their time is completely planned, with virtually no “slack time.” In other words, normal developers tend not to have any time to do anything else beyond the work assigned by their managers within their teams. This also means that a proposed community, which would necessarily include a community leader (as one of the acceptance criteria) and perhaps also some developers from one or more business units, could find it difficult to get developers committed. The BIOS Governance Office could use its funding to reimburse a business unit for the engineer’s time, effectively buying out the developer for 10, 20, and in some cases even 50 percent of their time. BIOS community leaders were funded 100 percent by the BGO. Because the BIOS budget was corporate money rather than money from a specific business unit, those bought-out developers would enjoy a great deal of independence—in other words, those developers would not be expected to serve their business unit, and instead would have complete freedom to self-direct.

Any developer time buyout and reimbursement arrangement with a business unit was supported by a formal contract. Formal contracts are a traditional mechanism for organizations that managers recognize, so this facilitated a smooth process for managers to sign off on those. While reimbursement of developer time can help convince a manager to let an engineer spend time in the BIOSphere, a more compelling reason is if the business unit stands to benefit from the community work directly—for example, by being able to improve their internal processes or productize it.

All communities in the BIOSphere publish their work products under a specialized BIOS license, which protects all BIOSphere developers from any liability claims. The BIOS License (BIOSL) was created by the BGO based on existing Open Source licenses, and later improved by the central legal department. The license clarifies what developers and business units can do with the software, what they cannot do, and what they must do. For example, it prescribes that all assets created by any BIOS community must be available to all business units within our company. This means that a business unit that did not contribute in any way to a BIOS community would still be able to “free-ride” and incorporate its assets into their products. Ultimately, a business unit is responsible for ensuring compliance, such as ensuring that intellectual property is protected or that OSS license obligations are met, thereby relieving the communities of this responsibility. This means, for example, that business units cannot publish any source code from BIOS communities outside of Bosch, and business units remain liable for their products (which includes any warranty claims), even if the product uses any BIOS assets. In effect, business units must follow the same procedures with BIOS software as they would for Open Source software components in such areas as licensing and accounting.

From BIOS to Social Coding

After the first six years, the BIOS initiative saw a number of changes, which we characterize as Phase 2. Before 2016, the BIOSphere was guarded by the Review Committee mentioned earlier and facilitated and funded through the BGO. At the end of 2015, a consensus formed in top-level management that BIOS was mature enough to continue without both, so they decided to dissolve both the Review Committee and the BGO. Effectively, this removed the “protective layer” around the BIOSphere. With the closing of the BGO, we also lost funding for the community leaders, who subsequently were not able to continue dedicating themselves completely to their respective communities anymore. On the bright side, without the Review Committee, everybody could now start a BIOS community without having to wait for and go through a formal vetting process.

Having experienced the value that BIOS brought to the organization firsthand and fearing that the lack of organizational support for BIOS would endanger what we had built, a group of former BIOS community leaders and the BIOS governance officer started a new bottom-up initiative to further drive the adoption of BIOS. After much lobbying with top-level management we eventually established the Social Coding initiative. The goals of this initiative are:

Changing the norm

Drive the cultural change toward a more open organization in which the BIOS way of working will become the norm, rather than the exception.

Establishing infrastructure

Provide a platform for our coders to collaborate across divisional boundaries.

Offering organizational support

Help the organization use that platform and implement the new culture.

BIOS did not prescribe the use of any specific tools, following the principle of self-determination, but after a couple of years a consensus emerged that using a single collaboration platform would be beneficial. We started to use Stash and eventually migrated to Bitbucket, when the Social Coding initiative was established. Our main reason for using Stash and later Bitbucket was that Bosch had already heavily invested in the Atlassian tools suite.

Access to the platform was provided completely free of charge to any individual and department, unlike the standard infrastructure for which departments were charged monthly fees. By subsidizing the platform, we made sure that people who wanted to start a new community could do so at no cost. This meant that developers didn’t have to ask their department managers for permission to get involved.

To convince business units that are hesitant to “open up,” and to build a critical mass of developers, the platform now also allows “traditional” projects that were not open to the rest of the company—that is, non-InnerSource projects. Ultimately, we hope that those projects will convert to a true BIOS community by way of exposure to the new culture and by promoting existing BIOS communities as the “Gold Standard” and a role model for collaboration within Bosch.

Finally, and unlike many other companies, we didn’t require projects or communities to use our platform. Instead, we opted to make it an offer to everybody to use at their discretion, because we think this is more in line with our values, especially self-determination.

Sustaining Social Coding

The year 2018 saw another change in the funding of the initiative. Both the BIOS and Social Coding initiatives were funded with corporate money, which kept the accounting overhead to a minimum. Beginning in 2018, the Social Coding initiative has to finance itself with business unit money. While we were successful in collecting enough funding for the Social Coding team by way of an internal crowdfunding campaign, the effort for running that campaign, and subsequently for the necessary internal accounting, turned out to be prohibitively high. This is why we decided to take the idea of community one step further, and push for replacing the central Social Coding team with a decentralized community of Social Coding advocates beginning in 2019. Every business unit that would like to hold a stake in (and influence the evolution of) Social Coding and the accompanying infrastructure will be encouraged to provide capacity to at least one Social Coding advocate to represent the business unit in the community. It remains to be seen whether that approach to sustaining Social Coding will be successful.

Success Stories

BIOS and Social Coding led to a number of success stories. Here we describe some of these.

Widespread Adoption

Within the time span of the first experiment and its extension (a total of six years), 11 communities were accepted within the BIOSphere, involving a total of 300 developers from 15 business units in 11 countries across three continents. As the BIOS initiative evolved into the Social Coding initiative, the number of users on our platform has increased from 300 to almost 8,000 in the past two years and is continuing to grow constantly. We now facilitate collaboration of developers in more than 150 business units in 28 countries. The total number of projects grew to over 600, almost one third of which are organized as BIOS communities—that is, they are accessible by all Bosch associates. The remaining two thirds of projects on the platform, however, are closed projects, accessible only by a specific business unit or project. Despite this, many business units that are running closed projects have adopted elements of the Open Source style working models that Social Coding promotes for their product development as well. Interestingly, the ratio of open versus closed projects on our platform approaches that of GitHub.

Diverse Ecosystem of Communities

The topics of communities varies greatly, ranging from production and engineering tools, to technology and product demonstrators, libraries and APIs, and new products. We develop throwaway prototypes and demonstrators very quickly, but also mission-critical software running in our production plants. Some examples include:

Teleheater

An app for remotely controlling our HVAC systems, including the required infrastructure and embedded hardware. The system was presented as the flagship innovation at a major trade fair in 2011 and won an international design award for its interaction concept as well as an internal innovation award.

COM4T IP-Stack

A networking stack for resource-constrained devices, allowing them to take part in the Internet of Things without requiring much of the devices’ very precious and limited RAM. It is now used in a variety of IoT-related products—for example, the XDK Cross Domain Development Kit (xdk.io).

Tram Collision Avoidance

A visualization for a collision avoidance system for trams building on Bosch radar and optical sensors used in the automotive domain and an API for accessing the CAN bus developed in the BIOSphere. The BIOS team rapidly developed the visualization in cooperation with the potential customer and was instrumental in eventually acquiring new business. The system is now being field-tested in many European cities by public transport authorities.

This type of innovation happened both in existing business units and in completely new areas that emerged spontaneously.

Improved Collaboration

At a technical level, the collaborations across different business units became smooth and frictionless. Previously existing technical barriers for this kind of collaboration were effectively removed.

BIOS communities were given complete autonomy with respect to how they performed their work. Initially, there was a general expectation that this would lead to a lack of formal planning and quality control, neglect of corporate processes, and a plethora of non-standardized toolsets in the BIOSphere which would ultimately lead to chaos. However, in fact the opposite happened: a strong culture of craftsmanship and apprenticeship emerged. BIOS now has a well-deserved reputation of producing high-quality software and many business units have modeled aspects of their development processes after processes common in BIOS projects.

Personal Growth

The BIOS initiative became a great success, not only for the involved business units, but also for the associates. Many associates reported they felt their personal growth accelerated dramatically through their BIOS activities. These associates consistently reported that the BIOS work in turn led to increased happiness and work satisfaction. The BIOSphere and its communities very clearly radiated a “coolness” factor, which attracted many excellent developers. Engineers were able to find a new purpose and renew the enthusiasm that they might have lost over the years.

Increased Productivity

The level of engagement and motivation of developers in BIOS communities were extraordinarily high. It is therefore not surprising that the productivity that BIOS communities achieved was far above average. The reduced administration work offered to developers by the BGO, and the permission to let developers adopt only processes that they felt were necessary and helpful, also contributed to that increase in productivity. As a result, a number of small teams and communities had a very disproportionate impact on the organization.

Alignment with Business

A key issue in adopting InnerSource is the potential disconnect between developer self-determination on the one hand and aligning work with the company’s business objectives on the other. Interestingly, we found that this alignment happened quite naturally. Many BIOS projects have made direct or indirect contributions to reaching Bosch business objectives and this was recognized by our management. We also discovered that the vast majority of BIOS developers consider it to be the ultimate reward for their engagement if their software is used in a product or brings value to fellow associates by making their daily work simpler, more enjoyable, or more efficient.

Success Factors

In hindsight, we can identify a number of factors that led to the success of the BIOS initiative.

The timing of the BIOS initiative was good, because our management wanted to develop a strategy for Open Source around the time the BIOS initiative started. This was a major success factor for rallying support for the BIOS initiative and getting it off the ground. Although InnerSource is not the same as Open Source, InnerSource can help to create a culture that values transparency and meritocracy and thus help the organization to work with communities of developers. Furthermore, the BIOS initiative addressed an urgent need of the organization: to improve the efficiency of distributed software development in general.

BIOS started as an experiment with low expectations—and perhaps most importantly, it was declared as an experiment. Managers were more likely to sign off on it because it was time-limited and because declaring it as an experiment clearly communicated that failure was an acceptable option. For executive managers, such an experiment with a budget for a fixed time period is simply an investment with a risk. Without such limitations, managers are likely more wary that such an experiment might spiral out of control.

The experiment was completely funded by corporate management rather than a specific business unit. This helped to give the initiative the autonomy needed to ensure that it could pursue a direction that wouldn’t necessarily be dominated by any one business unit. By minimizing the influence of individual business units, the corporate-level initiative avoided political or budget-related conflicts that might hamper any cross-business unit collaborations. This is one of the key things that BIOS aimed to improve.

A second success factor was the focus on attracting self-selected and motivated “volunteers.” This completely aligns with one of the values we defined previously: voluntariness. Perhaps most importantly (and most impressive), many contributors would contribute to these projects in addition to their normal, daily workload. This self-selection of highly motivated people naturally meant that their motivation was intrinsic and that they were highly enthusiastic. This in turn acted as a natural filter and allowed the recruitment of the most driven associates who were passionate about what they did.

The support rendered by the BGO was an important success factor as well. It unburdened the developers in the BIOSphere of the many administrative processes common in large organizations and thus allowed them to focus entirely on delivering their best work and make the most of the sometimes limited amount of time they had. More importantly, the BGO successfully managed to maintain the protective layer around the BIOSphere as a whole. As a result, the developers in the BIOSphere were able to implement the five values to the fullest extent, which contributed greatly to the extraordinarily high level of motivation and thus productivity we observed.

Another major success factor was the choice of leaders: the BIOS communities were led by enthusiastic and competent community leaders that were able to dedicate 100 percent of their time to establish, promote, and grow their respective communities. They were instrumental in attracting and retaining contributors, which is probably more difficult than in Open Source communities where the number of potential contributors is much higher to begin with. The importance of the 100 percent community leader became even more apparent when we lost the capability to fund them in 2016 and the number of contributions and overall productivity of their communities decreased significantly as a result.

Finally, giving the communities in the BIOSphere the autonomy to decide themselves what to work on and which tools and processes to use contributed to the success of the BIOS initiative. By using a dogfooding approach (i.e., the developers who created processes also used them), only those processes that really helped the community were implemented and continuously refined; everything else went out of the window. Communities also had and made use of the freedom to quickly act when a project opportunity presented itself. Chance favors the prepared.

Challenges

The BIOS initiative has been very successful, overall, but there were certainly also some challenges, some of which we have not yet been able to meet.

One of the primary challenges is to grow communities. It can be really hard to attract contributors from throughout the company when people are focused on their specific business units, and when their time is completely allocated to specific projects owned by that business unit.

We also found that getting buy-in and commitment from management, especially of middle management, was quite challenging. This is because many of the benefits of InnerSource—productivity as a result of developer happiness, employee retention, and personal growth, to name a few—are hard to quantify. Another, more systemic reason for the lack of buy-in is that mid-level managers simply have different goals and motivations, as they are responsible for only a slice of the company. Even if they buy into the goal of the whole organization, supporting cross-team collaboration and allowing their subordinates to contribute to business outside of their area of responsibility may not be in their interest, because offering developer time to outside projects can incur a cost to their own business unit’s performance.

In terms of developer career path, one shortcoming of the BIOS initiative was that it was not coordinated with Human Resources. As a consequence, work performed within this initiative was often not rewarded in terms of advancing developers’ careers. Time spent voluntarily on BIOS work was sometimes time not spent on reaching the goals set by their organization. Although several individuals have been able to leverage the increased visibility they enjoyed, there was no formal promotion track that was facilitated by HR policy.

We found it very challenging initially to get internal publicity for BIOS. Even after the first six years, very few associates overall were familiar with the BIOS initiative. This challenge later changed to a more interesting issue of brand dilution. The success stories that we shared within the company inadvertently led other teams to use the brand BIOS to suggest they were part of the success, without them actually practicing the values that BIOS advocates. This is not an uncommon phenomenon, and in a conflicted way, an indicator of success: clearly, our InnerSource initiative is perceived as successful, and others want to share in this success. However, if teams simply identify themselves as part of the success without actually practicing it, the BIOS brand is diluted. Worse, business units may simply claim they “do InnerSource” but not make the effort that is required.

Although cross-company collaboration improved, we still faced a cultural divide between BIOS and business units that could cause some friction. In particular, one of the BIOS values is meritocracy, and for that to work well, it is very important to acknowledge high-quality contributions, because such credit is the “currency” for BIOS developers. At the outset, most business units were not familiar with this culture. And so when business units simply use BIOS assets to develop their products (and they are free to do so, as mentioned earlier), and don’t give credit where credit is due, this leads to feelings of betrayal among BIOS developers because their work is taken without any recognition. Another facet of this challenge is that it was at times hard to sell work on APIs and libraries, work that many software developers gravitate to naturally. The reason for this is that API developers are usually so far removed from where money is actually made in the company that the value can be hard to quantify, and therefore, hard to justify. This is exacerbated by the fact that few managers have experience in software development that would allow them to appreciate the importance of high-quality APIs.

In addition to the challenges just described, a number of other issues emerged related to laws and regulations. First, we had to engage with the legal department and develop a license for all assets that would be created within the BIOSphere. This wasn’t straightforward because of the sheer number of legal entities and countries involved. For the same reason, we also had to consider things such as export control: if code is being shared across legal entities in different countries, you must observe export control regulations, such as US laws controlling the export of strong encryption algorithms. Furthermore, we had to consider the federal tax authorities and address the problem of transfer pricing.

A concern that should not be taken lightly is the potential misuse of an increased level of transparency regarding individual developer’s activities and performance that InnerSource offers. In Germany, for example, the Workers’ Council serves as an “ombudsman” to ensure that such transparency is not abused for inappropriate performance evaluations.

Lessons Learned

Based on our experiences with setting up BIOS and the BIOSphere, we’ve learned a number of lessons that could be useful for other organizations that aim to set up an InnerSource initiative:

Ensure good stewardship

Our initial steward, Corporate Research, was a perfect fit for what we were trying to do. They had a full understanding of the culture change that we were trying to make, and they shared our enthusiasm for software and Open Source. Furthermore, we had sufficient “executive air cover” through the Review Committee. Such support from a high level within the organization was very important for getting things done.

Create a compelling business case

One problem for any centrally funded change initiative is sustainability. While the BIOS initiative initially received corporate funding, over time we were expected to become self-sustaining, which meant that we would somehow have to get funding support from the various business units. However, creating a compelling business case to those business units that would convince them to give us a portion of their budget is really challenging.

Start measuring, but with care

While any change initiative will get a bit of slack, after a while, managers will expect some evidence that whatever improvements are promised are also actually achieved. Measuring participation and progress is therefore an important thing to do. We didn’t do metrics from the outset for a number of reasons: the risk of metrics being gamed, the lack of control about interpretation of measurements and also the difficulty to objectively quantify the less tangible, and in our opinion most important, value contributions we made. However, we eventually arrived at the conclusion that one should try and quantify the less tangible value contributions, such as employee retention or increased learning from the beginning, possibly based on some broad assumptions, rather than giving up on quantifying those value contributions at all.

Think about marketing

We found that getting a clear message out to all business units in a large organization such as Bosch can be very challenging. Even after several years of advocacy, some associates still aren’t familiar with BIOS. At the same time, one mistake we made was that we muddied the water ourselves by having too much branding. While BIOS and the BIOSphere were very useful (and playful) terms that had real meaning within Bosch, we caused confusion by introducing the term Social Coding, which referred to the second phase of the BIOS initiative.

Plan for early decentralization

We have learned the hard way that it is unlikely that a central team driving change initiatives such as BIOS and Social Coding will be funded for extended periods of time, regardless of whether they have fully realized their goals. Changing the culture of an organization, especially a large one like ours, will almost certainly take much longer than management is willing to fund the change initiative. Therefore, rather than relying on a continuously funded central team, we think it makes sense to spend significant effort early on to build up and empower a community in the organization that will continue to drive the initiatives even if the central team eventually ceases to exist. The bottom-up nature of both the BIOS and the Social Coding initiatives is now proving advantageous with respect to the community building effort. We are convinced that setting up the BIOSphere as a “safe space” in the organization was instrumental in getting the initiative off the ground. However, it is easy to be lulled into a false sense of security regarding the longevity of this bubble. We feel it is important to communicate early on that a “safe space” like our initial BIOSphere can be only a temporary solution that eventually needs to be replaced with something else to help sustain InnerSource in the long run.

Seek alternative funding models

While we have been successful in establishing stable and long-term funding for our collaboration infrastructure, we have been less successful in doing so for BIOS communities. Remember that we used BGO funding for contracting community leaders and contributors and that it was a key factor in growing and sustaining our InnerSource communities. Getting business units to provide funding on the other hand, especially for permissionless innovation projects where the benefit to the business unit is not necessarily obvious, turned out to be hard, even if the overall benefit for Bosch was apparent. At the time, we decided to make our collaboration platform available for free to both open and closed projects, mostly for the sake of organizational simplicity and speeding up the decision process. In retrospect, it would probably have been better if we asked the owners of closed projects to pay a small fee for using the platform, which we could have then used to fund the BIOS communities.

Conclusion

At the time of writing, we are nine years into our InnerSource journey. We have seen tremendous successes and have also encountered major challenges and frustrations. But most of all, we experienced firsthand how InnerSource can truly change the way we work for the better. Today, we can observe promising signs that our culture is indeed changing in the direction we envisioned at the beginning. We are encountering more and more projects at Bosch that “get” the BIOS idea and develop in the open from the very beginning.

For many of us, our time working in the BIOSphere and leading the first BIOS communities was the most productive, the most fun, and quite simply the best time in our careers up to now. At this point, we can’t imagine working in any other way and are convinced that InnerSource, similar to Open Source, will continue to make a difference and is ultimately here to stay.

Acknowledgments

We’d like to express our gratitude to Stefan Ferber and Hans Malte Kern for lobbying for, and introducing, InnerSource at Bosch. Thanks to Gerd Zanker and Robert Hansel for their pivotal roles in BIOS and Social Coding.