Aiven's OSPO is now one year old. Find out what OS Engineering Manager Josep Prat and his team have learned about setting up and running the function.
Josep Prat
|RSS FeedSenior Engineering Director, Streaming Services
Subscribe for the latest news and insights on open source, Aiven offerings, and more.
A year ago, Aiven raised $100M in a series C investment round which put the company valuation around $800M, and recently achieved a $2B unicorn valuation having raised $210M total funding. One of the important reasons for raising that round was to increase our impact in the Open Source communities.
One of our first actions was to create the Open Source Program Office (OSPO for short), a department whose work is exclusively dedicated to contributing to open source projects. The team went from just a pair of people to double the size several times, always growing at a sustainable pace.
The mission of Aiven's OSPO is simple:
Ensure the sustainability and secure the future of the Open Source Software infrastructure Aiven uses.
Aiven has always contributed back to open source, since the very early days when Aiven consisted of four founders only. Contributing to upstream OSS projects was the most normal thing to do, it was nothing special or something to discuss, and patches were always to be contributed back. As Aiven continued to grow, this part of the culture stayed, but at the same time, it became apparent that keeping a constant stream of contributions to upstream projects while delivering a successful product was challenging.
With the creation of a dedicated team, we wanted to ensure that our commitment remains at the level that the key OSS projects in our infrastructure deserve.
Each member of the OSPO team focuses on a specific project, for example, Apache Kafka®, Apache Flink®, PostgreSQL®, M3, or OpenSearch®, among others. But the OSPO members are not the only ones contributing upstream, every single person at Aiven is welcomed and encouraged to do so.
Aiven's OSPO team has responsibilities in three main areas:
This is where the team spends most of its time. Each team member can decide the tasks and focus areas; the only criteria is the impact on the community. Their contributions are not limited to the core products, but any project in their ecosystem (plugins, connectors, underlying libraries...). Each team member is also a member of the community, so they have an inside view and can evaluate the potential impact of the tasks they are working on.
We especially emphasize getting rid of technical debt, as these tasks are usually not picked up by people working on OSS during their free time. These type of tasks has a good ratio of time invested vs. returns in the area of maintainability.
Our work on 3rd party OSS projects is not limited to contributing new features, bug fixes or cleaning technical debt. One crucial part is reviewing existing code submissions from the community. We understand maintainers' workload is usually several orders of magnitude higher than what one person can tackle, so we do what we can to share it.
We want to ensure that any OSS project Aiven depends on has enough people working on it. This is the best way to ensure project stability. The more companies that would do this, the better the OSS ecosystems get, in that their existence will not depend on single individuals or single companies.
Our work in this space is guided by the following principles:
Aiven is not just a consumer and contributor to OSS, but also a producer. The OSPO team is an integral part of the process, starting from the moment the teams decide they want to open source a given project and also during all the project lifecycle.
The OSPO team makes sure each member of our organization is aware of the power and importance of OSS. We work closely with Engineering, Product and Developer Relations teams to identify opportunities for open sourcing internal projects that may benefit the community - not just users of the Aiven platform, but anyone using the underlying OSS technologies.
One important initiative at Aiven that helps to foster OSS culture and mentality is our Plankton Program. We offer monetary compensation for all Aiven employees who decide to spend some of their free time working on open source projects. And this is not limited to just writing software, but any type of work done in open source: from contributing to programs like Common Voice, to writing articles in Wikipedia, or doing some project management for an existing open source.
The OSPO team is not the "team that does open source at Aiven". We're the team that multiplies open source at Aiven.
Additionally, together with our product teams, we maintain the open source projects under Aiven's umbrella. We make sure those projects are community friendly. The work we do goes beyond providing code. We offer guidance and structure around governance, project management, licensing, and community engagement.
As a consumer and producer of open source, Aiven needs to ensure all our software is compliant with all legal aspects involving licenses, trademarks, and contributor agreements. To do this we resort to a great team of experienced lawyers who help us navigate relevant legal frameworks.
To succeed in this area we need to know our full dependency tree. The Software Bill Of Materials (SBOM) is a tremendously useful tool that helps analyzing and auditing the dependency tree of given software.
Having this information is crucial to determine which projects are in our supply chain and which ones we deem might need some help.
During this first year at OSPO, we have learned several important things. To help others follow in our footsteps, we want to share them with the world.
Companies have been hiring for product development roles for a long time, and one might think that creating a team for the OSPO might be only slightly more complicated. However, as we were building an OSPO whose focus was 3rd party OSS projects, we needed a different type of developer.
Current software development optimizes for turn-around time: how fast can I get feedback on the feature I'm working on right now. This means that our industry focuses on aspects like incremental development, continuous integration and continuous deployment, early feedback, and listening attentively to users.
While we believe this is a great way of developing products (Aiven focuses on those same terms for our product), applying it to 3rd party OSS development won't yield the expected results as delivery happens at the community level (either via Project Management Committees or via different means of consensus in the community). We need to find ways of working (and developers that are effective under this) that accommodate the fact that the timings and even deciding if changes get incorporated happen outside of the team and even the company.
Instead we need to look for developers who:
Also, it goes without saying that we needed to go fully remote: instead of expecting the talent to come to us, we want to go where the talent is.
There are lots of management styles, and the type of management we need to succeed with 3rd party OSS differs from the mainstream. We learned that delivery can't be the responsibility of the manager when working with 3rd party OSS, because project governance is driven outside the company, far from the reach of the managers. This means we need to focus on enablers, true multipliers that make people perform at their full potential.
Another crucial aspect is to find managers that are completely comfortable in not being the expert in the room. More often than not, managers know only the superficial aspects of the technologies their team is working on. When one is a manager of a team working on PostgreSQL®, Apache Kafka® and OpenSearch®, it's clear that they will never be experts in all these areas, and maybe some of them are only known to them from a user perspective.
The eternal question is how do we measure success? This is already a complicated question in software engineering in general, but when the team whose success we need to evaluate contributes to 3rd party OSS, it just gets more complex.
The first thing we need to acknowledge is that the time scale of the development process doesn't belong to us, but to the whole community. How can we then use metrics like "number of features released" or "time to deploy"? In short, we can't. We need to move away from such metrics and concentrate on measuring things we have the full control on. For example, a set of metrics that are useful for us are:
This was a wonderful year, we built up the team from the ground up and had a real impact on the projects we worked on. Since we proved to ourselves we can do this, we want to double down for the year to come.
We want to double our size and increase the reach and breadth of our team (more projects and more people per project). Our synergies with the product teams generated way more OSS projects that we expected, so we want to also put some more effort in this area. We want to make sure that the majority of our OSS projects are welcoming external contributors and foster a safe place for people to form communities around them.
But all this couldn't be done without the great help from our Engineering teams and our Developer Relations team. Don't forget to check out our open positions here!
To another year, of many more, of successful contributions to open source!
