VMware — you may know the company as a leader in multi-cloud, a pioneer in virtualization, and an industry innovator. But did you know that VMware is an influencer and leader in open source ecosystems? My curiosity in VMware’s quiet yet superlative leadership in open source recently piqued when a tweet by Pushkar Joglekar, a VMware Tanzu Senior Software Engineer, appeared in my Twitter feed:
Upstream. The opposite direction from that in which a stream or river flows; nearer to the source. In the open source world? It’s where open source software lives, is continuously improved and maintained, and the community for a project comes together to collaborate for the benefit of all parties.
Pushkar’s enthusiasm is nothing short of contagious and I wanted to learn more about why he makes working upstream more integral to his work. He tells me:
I love working in open source and contributing to projects I had been a long time end user in the past. As an end user I had a unique perspective on the pain points and improvements that could be made but had no ability to address those issues. Having the freedom to work on fixing these pain points in the open, allows me to solve these issues for thousands of end users who are going through the same journey that I formally faced. And getting to work with a diverse group of individuals from all over the world? It’s an added plus!
Being able to fix pain points in the open—for thousands of end users. That’s Pushkar’s underlying message.
He invited me to talk to other VMware colleagues about their own experiences contributing upstream so I could further develop my understanding “for the love of contributing upstream”— and my journey led me to product managers, engineers, and developers — all expressing their enthusiasm for upstream. One software engineer even remarked, “When I retire, I’ll still be working in open source!”
Wow, that’s some fevered addiction!
But before I share with you the valuable takeaways from some of VMware’s top open source contributors, let’s look more closely at what “working upstream” entails and why it’s so impactful.
What it Means to be Upstream First
Working upstream — where the source resides — enables the opportunity to vet ideas with a larger, more diverse stakeholder community and work together to build new features, patches, releases, and content, with the contributors’ understanding that any changes made may impact other parts of the project. This is where collaboration comes in — it’s good to identify changes early and give the community a chance to weigh in their perspectives before coming to a consensus.
It’s also more practical to work upstream first. It can often be faster to implement a feature or a patch in a downstream project —especially if there are differing ideas about the project’s direction. But in the long run it’s more work to bring those features or patches back to the upstream project. By the time it’s been shipped downstream, it’s likely that the upstream code has changed, which makes it more difficult to integrate features and patches developed against an older version of the project (a situation known as “technical debt”).
By working upstream first, you can have more impact and influence on the overall project, you can minimize your technical debt, and you benefit from exposure to a more diverse set of ideas. Your method of solving a problem or implementing a new feature is but one way; by engaging with a community of like-minded developers and users, you will likely discover other ways— methods that may be an improvement over your idea.
Rose Judge, VMware Open Source Engineer and Co-maintainer of Tern, shines the light on why she’s inspired to contribute upstream and discusses one of her favorite projects in this brief video.
Diversity and Inclusion in Open Source Communities
Anyone who’s involved in a healthy open source community has experienced the power of contributing and innovating together and formed long-lasting genuine relationships with people they’ve met along the way. Davanum “Dims” Srinivas, a VMware Senior Staff Engineer, is one of these people. Dims works on Kubernetes and projects in the Kubernetes ecosystem, and also serves on the Kubernetes Steering and CNCF Technical Committees. He tells me he got bit by the open source bug in 2001 and he’s been contributing to open source projects ever since:
I was working 50-50 downstream/upstream until I was able to hire others and transition to upstream full time. I quickly grew to love open source because it allowed me to work from home and I worked with people all over the world—experts—and we’d celebrate the things we did together. There are no boundaries in open source, no hierarchy and everything that you do is right there in public view—the good, the bad, your mistakes, your personal learnings for people to see and evaluate—there’s no place to hide.
I heard: no place to hide. Learn how communities work and take those learnings into other communities. Diversity, inclusion. Mentoring. Celebrate the things we do together. How inspiring are these grounding attributes in a world that changes so quickly?
Robert Eckhardt, Product Manager of Postgres, the open source project that includes PostgreSQL binaries, packaged and commercially supported, addresses diversity, equality, and inclusivity in this way:
As a PM, my role is to balance work that actively helps our products that rely on Postgres with work that actively helps the Postgres project and/or community.
With VMware being such a big company, we’re able to rotate the team around in different roles, while increasing the size of the community. Postgres is one of the healthier projects, but we are looking to add more women and underrepresented minorities to open source. We have the unique ability to give people the chance to contribute to a project to see if open source contributions are a fit.
Do you innovate in ways beyond just writing code? Roberts says there are opportunities other than writing code in open source and are considered just as valuable, and he and his team strive to find ways to communicate that value internally.
People Solving Problems Together – Faster, More Creatively
Innovation is one of the top superpowers of a strong open source community. Ideas spread swiftly and collaborating on problems yields better outcomes than deriving individual solutions, benefiting both the platform and its users. Embracing this commitment to community lends to developers’ constant contribution of new features and ensuring old ones perform properly. It’s this cross-industry, borderless, and badgeless collaboration that fuels rapid innovation.
VMware’s V.P., Chief Open Source Officer, Dirk Hohndel, who spends his time “thinking about and interacting with open source software and the people and processes that make it successful,” speaks to the benefits of collaboration in a community in an even broader context:
Open source is a key methodology behind some of the most interesting technology developments and an ideal way to foster interoperability and cross-industry collaboration. From Kubernetes to Spring, these software innovations grew fast, gained adoption, evolved, and matured at astonishing speed because of the community collaboration and ready access.
Tasha Drew, VMware Director of Product Incubation, Co-chair for the Kubernetes Multi-tenancy Working Group and SIG Usability, and 2021 CNCF award-winner of Chop Wood Carry Water, looks at the ecosystems, the Special Interest Groups (aka SIGs), and the working groups under the Linux Foundation, when wanting to gauge how people are thinking about a certain topic and/or solve a given problem:
Upstream is the right place to be if there is a friendly, professional community of people who want to solve problems together, and you have a problem or a question or a solution you want to share in that space. When I am investigating a question – like “how will people automate the lifecycle of an application or service in a cloud native architecture,” or “how are people thinking about layers of tenancy in Kubernetes,” or “what is the user experience using Kubernetes” – I look at the ecosystem, the SIGs, and the working groups under the Linux Foundation and check out their meetings and notes and demos online, to see if there are a group of people who are asking (or answering!) similar questions. This often hugely accelerates my understanding of the space, and then I can bring what I learn back to the products I’m working on.
A significant takeaway from Tasha? She says when she works with a team who is solving a problem in the space of an open source project, like Kubernetes, she always encourages them to think about how they can contribute and collaborate upstream, so that they can move the state of the technology forward in a shareable, collegial way.
Making the Case for Allocating Time to Open Source Projects
How does one begin to get valid open source experience under their belts and pursue “working in” open source to their day job when it has no part in it at all? And how can an employer evaluate their employee’s open source contributions?
Carlisia Thompson, Senior Member of Technical Staff at VMware, spoke about the topic at the Women Transforming Technology Conference in May of this year. The Open Source Editorial Team talked with her subsequently, and published her insights in a blog entitled Foolproof Your Career with Open Source. She comments:
Regardless of where you are on your professional journey, open source can accelerate your career and make it more resilient. Since your contributions to a project are visible to the public, open source allows you to build an accessible resume and tangible body of work. From an employer’s perspective, demonstrating involvement in open source shows where you want to be — you are not just talking the talk, but walking the walk. Your public body of work makes you a “known entity.” This makes it easy for an employer to evaluate your work, understand what you’re interested in, and imagine how you would fit into their organization.
There you go.
Remember Pushkar, who tweeted about how happy he is in his new role at VMware, working a 50-50 split between open source and proprietary? A change from his previous full-time role in proprietary that left him investing much of his free time contributing to open source?
I got back with him, wanting to know just how he negotiated that 50-50 split with his VMware leaders. He tells me:
It’s about the top-down awareness of how good open source is for the company — that’s in my favor. But “shifting security left and up” seems to have resonated with my supervisors, too, as anything done in Open benefits the larger community and has a side-effect of benefiting the dependent proprietary product.
Well, isn’t that something?
You know what’s even cooler? Pushkar’s “ideal split” for 2022 is 70-30!
The Future of Open Source Software is Incredibly Bright
This brings us to the conclusion of Part 1 of this two-part blog series. Many thanks to all of our contributors who didn’t hesitate at the opportunity to talk Upstream!
Oh, and all you open source newbies out there—what are you waiting for?
Jump on in. The water upstream is fine!
Stay tuned for Part 2 of this Open Source Blog series where we’ll discuss VMware-initiated Open Source projects, VMware employees’ leadership roles in the CNCF ecosystem, and other community projects such as TUF. We’ll also illustrate that working upstream isn’t just about code. In the meantime, follow us on Twitter for more deep dives into the world of open source contributing.
