In March 2015, the leadership of Berlin-based Zalando gathered the company’s entire tech team in a hip underground techno club (it’s Berlin, after all) and announced a new way of working—something called “Radical Agility.” Inspired by Daniel Pink’s Drive, Brian Robertson’s Holacracy system and the agile movement, Radical Agility emphasizes Drive’s call for autonomy, mastery and purpose as the pillars of the company’s tech strategy and culture. With this new framework, Zalando could more effectively evolve from e-tailer to online fashion platform; from top-down command-and-control to agile; from stagnant/uncool Java monolith to scalable and technically challenging microservices architecture that supports a polyglot approach to development.

As you might expect from such a substantial cultural transition, Radical Agility deeply transformed Zalando’s open source development efforts. Until that point, our GitHub activity had been minimal: a few projects geared around PostgreSQL, a monitoring and alerting solution that had emerged during one of the company’s annual Hack Weeks, and a few Python projects created by a prolific dev on the cloud team summed up the company’s offerings. Radical Agility gave engineers the freedom and encouragement to choose and use the technologies—including open source—they felt were necessary and optimal to get the job done, or build their own software if none existed. The adoption of technical Rules of Play encouraging microservices, RESTful APIs, and use of cloud technologies like AWS freed them up to experiment. Many of our engineers felt this was the first time in their careers someone trusted them to make their own decisions.

Through the rest of 2015, dozens of new, informal technical guilds formed around specific programming languages, types of development, methodologies, AWS use, web dev, and other topics. Along with our head of platform/infrastructure engineering, I created a new Open Source Guild and, along with about 20 regular engineers showing up for our biweekly meetings, we crafted the first drafts of our “how to open source” guidelines. These guidelines were pretty rudimentary in hindsight, but they covered the basics: which license to use (MIT), versioning, creating maintainers files, etc. We shared these guidelines with the rest of the organization and kept them as a living document, always subject to change as we learned more.

Meanwhile, the number of projects published on github.com/zalando soared into the hundreds. The enthusiasm our team showed for open source led the Guild to next develop a set of Open Source First principles to institutionalize this openness. These principles encourage our engineers to share their code instead of hide it inside private repos, as well as “take ownership,” “be safe,” “provide documentation,” and “ask for help.” The message reinforced the pillars of Radical Agility by encouraging mastery, team autonomy and end-to-end delivery of projects, and solid craftsmanship.

Naturally, transforming a culture takes a lot more than creating and publishing guidelines and principles. And getting everyone up to speed can take some time when you’re working with a rapidly growing, distributed organization undergoing a major organizational transformation. Pre-Radical Agility, many Zalando engineering teams had been working in a context in which they were expected to execute functional tasks, do whatever their lead/manager said, or both. This kind of culture might be good for delivery speed, but it doesn’t encourage engineers to engage with the product they’re building or solve problems independently. And our projects on GitHub reflected this. Members of the Open Source Guild who had cultivated a product mindset started to complain that the work we were sharing with the world often wasn’t usable to anyone beyond our own walls.

A quick scan of our GitHub repos showed that quality varied. Some projects were out-of-the-box useful and had audiences of users or external contributors, but our overall output showed that we didn’t reflect a coherent definition of what “open source” meant to our team. We already had used GitHub APIs and the talent of our monthly onboarding groups to generate a real-time metrics dashboard showing us which of our projects were most popular, and a few other data points. But a deeper dive revealed that many engineers published repos without READMEs, didn’t invite contributions, and didn’t clarify the “why” behind their work. Many projects were tightly dependent upon our own unique systems. And with so many projects to track, transparency and insight into what we were doing as a tech org—and why—was lacking. Despite growing our dev team exponentially (3x since Radical Agility’s big reveal), our GitHub activity, now scattered across many different teams across the organization, still had no official overseer.

In January 2016, I became Zalando’s open source evangelist and set about guiding our technology team toward a coherent, open source effective strategy. With 300+ projects and always more on the way, where to begin? Among my first few tasks were to publish our how-to on GitHub and start raising internal awareness. A few weeks into the job, I went to FOSDEM and met other, more experienced Open Source Evangelists like Brandon Keepers of GitHub and Duane O’Brien of PayPal. These pros gave me some valuable feedback on how to encourage engineers to deliver maximum value in their open source efforts.

