The development and evolution of the Android client for ownCloud is a good example of how the collaboration between an open source community and a company’s engineering team can grow through the years. It can also illustrate some of the challenges and benefits of addressing them in an open and collaborative way.
The ownCloud Android app is over 3 years old. It was born in the community, the collaboration of a couple of people, and it happened before the current ownCloud Android engineering team was even put into place. From the beginning, this was an app that grew based on the collaboration between the engineering team and community developers. That collaboration has accelerated over the last 18 months, but that growth was neither inevitable nor steady. In fact, it is the role of one or two key people who end up driving that growth and without whom things may have turned out differently. A key community developer who not only does a lot of work, but also brings others, can make a world of difference. This self-driven aspect was really important and, in a sense, drove us to increase our responsiveness to community requests.
In order to encourage, sustain, and support the community aspect of the Android ownCloud app, our team started to do a number of things to initiate and guide conversations with the community. The team started using github tags to announce areas of interest, either encouraging new people with “Junior Jobs” or marking an issue as “Contributions are Welcome” to request help in specific areas where the internal engineering team could not focus immediately. Internally, engineering took a very internal, scrum-focused process and proceeded to adapt it without losing its benefits to a community project and using tools that the community could access. Sprint reviews have become more attentive to community pull requests, at some cost, which of course is well worth it, to the roadmap-focused team speed, with full support and encouragement from ownCloud’s product leadership.
How the team handles community pull requests is a core element of this collaboration. With increased community contributions, the task gets harder, even if it is rewarding across the board. To handle a community pull request, the team, including product leadership, first values the technical aspects of the submission, what problem it is trying to solve, and how it advances the app. This is followed by feedback to the community developer or, if it is of obvious value, marking the pull request as “Ready to test.” At that point, the internal QA team has a go, dealing also with its own prioritization of tasks. While internally the team uses a private backlog to deal with these issues, the output of all this work is on github and is readily available for the next steps.
Also, not all pull requests are handled by the internal engineering team any longer. With the growth of the ownCloud Android developer community, other community contributors have started to edit and comment on other community pull requests. Branches are also created with pending pull requests by the developer community. This process runs autonomously and now involves, at this point, 15 community developers between submitters and reviewers, a number that continues to grow.
The quality of a contribution depends on the experience, effort, and the skills of the contributor. Long-term contributors are easier to work with, because the communication is easier as adhering to common standards is almost second-nature and there is a known history to draw back on. Some of the collaborations have been very high quality, for example the work on Material Design, which has changed the app substantially. But in general, even with initial disagreements, it has been easy to orient the code and the pull requests so that they can be brought into the app itself. The large majority of pull requests end up merged (easily over 90% at this point); not always without changes, not always immediately, but almost always adding value to the app.
One of the key questions for the internal engineering team is, of course, the amount of time they can spend on these community pull requests. In reality, it varies across the sprints. With 2 week sprints, this emphasis can be calibrated very frequently based on both internal pressures (customers, roadmap) and community ones (the number and age of pending contributions). The growth of the developer community, the growing list of pull requests, our own emphasis on open source is the core of our company, and the delight to work with a team of thoughtful, brilliant, and committed community members is what keeps driving our team’s desire to continue to increase this collaboration and, with the permission of customers and roadmaps, make it even better.