All right, folks. Thanks for your patience. This next talk is about upstream and downstream
tensions and why there's so common even when everyone has good intentions downstream
needs shipping and stability. And those can collide with upstream norms and priorities.
And that friction can wear teams down if it's not handled well. Please welcome Adilko
Vancha. I got it. For practical look at how these dynamics show up and how to help teams work
through them. Thank you. Thank you all for making it for my session.
So today I will talk about some challenges and dynamics and open source communities
that are somewhat driven inspired by corporate involvement, which is by the way very encouraged
and welcomed but sometimes again there are some dynamics that go a little bit off-row.
But before I go into all that, first of all I'm really bad at keeping myself on time.
So there are so many ways to catch me if you cannot catch me at the event today here in person.
Please reach out. And who am I and why am I talking about this topic?
So I am director of community at the opening for foundation, which is a non-profit organization
supporting open source communities like OpenStack, Kada containers and many more.
And I'm also a personal individually enthusiastic about open source.
So because I have so much free time, no I don't. But I still became the creator host and soul
maintainer of the my open source experience podcast. So if you want to hear about topics like this
or other topics about the mechanics of open source, tune in to that one.
So without further ado, what is this talk about?
So I started an open source and started an open source as in finally getting involved in open source
a bit over 13 years ago. And I started that as part of my paid job.
And over the course of this 13 years, I transferred from my corporate paid job into the nonprofit paid job
and worked with numerous communities over time. And kind of experienced open source becoming not just mainstream
but even more mainstream. So you see companies, open sourcing their projects.
You see companies getting involved in open source projects, which is amazing.
And I still think that there are so many companies who should get on this train and get involved.
But sometimes it happens that their people get kind of thrown into this big ocean of open source
without even being asked if they can swim.
And then it becomes a challenge in so many ways for the individuals, for the communities, or both.
So what kind of things do I mean?
For example, this is one where one, two, three companies, all of a sudden that's open source
this project for whatever motivation they have.
And then there are the people who have been working on that code.
Up until the point of all of a sudden, the code is getting uploaded into a public repo
and all of a sudden they are supposed to work on an open source project.
So how many ways do you think this can go wrong?
And by the way, does anyone have this particular experience?
Or do you know anyone who's being in this boat?
All right, we have a few people in the room.
So there are so many challenges that I will, I could spend the whole presentation, just on this one.
But the challenge really is that when people don't really get the opportunity to learn about open source values, practices, processes,
it's really hard to rewire your brain from the corporate way of doing things into how do I actually work and operate in a fully completely public environment.
And how do I build a community around that open source code?
Because open source is more than just the code and the license is.
However, if you have a group of people who as a group don't really have that experience, then to them having the code as open source.
And then kind of keeping up with the corporate ways of doing things.
Whatever we do is open source because our code is in an open source repo.
Our issues are open.
So the fact that, for example, we had our internal meeting first and then we summed it up at the community call, it should be totally fine, right?
Or, no, we don't like the chat platform.
Let's just use the meaning list when we have time to look at it if we do.
Or helping newcomers is great, but maybe you could tell our boss to hire someone to do that job.
So, time a little examples that I saw in projects happening over time when people again just get thrown into the deep ocean.
Or, if you go, come on swim. So it's not that easy. Open source is very counter-intuitive.
So learning how to do that swimming upstream is not as easy as it looks.
What else does happen? Things like these ten-class maintenance type of jobs like documentation.
I heard, I think, not one people saying that, well, my company pays me to work on open source and my priorities to work on features.
That's what the company wants. Maybe they want also box fixes.
But that's kind of where it ends when it comes to maintenance, maybe fixing some bugs.
But when it comes to writing and maintaining documentation, well, this is not part of my responsibilities according to my manager.
And then this can go wrong. At least in two ways, one, no one does documentation.
Job, maybe outside of documenting their feature.
But if the project's documentation is not really kept up well, maybe that doesn't happen because where would I even put it?
And then, if no one does that job, then, you know, the project does not have documentation or the person might say that I really think that we should have some,
at least the baseline level of documentation here, and then they do that work in their free time.
And if that eats into most of their free time, then people tend to burn out who take on these responsibilities.
Then taking down streams into consideration, which is important.
So I'm not saying that if you work on behalf of a company on an open source project, you should not think of what's in the interest of your company.
But if everyone only thinks through these lands and through this mindset, then this can really easily become a bottleneck.
Because, oh, that's not deprecate things until my company and yours and yours and yours finish all the things that we need to do.
Or wait until we make this decision because we need to ask our companies.
And then these decisions just getting pushed and pushed and pushed, and then they don't get made.
So all these delays and, like, built a bottleneck, become a challenge for the project to be able to move forward.
So representing companies within projects is important, but when it starts to become a bottleneck, and the community starts to think in terms of downstream stakeholders, as opposed to users.
And companies who rely on your project from whatever perspective, using becoming a being a vendor, there are so many ways of utilizing all the source projects, then you are creating a bottleneck for yourself.
And it's really hard to get out of that bottleneck because, as you can imagine, every single company based on in what shape of form they are relying on that project had very different approaches to things.
Some like to be on the latest release, others are dragging their feet, and they don't want to move forward fast. What happens with the dependencies then, do we move forward, do we not move forward in the upstream project, very, very easily becomes a problem.
It's very important to do mentoring and talking about official mentorship programs with universities or things like outreach, Google Summer of Code, there are a lot of great programs who help either the next generation who is currently growing into tech to get into open source and build up their network and build up their knowledge.
All the skills that they will need to be successful on the job market, and then you have professionals who might be looking for a career switch, a little bit of change, update and direction, and they can benefit from mentorship programs.
If you don't have anyone in the community who can do the mentoring, then these programs cannot move forward.
And in my experience mentoring is always a great experience and a great learning experience both for the mentor as well as the mentee.
However, very often you hear that I would really love to become a mentor but my manager didn't let me again.
So what does the person do then? Sometimes they might deal in there again free time which again can lead to burnout or something needs to change.
And see I as a mother example that I will not even go into huge detail here. For example, we do have a there's a community in the under the opening for foundation is called Open Dev.
And they are volunteers who are maintaining the the test infrastructure and gaining infrastructure and tooling for the opening for communities and I'm talking about handful of people.
So just because your company doesn't provide donate machines for the CI test, it doesn't mean that a person cannot work on and help out maintaining and debugging CI.
Even in the open dev community, the handful of people they are not all or maybe they are not at all from those companies who are donating to hardware itself.
So you don't necessarily have to work for those companies, but without testing, active testing and CI infrastructure and community infrastructure tooling, the community will not be sustainable.
So where do we go from here? And by the way, there are more examples I just picked these ones for today as kind of showing you what kind of downstream inspired dilemmas are out there.
So for those who have not yet taken ownership over their projects, this is the time because if again, we are looking into the small handful of people who do all the hidden thank less maintenance jobs.
There's a lot of talks around about burnout and things. So I think that the concept of community hat needs to come back a little bit because in my experience again working with numerous communities, the community hat seems to disappear sometimes.
More and more corporations get involved, they need to people need to understand what it means to take care of the open source project, the upstream project, because it's the people's responsibility who work on those projects, it's not the companies responsibilities, the people's responsibility, however the companies need to let the people to work on those.
So the question is if you as a person who is actively involved in the community working on code documentation, mentoring, organizing meetings, doing whatever you do, if you don't feel that you have ownership over your project, you have the decision making power.
Who will be the person who takes on that responsibility? If you doesn't matter what level you're involved in, you don't have to be a maintainer to feel that this project is something that is your responsibility too.
You don't have to be paid by a company, you don't have to be a volunteer, everyone who is involved actively involved in a project, this is your time to take ownership and think about what happens with this project. How do I make this project sustainable? How do I make this project welcoming?
How do I as a person ensure that this project, this community will exist next month, next year, 10 years from today?
And in my experience, this gets very challenging when people are involved on behalf of their employers, because then the company priorities, very often take over, and the company processes take over, and the company barriers tend to take over, and people just forget that the community had exist.
And with all the bottlenecks and issues and the maintenance jobs being left behind, that will cause problem for the community's down the road.
So, something that both individuals and this is a message to dig back to the company as well, that companies really need to understand is thinking a little bit longer term and making the best decision for the open source project will be the best decision for the company, because if the project is part of the product service that they're offering and taking to the market, then if the project crumbles under itself, then the product will crumble as well.
And I don't think companies are really out there wanting to fork everything and maintain everything in-house and not having the open source version out there at all.
I've never seen that as an objective, not saying never, but in most cases, that's not the objective, that's just the result of missed opportunities.
So, just because something is not an immediate benefit to the company, for the sustainability of the open source project, it will become the benefit for the company as well.
So, what do you do from here? Like, you can go and look for the windwind solution, like you need to deprecate something, find the middle ground that mostly is reasonable, the community is not going to crumble, so don't deprecate it next week and don't deprecate it 10 years from now.
Something in the middle that feels reasonable, but as again, the contributors and maintainers of the project that decision is yours, not your companies.
And other simple things, yes, we already established that it's hard to maintain documentation, however, spending a little bit of time to build document and publish processes that the community has, will make it easier for you to commit to them and telling your company what job needs to get done and what they will need you to be committed to.
I did have a conversation with someone last year or a year before I had a conference, I think they had some challenges with the leadership continuity, and it turned out that they didn't have it documented what kind of leadership positions they have, what it takes to do that leadership position, how someone can get into that leadership position.
So they have really hard time to finding people replacing those who just felt really, really burned out by that point, so spending that little bit of time of documenting what needs to get done, you can figure out how long it takes, you can go and lobby to your company that, hey, this needs to get done.
It should fit into my time because these are the responsibilities, this is how long it's going to take, so you can commit and it will be transparent for you, for your company and the community as well.
And I talked about thinking in the context of downstream stakeholders and talking about customers, community meetings just replaced those terms with users.
And then the horizon opens up a little bit and you won't just think about those companies who are involved in the meeting, but you will think about others who are using your project out there.
So things like backwards compatibility and some other, you know, refactoring some code and doing some maintenance, my pick on something that is a little bit higher priority than it wasn't the past.
So who are involved in the open source project on behalf of the company, I work for nonprofit, I would love to talk to your boss, but I usually don't have the contact information of your boss and then your boss may or may not want to talk to me.
Because your opportunity and a little bit of responsibility to go and tell them why all these things are important and why if these things are not get done will become a problem to the company at large and how that will become a business risk for them.
And then you can try to based on what the company does put a little bit of hopefully that your company has good practices. So putting it side by side with what the community needs to get done what the company gets done internally.
If you put that side by side and then you can show what's missing in the community that the company always does for their products.
Well, the upstream project is kind of like a product. So if something gets done downstream internally, why is it left behind as a responsibility upstream.
So try to talk to your management, your company in the terms that they understand. So if they understand how the internal processes work, you can map that to the upstream processes and community and help your management understand how that community process works and why you should be one of those people who picks up some of that stack.
Last but not least, I'm personally very fortunate because I work for a nonprofit and I do community management. So I have a totally unbiased view of all the things happening in the community.
It is very rewarding and it is also very thankless job all built into one, but I have that lucky opportunity to walk in and say that my priority is figuring out what is missing, what is challenging for the community that would prevent them to be sustainable and be successful in the like reaching the goals that they set for themselves.
I'm lucky. However, I'm not saying that if you need a community manager for your project, then I think it was too talks before.
Fatiha and Ray were talking about company backed projects. You can work for a company and be a community manager.
The base I need to be my company doesn't exist, but having people who look at the community and say that my responsibilities to have the community running, then please take on those responsibilities.
And find me somewhere to chat a bit more about this. That's all I had for you today.