To understand what we were publishing on GitHub in a holistic way, I dug in and checked out each one of those 300+ projects on our GitHub repo. This review process took a few months, and revealed that we were releasing a lot of work that wasn’t truly open source — i.e. out-of-the-box useful to the community at-large. With some guidance, we could turn that around. But doing that would take many one-on-one discussions with project creators. Luckily, I was in the perfect position to do this sort of communication, and set to work.

My process went like this:

• Check out a given repo on our GitHub org
• Assess the README for clarity of project purpose (what it did and how, why it did those things), setup/install directions, and other need-to-knows
• Ensure the project was actively maintained and included a maintainers file
• See if there was a contributing guidelines file, or any invitation for contributors at all
• Look for other Zalando dependencies
• Follow up with the project’s maintainers and ask them what their goals were for their project, if they planned to add anything missing like README instructions or contributor guidelines, then begin helping them

Some projects we weren’t maintaining or using at all—so I deleted those after getting the okay from the project creators (and, if need be, surveying the team to make sure we could delete without breaking anything). More often, we had released something useful only to ourselves; in those cases, the next step was either to pull back the repo and publish on GitHub Enterprise, or… or… or what? We definitely needed to reduce the signal-to-noise ratio on our GitHub org. We wanted to ensure that the strongest work rose to the top of our projects dashboard, and was most easily discoverable. However, the creators of many such projects really wanted their code to remain public.

The goal was to come up with a way for us to both respect their wish while making it more possible, as one veteran Zalando engineer put it, “to find the cool stuff.”

The solution: create a new GitHub organization called the Incubator for storing those “coding in the open” projects, and use only the main Zalando GitHub org for “the cool stuff.” After assuring our engineers that transferring GitHub repos from one org was possible and low-risk, I reached out to project creators and maintainers and worked with them to transfer their work. To help clarify why, we added a new section to our “how-to” explaining the difference between the main org and the Incubator, as well as which repos were appropriate only for GitHub Enterprise.

When GitHub notifications informed me that new projects had just come online, I’d check them out to see how out-of-the-box useful and polished they were. If the README wasn’t clear that something was dependent on our own systems, or if there was no clear purpose detailed yet, I’d follow up immediately with the project creators to ask about their project vision. From 300+ projects on our main GitHub org, we’re now down to 149 projects. Now, more than ever, the collection of projects we highlight to the public emphasizes usability, good documentation, clarity of purpose, and “the cool stuff.”

After refining our guidelines and processes, publishing them on GitHub, and sharing them in one-on-ones with any engineer who didn’t know them, it took just a few months for our engineering team to adapt without any additional intervention required. Continuously clarifying the guidelines based on user feedback—i.e., developers’ questions or points of confusion—helped with iteration, to ensure the guidelines were as clear as possible. And taking any opportunity to answer a question with “go to our guidelines for your answer!”—in HipChat forums, in one-on-ones, and in meetings—reinforced the message. I also integrated key parts of the how-to into my monthly open source presentation to our new hires, so that they would be aware of our processes and know where to find answers to their questions.

Over the past few months, the focus of my open source evangelism has shifted from grassroots awareness-raising and transferring repos around, to collaborating with project creators on promoting their great projects. The engineers behind Zappr, a GitHub integration that enhances workflow and enables teams to enforce repo requirements, evolved their project from a hack into an official GitHub integration. Patroni (a high-availability solution for PostgreSQL), and Connexion (API First Python Flask framework) have also developed into strong projects with external contributors, tech-media coverage, and community support. The devs do most of the hard work; I primarily show them where the doors of opportunity are open, and guide them across the threshold if they need any help.

The Guild’s continued work has increased awareness of the ways we deliver open source products that the community can use. Guild members are key to driving and shaping the open source culture inside our 100+ delivery teams in a democratic, practical way. We discuss projects, community management, licensing, industry trends, and other relevant topics on a biweekly basis, with a rolling agenda of topics the engineers propose. Colleagues who aren’t located in our Berlin tech HQ join via Google Hangout. We pitch any changes to our how-to guidelines there, then document via Google Docs and share with Guild members at large (who now represent about 20% of our whole tech organization). We collect comments and challenge each other. Then, after about a week’s worth of review and deliberation, we incorporate the new changes into the how-to. This way, our open-source culture remains grassroots and organic—that is “Radically Agile.”