Developer Relations at Cloudera: Introducing DevRel and What Developer Advocacy Means for Cloudera
This blog is part one of two
It has been slightly more than four weeks since I joined Cloudera to lead Developer Relations (DevRel). A month may seem brief, but it’s enough to feel the pulse of a community—its culture, its people, and the momentum behind some of the key technologies that Cloudera drives.
In this blog post, I’ll explain what Developer Relations means for Cloudera. The DevRel function can look different from one organization to another, depending on the goals of advocacy. This is my fourth DevRel gig, and at Onehouse, Dremio, and Qlik, the focus was slightly different. But the crux has always been the same: educating, engaging, and building a two-way relationship with developers.
In part two, I’ll share what I’ve seen in my first 30 days, our plans for supporting practitioners in their pursuits and use of the technologies that matter most to them, and how our platform supports their efforts.
What is Developer Advocacy?
Developer Advocacy is a specific role within the DevRel function and while there are other roles within the function, we will use these terms interchangeably in this blog.
Figure 1: Developer Relations as an interface with product, engineering, and marketing teams and developers
At its core, DevRel is the bridge between technologies (products) and developers. On one hand, it’s about enabling developers to be productive, grow, and succeed with a range of data and AI technologies. This involves breaking down complex system internals in the form of blogs, books, or papers; showing how to accomplish something (with code); and exploring possible use cases via demos, hands-on labs, or webinars. It’s about being present where developers already are—meetups/conferences, open-source Github repositories, Slack channels, and forums.
Figure 2: A day in the life (of DevRel)
On the other hand, it’s about carrying developers' voices back into product engineering and making sure their needs shape what gets built next. When done right, DevRel creates a two-way feedback loop. We show what's possible with a platform, and we also listen to and incorporate where developers get stuck (the issues/errors), what excites them (capabilities), and how the community evolves with the ecosystem.
What Does Developer Advocacy Mean at Cloudera?
At Cloudera, developers have always been at the center. The company sits at a unique intersection: open-source commitment on one side and enterprise adoption on the other. Cloudera has a long history of contributing to foundational Apache projects like Spark, Flink, Kafka, Ozone, NiFi, and Iceberg, while also serving a global customer base that depends on these technologies for production-grade scale and reliability.
Figure 3: Cloudera’s support and usage of various open source software
In line with its open-source foundations, Cloudera is built on the principle of being open for integration, frameworks, and standards. That openness gives developers the freedom to use the tools they already know, adopt new ones as the ecosystem evolves, and avoid being locked into a narrow path.
That is why DevRel is so critical here. It means staying deeply engaged with the open-source ecosystem, while also enabling enterprise developers who rely on Cloudera to solve real problems in data and AI using these foundational technologies.
At Cloudera our DevRel work is anchored on three pillars: awareness, engagement, and impact. Awareness is about making sure developers discover and understand what’s possible. Engagement is about meeting them where they are. And impact is about driving real outcomes: helping developers be more productive, shaping better products through feedback, and strengthening the open-source projects we all depend on.
What We’re Building for Developers
As I wrap up my first month, I keep coming back to a simple thought: my journey has always been shaped by community. I started as an engineer leaning on open source—reading docs, interpreting code, and learning from community blogs. Over time, I contributed back in different ways.
Now at Cloudera, I see the chance to extend that same cycle: to learn, share, and build alongside developers. Here’s what we’ll be working on in the coming months:
Technical deep-dives: This includes blogs, how-tos, and whitepapers on how to operationalize technologies like Iceberg, Spark, Flink, NiFi, Ozone, Kafka, and more at scale with Cloudera. They’ll show real patterns, tradeoffs, and examples you can reuse.
New explainer series: Encompassing short, focused breakdowns of concepts, use cases, and learnings from production in the data and AI space. The goal is to cut through jargon and give developers a clear mental model.
Hands-on labs: These are guided, runnable examples you can try on your own laptop or cloud environments. If a blog tackles the “why,” labs will show the “how.”
Community events: We are meeting engineers wherever they learn and code. So, meetups, workshops, and conference sessions are where we will engage directly, exchange ideas, and learn from one another.
Join me at the Cloudera Community and engage with the content, try out the code, give feedback, and ask questions!