WEBVTT 00:00.000 --> 00:11.000 All right, folks. Thanks for your patience. This next talk is about upstream and downstream 00:11.000 --> 00:16.000 tensions and why there's so common even when everyone has good intentions downstream 00:16.000 --> 00:21.000 needs shipping and stability. And those can collide with upstream norms and priorities. 00:21.000 --> 00:27.000 And that friction can wear teams down if it's not handled well. Please welcome Adilko 00:28.000 --> 00:33.000 Vancha. I got it. For practical look at how these dynamics show up and how to help teams work 00:33.000 --> 00:42.000 through them. Thank you. Thank you all for making it for my session. 00:42.000 --> 00:49.000 So today I will talk about some challenges and dynamics and open source communities 00:49.000 --> 00:55.000 that are somewhat driven inspired by corporate involvement, which is by the way very encouraged 00:55.000 --> 01:01.000 and welcomed but sometimes again there are some dynamics that go a little bit off-row. 01:01.000 --> 01:06.000 But before I go into all that, first of all I'm really bad at keeping myself on time. 01:06.000 --> 01:12.000 So there are so many ways to catch me if you cannot catch me at the event today here in person. 01:12.000 --> 01:17.000 Please reach out. And who am I and why am I talking about this topic? 01:17.000 --> 01:24.000 So I am director of community at the opening for foundation, which is a non-profit organization 01:24.000 --> 01:28.000 supporting open source communities like OpenStack, Kada containers and many more. 01:28.000 --> 01:35.000 And I'm also a personal individually enthusiastic about open source. 01:35.000 --> 01:42.000 So because I have so much free time, no I don't. But I still became the creator host and soul 01:42.000 --> 01:47.000 maintainer of the my open source experience podcast. So if you want to hear about topics like this 01:47.000 --> 01:52.000 or other topics about the mechanics of open source, tune in to that one. 01:52.000 --> 01:57.000 So without further ado, what is this talk about? 01:57.000 --> 02:05.000 So I started an open source and started an open source as in finally getting involved in open source 02:06.000 --> 02:12.000 a bit over 13 years ago. And I started that as part of my paid job. 02:12.000 --> 02:22.000 And over the course of this 13 years, I transferred from my corporate paid job into the nonprofit paid job 02:22.000 --> 02:30.000 and worked with numerous communities over time. And kind of experienced open source becoming not just mainstream 02:30.000 --> 02:35.000 but even more mainstream. So you see companies, open sourcing their projects. 02:35.000 --> 02:40.000 You see companies getting involved in open source projects, which is amazing. 02:40.000 --> 02:45.000 And I still think that there are so many companies who should get on this train and get involved. 02:45.000 --> 02:54.000 But sometimes it happens that their people get kind of thrown into this big ocean of open source 02:54.000 --> 02:58.000 without even being asked if they can swim. 02:58.000 --> 03:08.000 And then it becomes a challenge in so many ways for the individuals, for the communities, or both. 03:08.000 --> 03:11.000 So what kind of things do I mean? 03:11.000 --> 03:19.000 For example, this is one where one, two, three companies, all of a sudden that's open source 03:19.000 --> 03:22.000 this project for whatever motivation they have. 03:22.000 --> 03:26.000 And then there are the people who have been working on that code. 03:26.000 --> 03:32.000 Up until the point of all of a sudden, the code is getting uploaded into a public repo 03:32.000 --> 03:36.000 and all of a sudden they are supposed to work on an open source project. 03:36.000 --> 03:41.000 So how many ways do you think this can go wrong? 03:41.000 --> 03:45.000 And by the way, does anyone have this particular experience? 03:45.000 --> 03:49.000 Or do you know anyone who's being in this boat? 03:49.000 --> 03:52.000 All right, we have a few people in the room. 03:52.000 --> 03:59.000 So there are so many challenges that I will, I could spend the whole presentation, just on this one. 03:59.000 --> 04:10.000 But the challenge really is that when people don't really get the opportunity to learn about open source values, practices, processes, 04:10.000 --> 04:24.000 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. 04:24.000 --> 04:29.000 And how do I build a community around that open source code? 04:29.000 --> 04:34.000 Because open source is more than just the code and the license is. 04:34.000 --> 04:43.000 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. 04:43.000 --> 04:47.000 And then kind of keeping up with the corporate ways of doing things. 04:47.000 --> 04:52.000 Whatever we do is open source because our code is in an open source repo. 04:52.000 --> 04:54.000 Our issues are open. 04:54.000 --> 05:02.000 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? 05:02.000 --> 05:05.000 Or, no, we don't like the chat platform. 05:05.000 --> 05:10.000 Let's just use the meaning list when we have time to look at it if we do. 05:10.000 --> 05:18.000 Or helping newcomers is great, but maybe you could tell our boss to hire someone to do that job. 05:18.000 --> 05:29.000 So, time a little examples that I saw in projects happening over time when people again just get thrown into the deep ocean. 05:29.000 --> 05:38.000 Or, if you go, come on swim. So it's not that easy. Open source is very counter-intuitive. 05:38.000 --> 05:44.000 So learning how to do that swimming upstream is not as easy as it looks. 05:44.000 --> 05:54.000 What else does happen? Things like these ten-class maintenance type of jobs like documentation. 05:54.000 --> 06:03.000 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. 06:03.000 --> 06:06.000 That's what the company wants. Maybe they want also box fixes. 06:06.000 --> 06:11.000 But that's kind of where it ends when it comes to maintenance, maybe fixing some bugs. 06:11.000 --> 06:19.000 But when it comes to writing and maintaining documentation, well, this is not part of my responsibilities according to my manager. 06:19.000 --> 06:24.000 And then this can go wrong. At least in two ways, one, no one does documentation. 06:24.000 --> 06:27.000 Job, maybe outside of documenting their feature. 06:27.000 --> 06:35.000 But if the project's documentation is not really kept up well, maybe that doesn't happen because where would I even put it? 06:35.000 --> 06:45.000 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, 06:45.000 --> 06:51.000 at least the baseline level of documentation here, and then they do that work in their free time. 06:51.000 --> 07:00.000 And if that eats into most of their free time, then people tend to burn out who take on these responsibilities. 07:00.000 --> 07:08.000 Then taking down streams into consideration, which is important. 07:09.000 --> 07:17.000 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. 07:17.000 --> 07:28.000 But if everyone only thinks through these lands and through this mindset, then this can really easily become a bottleneck. 07:28.000 --> 07:36.000 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. 07:36.000 --> 07:41.000 Or wait until we make this decision because we need to ask our companies. 07:41.000 --> 07:49.000 And then these decisions just getting pushed and pushed and pushed, and then they don't get made. 07:49.000 --> 07:59.000 So all these delays and, like, built a bottleneck, become a challenge for the project to be able to move forward. 07:59.000 --> 08:17.000 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. 08:17.000 --> 08:33.000 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. 08:33.000 --> 08:46.000 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. 08:46.000 --> 09:04.000 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. 09:04.000 --> 09:31.000 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. 09:31.000 --> 09:48.000 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. 09:48.000 --> 09:54.000 If you don't have anyone in the community who can do the mentoring, then these programs cannot move forward. 09:54.000 --> 10:05.000 And in my experience mentoring is always a great experience and a great learning experience both for the mentor as well as the mentee. 10:05.000 --> 10:13.000 However, very often you hear that I would really love to become a mentor but my manager didn't let me again. 10:13.000 --> 10:26.000 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. 10:27.000 --> 10:42.000 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. 10:42.000 --> 10:57.000 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. 10:57.000 --> 11:13.000 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. 11:13.000 --> 11:21.000 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. 11:21.000 --> 11:34.000 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. 11:34.000 --> 11:49.000 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. 11:49.000 --> 12:07.000 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. 12:07.000 --> 12:26.000 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. 12:26.000 --> 12:47.000 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. 12:47.000 --> 13:04.000 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. 13:04.000 --> 13:22.000 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. 13:22.000 --> 13:41.000 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? 13:41.000 --> 13:50.000 How do I as a person ensure that this project, this community will exist next month, next year, 10 years from today? 13:50.000 --> 14:17.000 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. 14:17.000 --> 14:28.000 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. 14:28.000 --> 14:57.000 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. 14:57.000 --> 15:07.000 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. 15:07.000 --> 15:18.000 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. 15:18.000 --> 15:29.000 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. 15:29.000 --> 15:49.000 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. 15:49.000 --> 15:59.000 Something in the middle that feels reasonable, but as again, the contributors and maintainers of the project that decision is yours, not your companies. 15:59.000 --> 16:25.000 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. 16:25.000 --> 16:46.000 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. 16:46.000 --> 17:05.000 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. 17:05.000 --> 17:17.000 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. 17:17.000 --> 17:30.000 And I talked about thinking in the context of downstream stakeholders and talking about customers, community meetings just replaced those terms with users. 17:30.000 --> 17:41.000 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. 17:41.000 --> 17:56.000 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. 17:56.000 --> 18:12.000 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. 18:12.000 --> 18:33.000 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. 18:33.000 --> 18:47.000 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. 18:47.000 --> 18:55.000 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. 18:55.000 --> 19:10.000 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. 19:10.000 --> 19:36.000 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. 19:36.000 --> 19:49.000 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. 19:49.000 --> 20:17.000 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. 20:17.000 --> 20:27.000 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. 20:27.000 --> 20:35.000 Fatiha and Ray were talking about company backed projects. You can work for a company and be a community manager. 20:35.000 --> 20:54.000 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. 20:54.000 --> 21:01.000 And find me somewhere to chat a bit more about this. That's all I had for you today.