5.1 Opening up
The process of opening up for external collaboration and maturing as an open source organization, can be compared to moving from a closed innovation model to an OI model (Chesbrough et al.
2006). The data suggest that the trigger for this process was a paradigm shift around 2010 when Sony Mobile moved from the Symbian platform (developed in a joint venture), to Google’s open source Android platform in their products (West and Wood
2013). Switching to Android correlates to a general shift in the development environment, moving from Windows to Linux. This concerned the tools used in the product development as well. A transition was made from existing proprietary solutions, e.g. the build-server Electric commander, to the tools used by Google in their Android development, e.g. GIT and Gerrit. As stated by I2,
“… suddenly we were almost running pretty much everything, at least anything that touches our phone development, we were running on Linux and open source”. This was not a conscious decision from management but rather something that grew bottom-up from the engineers. The engineers further felt the need for easing off the old and complex chain of integration and building process.
At the same time, a conscious decision was made regarding to what extent Sony Mobile should invest in the open source tool chain. As stated by I5,
“… not only should [the tool chain] be based on OSS, but we should behave like an active committer in the ways we can control, understand and even steer it up to the way we want to have it”. The biggest hurdle concerned the notion of giving away internally developed intellectual property rights, which could represent competitive advantage. The legal department needed some time to understanding the benefits and license aspects, which caused the initial contribution process to be extra troublesome. In this case, Sony Mobile benefited from having an internal champion and OSS evangelist (I5). He helped to drive the initiative from the management side, explained the issues and clarified concerns from different functions and levels inside Sony Mobile. Another success factor was the creation of an OSS review board, which included different stakeholders such as legal department representatives, User Experience (UX) design, product development and product owners. This allowed for management, legal, and technology representatives to meet and discuss OSS related issues. The OSS contribution process now includes submitting a form for review, which promotes it further after successful initial screening. Next, the OSS review board gives it a go or no-go decision. As this would prove bureaucratic if it would be needed for each and every contribution to an OSS community, frame-agreements are created for open source projects with a high-intensity involvement, e.g. Jenkins and Gerrit. This creates a simplified and more sustainable process allowing for a day to day interaction between developers in the Tools department and the communities surrounding Jenkins and Gerrit. Sony Mobile’s involvement in OSS communities is in-line with the findings of governance in OSS communities by Jensen and Scacchi (
2010).
5.2 Determinants of openness
Several factors interplay in the decision process of whether or not a feature or a new project should be made open. Jenkins and Gerrit are neither seen as a part of Sony Mobile’s competitive advantage nor as a source of revenue. This is the main reason why developers in the Tools department can meet with competitors, go to conferences, give away free work etc. This, in turn, builds a general attitude that when something is about to be created, the question asked beforehand is if it can be made open source. There is also a follow-up question, whether Sony Mobile would benefit anything from it, for example maintenance, support and development from an active community. If a feature or a project is too specific and it is deemed that it will not gain any traction, the cost of generalizing the project for open use is not motivated. Another factor is whether there is an existing community for a feature or a project. By contributing a plug-in to the Jenkins community or a feature to Gerrit there is a chance that an active workforce is ready to adopt the contribution, whilst for new projects this has to be created from scratch which may be cumbersome.
Another strategic factor concerns having a first-mover advantage. Contributing a new feature or a project first means that Sony Mobile as the maintainer gets a higher influence and a greater possibility to steer it in their own strategic interest. If a competitor or the community publishes the project, Sony Mobile may have less influence and will have to adapt to the governance and requirements from the others. A good example here is the Gerrit-trigger. The functionality was requested internally at Sony Mobile and therefore undergone development by the Tools department during the same period it became known that there was a similar development ongoing in the community. As stated by I3, “… we saw a big risk of the community going one way and us going a very different route”. This led to the release of the internal Gerrit-trigger as an open source plug-in to Jenkins, which ended up being the version with gained acceptance in the Jenkins and Gerrit communities. The initial thought was however to keep it closed according to I3, “… We saw the Gerrit-trigger plug-in as a differentiating feature meaning that it was something that we shouldn’t contribute because it gave us a competitive edge towards our competitors [in regards to our continuous integration process]”. It should be noted that this was in the beginning of the process of opening up in Sony Mobile and a positive attitude was rising. A quote from I3 explains the positive attitude of the organization which might hint about future directions, “… in 5 years’ time probably everything that Sony Mobile does would become open”.
5.3 Requirements engineering
This theme provides insights about requirements engineering practices in an example OI context. The requirements process in the Tools department towards the Jenkins and Gerrit communities does not seem very rigid, which is a common characteristic for OSS (Scacchi
2002). The product development teams in Sony Mobile are the main customers of the Tools department. The teams are, however, quite silent with the exception of one or two power users. There is an open backlog for internal use inside Sony Mobile where anyone from the product development may post feature requests. However, a majority of the feature requests are submitted via e-mail. The developers in the Tools department started arranging monthly workshops where they invited the power users and the personnel from different functional roles in the product development organization. An open discussion is encouraged allowing for people to express their wishes and issues. An example of an idea sprung out from this forum is the Build-failure-analyzer
8 plug-in. Most of the requirements are, however, elicited internally within the Tools department in a dialogue between managers, architects and developers. They are seen to have the subject matter expertise in regards to the tool functionality. According to I2, there are
“… architect groups which investigate and collaborate with managers about how we could take the tool environment further”. This is formulated as focus areas, and
“… typical examples of these requirements are sync times, push times, build times and apart from that everything needs to be faster and faster”. These requirements are high level and later delegated to the development team for refinement.
The Tools team works in an agile Scrum-like manner with influences from Kanban for simpler planning. The planning board contains a speed lane which is dedicated for severe issues that need immediate attention. The importance of being agile is highlighted by I2, “… We need to be agile because issues can come from anywhere and we need to be able to react”.
The internal prioritization is managed by the development team itself, on delegation from the upper manager, and lead by two developers which have the assigned role of tool managers for Jenkins and Gerrit respectively. The focus areas frame the areas which need extra attention. Every new feature is prioritized against existing issues and feature requests in the backlog. External feature requests to OSS projects managed by the Tools department (e.g. the Gerrit-trigger plug-in) are viewed in a similar manner as when deciding whether to make an internal feature or project open or not. If it is deemed to benefit Sony Mobile enough, it will be put in the backlog and it will be prioritized in regards to everything else. As stated by I3, “… We almost never implemented any feature requests from outside unless we think that it is a good idea [for Sony Mobile]”. If it is not interesting enough but still a good idea, they are open for commits from the community.
An example regards the Gerrit-trigger plug-in and the implementation of different trigger styles. Pressing issues in the Tools department’s backlog kept them from working on the new features. At the same time, another software intense organization with interest in the plug-in contacted the Tools department about features they wanted to implement. These features and the trigger style functionality required a larger architectural reconstruction. It was agreed that the external organization would perform the architectural changes with a continuous discussion with the Tools department. This allowed for a smaller workload and the possibility to implement this feature earlier. This feature-by-feature collaboration is a commonly occurring practice as highlighted by I1, “It’s mostly feature per feature. It could be an organization that wants this feature and then they work on it and we work on it”. But we don’t have any long standing collaborations”. I3 elaborates on this further and states that “… it is quite common for these types of collaboration to happen just between plug-in maintainer and someone else. They emailed us and we emailed back” as was the case in the previous example.
In the projects where the Tools department is not a maintainer, community governance needs more care. In the Gerrit community, new features are usually discussed via mailing lists. However, large features are managed at hackathons by the Tools department where they can communicate directly with the community to avoid getting stuck in tiny details (Morgan et al.
2011). As brought up by I2,
“… with the community you need to get people to look at it the same way as you do and get an agreement, otherwise it will be just discussions forever”. This is extra problematic in the Gerrit community as the inner core team with the merge rights consists of only six people, of which one is from Sony Mobile. One of the key features received from the community was the tagging support for patch sets. I2 stated,
“… When developers upload a change which can have several revisions, it enabled us to tag meta-data like what is the issue in our issues handling system and changes in priorities as a result of that change. This tagging feature allows the developers to handle their work flow in a better way”. This whole feature was proposed and integrated during a hackathon, and contained more than 40 shared patch sets. Prior to implementing this feature together with the community (I3 quoted)
“… we tried to do it with the help of external consultants but we could not get it in, but meeting core developer in the community did the job for us”.
As hackathons may not always be available, an alternative way to communicate feature suggestions more efficiently is by mock-ups and prototypes. I3 described how important it is to sell your features and get people excited about it. Screenshots is one way to visualize it and show how it can help end-users. In the Jenkins community, this has been taken further by hosting official webcasts where everyone is invited to present and show new development ideas. Apart from using mailing lists and existing communication channels, Sony Mobile creates their own channels, e.g. with public blogs aimed at developers and the open source communities.
This close collaboration with the community is important as Sony Mobile does not want to end up with an internal fork of any tool. An I2 quoted,
“If we start diverging from the original software we can’t really put an issue in their issue tracker because we can’t know for sure if it’s our fault or their system and we would loose the whole way of getting help from community to fix stuff and collaborate on issues”. Another risk would be that
“…all of a sudden everybody is dependent on stuff that is taken away from the major version of Gerrit. We cannot afford to re-work everything”. Due to these reasons, the Tools department is keen on not keeping stuff for themselves, but contributing everything (Ven and Mannaert
2008; Wnuk et al.
2012). An issue in Jenkins is that there exist numerous combinations and settings of plug-ins. Therefore, it is very important to have backward compatibility when updating a plug-in and planning new features.
5.4 Testing
Similar to the requirements process, the testing process does not seem very rigid either. I3 quoted, “… When we fix something we try to write tests for that so we know it doesn’t happen again in another way. But that’s mostly our testing process I think. I mean, we write JUnit and Hudson test cases for bugs that we fix”.
Bugs and issues are, similarly to feature requests, reported internally either via e-mail or an open backlog. Externally, bugs or issues are reported via the issue trackers available in the community platforms. The content of the issue trackers is based on the most current pressing needs in the Tools department. Critical issues are prioritized via the Kanban speed lane which refers to a prioritized list of requirements/bugs based on the urgent needs of Sony Mobile. If a bug or an issue has low priority, it is reported to the community. This self-focused view correlates with the mentality of how the organization would benefit from making a certain contribution, which is described to apply externally as well,
“… Organizations take the issues that affect them the most”. However, it is important to show to the community that the organization wants to contribute to the project as a whole and not just to its parts, as mentioned by Dahlander and Wallin (
2006). In order to do so, the Tools department continuously stays updated about the current bugs and their status. It is a collaborative work with giving and taking.
“Sometimes, if we have a big issue, someone else may have it too and we can focus on fixing other bugs so we try to forward as many issues as possible”.
In Gerrit, the Tools department is struggling with an old manual testing framework. Openness has lead them to think about switching from the manual to an automated testing process. I2 stated, “… It is one of my personal goals this year to figure out how we can structure our Gerrit testing in collaboration with the community. Acceptance tests are introduced greatly in Gerrit too but we need to look into and see how we can integrate our tests with the community so that the whole testing becomes automated”. In Jenkins, one of the biggest challenges in regards to test is to have a complete coverage as there are many different configurations and setups available due to the open plug-in architecture. However, Gerrit still has some to catch up as stated by I2, “it is complex to write stable acceptance tests in Gerrit as we are not mature enough compared to Jenkins”. A further issue is that the test suites are getting bigger and therefore urges the need for automated testing.
Jenkins is considered more mature since the community has an automated test suite which is run every week when a new version of the core is released. This test automation uses Selenium,
9 which is an external OSS test framework used to facilitate the automated acceptance tests. It did not get any traction until recently because it was written in Ruby, while the Jenkins community is mainly Java-oriented. This came up after a discussion at a hackathon where the core members in the community gathered, including representatives from the Tools department. It was decided to rework the framework to a Java-based version, which has helped the testing to take off although there still remains a lot to be done.
I3 highlighted that Sony Mobile played an important role in the Selenium Java transition process, “The idea of an acceptance test harness came from the community but [Sony Mobile] was the biggest committer to actually getting traction on it”. From Sony Mobile’s perspective, it can contribute its internal acceptance tests to the community and have the community execute what Sony Mobile tests when setting up the next stable version. Consequently, it requires less work of Sony Mobile when it is time to test a new stable version. From the community perspective I3 stated, “an Acceptance Test Harness also helps the community and other Organizations to understand what problems that big or small organizations have in terms of features or in terms other requirements on the system. So it’s a tool where everyone helps each other”.
5.5 Innovation outcomes
The word
innovation has a connotation of newness (Assink
2006) and can be classified as either things (products and services), or changes in the way we create and deliver products, services and processes. Assink (
2006) classified innovation into disruptive and incremental. Disruptive innovations change the game by attacking an existing business and offering great opportunities for new profits and growth. Incremental innovations remain within the boundaries of the existing technology, market and technology of an organization. The innovation outcomes found in this study are related to incremental innovations.
Sony Mobile does not have any metrics for measuring process and product innovation outcomes. However, valuable insights were found during the interviews regarding what Sony Mobile has gained from the Jenkins and Gerrit community involvement. During the analysis, the following innovation outcomes have been identified:
5.
Flexibility in implementing new features and fixing bugs.
6.
Increased turnaround speed.
7.
Increased quality assurance.
8.
Improved new product releases and upgrades.
The most distinct innovation outcome is the notion of obtaining
free features from the community, which have different facets (Dahlander and Magnusson
2008; Stuermer et al.
2009). For projects maintained by Sony Mobile, such as the Gerrit-trigger plug-in, a noticeable amount of external commits can be accounted for. Similarly, in communities where Sony Mobile is not a maintainer, they can still account for free work, but it requires a higher effort in lobbying and actively steering the community in order to maximize the benefits for the organization. Along also comes, the
free maintenance and quality assurance work, which renders better quality in the tools. Furthermore, the use of tools (Jenkins and Gerrit) helped software developers and testers to better manage their work-flow. Consequently, it
freed-up time for the developers and testers that could be used to spent on other innovation activities. The observed innovation example in this case was the developers working with OSS communities, acquiring and integrating the external knowledge into internal product development.
Correlated to the free work is the acknowledgement that the development team of six people in the Tools department will have a hard time keeping up with the external workforce, if they were to work in a closed environment. “… I mean Gerrit has like let us say we have 50 active developers, it’s hard for the tech organization to compete with that kind of workforce and these developers at Gerrit are really smart guys. It is hard to compete for commercial Organizations”. Further on, “… We are mature enough to know that we lose the competitive edge if we do not open up because we cannot keep up with hundreds of developers in the community that develops the same thing”.
An organizational innovation outcome of opening up is the
knowledge retention which comes from having a movable workforce. People in the community may move around geographically, socially and professionally but can still be part of the community and continue to contribute. I3, who took part in the initiation of many projects, recently left Sony Mobile but is still involved in development and reviewing code for his former colleagues which is in line with the findings of previous studies (Morgan et al.
2011; Stuermer et al.
2009). Otherwise, the knowledge tied to I3 would have risked being lost for Sony Mobile.
Sony Mobile had many proprietary tools before opening up. Adapting these tools, such as the build server Electric commander, was cumbersome and it took long time before even a small fix would be implemented and delivered by the supplier. This created a stiffness whereas open source brought
flexibility. I2 quoted,
“… Say you just want a small fix, and you can fix that yourself very easily but putting a requirement on another organization, I mean it can take years. Nothing says that they have to do it”. This increase in the
turnaround speed was besides the absence of license fees, a main argument in the discussions when looking at Jenkins as an alternative to Electric commander. This was despite the required extra involvement and cost of more internal man-hours. As a result, the continuous integration tool chain could be tailored specifically to the needs of the product development team. I1 stated that
“… Jenkins and Gerrit have been set up for testers and developers in a way that they can have their own projects that build code and make changes. Developers can handle all those parts by themselves and get to know in less than 3 minutes whether or not their change had introduced any bugs or errors to the system”. Ultimately, it provides
quality assurance and performance gains by making the work flow easier for software developers and testers. Prior to the introduction of these tools there was one engineer who was managing the builds for all developers. In the current practice everybody is free to extend on what is given to them from tools department. It offers more scalability and flexibility (Morgan and Finnegan
2010).
I1 stated that besides the flexibility, the Tools department is currently able to make a “… more stable tools environment [at Sony Mobile] and that sort of makes our customers of the tools department, the testers and the engineers, to have an environment that actually works and does not collapse while trying to use it”. I2 mentioned that “… I think it is due to the part of open source and we are trying to embrace all these changes to our advantage. I think we can make high quality products in less time and in the end it lets us make better products. I think we never made an as good product as we are doing today”. Further exploration of this statement revealed the background context where Sony Mobile has improved in terms of handling all the new releases and upgrades in their phones compared to their competitors and part of its credit is given to the flexibility offered by the open source tools Jenkins and Gerrit.
The obtained external knowledge about the different parts of the continuous integration tool chain enabled better product development. However, the Tools department has to take the responsibility for the whole tool chain and not just its different parts, e.g. Jenkins and Gerrit, described by I5 as the next step in the maturity process. The tool chain has the potential to function as an enabler in other contexts as well, seeing Sony Mobile as a diversified organization with multiple product branches. By opening up in the way that the Tools department has done, effects from the coupled OI processes with Jenkins and Gerrit may spread even further into other product branches, possibly rendering in further innovations on different abstraction levels (Linåker et al.
2015). A way of facilitating this spread is the creation of an
inner source initiative which will allow for knowledge sharing across the different borders inside Sony Mobile, comparable to an internal OSS community, or as a bazaar inside a cathedral (Wesselius
2008). The tool chain is even seen as the foundation for a platform which is supposed to facilitate this sharing (Linåker et al.
2014). The Tools department is considered more mature in terms of contributing and controlling the OSS communities. Hence, the Tools department can be used as an example of how other parts of the organization could open up and work with OSS communities. I5 uses this when evangelizing and working on further opening up the organization at large, and describes how
“… they’ve been spearheading the culture of being active or in engaging something with communities”.