 Thanks everyone for joining and first thing to you almost the end of the open source summit. So one of the last sessions and yeah, it's about projects on set. So what a good ending or close to the ending of the Osprey con sessions. And what I will be telling you about, my name is Devkanimitrava, I'm a senior program manager in the Ospo which in VMware. So I'll be giving some steps and some hints on how to sunset open source project and what I've learned. I learned actually many things in this open source summit. I hope you all can confirm that. But I've been reminded not to use so to be careful by using words simple, especially when I give some guidelines or restrictions because what's simple now to me after doing that for three years or more driving that program that I called getting orders of about sunsetting around a Hiving in Active project might be or not be so simple for anyone else who is new to the topic. So I'll start with quick introduction about myself. I already mentioned my position and my role within VMware where I'm part of the open source community strategy team and the one foster here is my manager, which I'm really happy with. And actually I have a financial and business background, although I'm already for 10 plus or minus years into the software development industry, I tend to still think in terms of costs and benefits. So you can see why this topic is so important also for me to be clear about what to archive or what to keep active. And I have also many other passions like climbing, mountaineering, experiential education, working with kids on different topics. And after all, I need to balance it all. So that's why I like really to keep things simple. And that's also the only way for me in some case to keep doing what I love doing. So the agenda is actually the steps that I will guide you through, which I've developed through developing the program and then experimenting, adapting, which are, yeah, of course, start with know why you need to have some setting process or why you need to duplicate a project than what you have. So it's not easy to understand always what you're starting with in terms of projects or who to contact, especially within Ospo's context when we're dealing with more projects or larger portfolios, then decision making point where, whether to do that, who is depending on that, who needs to prove it and communicate it all and do the actual archiving. Be prepared to an archive. And all of this, it's actually the presentation, but why I need the other 35 minutes. It's because like with every beautiful sunset, it's usually before and after a storm that's coming around. So you might expect things to go wrong or on the way. And as I've experienced that, I can just share some of the learnings that I have. So starting with the why should we be proactively checking on inactive projects and by we I mean either Ospo's. So just checking who is a member of an open source program office here in the room. Yeah, OK. And then if not in a program office, maybe working for more than one project or interested in more than one project, then this makes it monitoring and looking into the activity of open source projects a bit harder when you're not responsible for only a single one. So being proactive is also because what I've found out not only based on experience within the company, but also researching some more information and simply looking into GitHub data. And I invite you to do that for every project that you're interested in or every organization that you're interested in. Just check how long projects remain active after they're newly created. And by looking into a thousand plus repositories in some major companies within open source, you can easily find out looking at the last commit date or the push that date that 16 percent of them wouldn't be active. I don't say they are abundant because, yeah, that's further investigation needed to really confirm whether they're abundant or not. But they wouldn't be so active within after 12 months. And this trend continues and just over the first five years, you will see then 10 more percent will not be active than 9 more percent. So in the fifth year, half of the projects that have been started will remain to be actively maintained. There will be still contributors to that. So what does it mean is that if we are not prepared for that and if we are working with a larger portfolio of projects, soon we might end up with not really knowing what we need to prioritize and what not. And I was, as I said, I learned a lot during this week and I hope we all did. But I was also inspired heavily, like looking through the word of open source open source Europe data and I must admit I've not read it through because, yeah, hanging out with colleagues and with people I met here was a bit more important for me this week. But checking on the data of the research, it was really obvious that with larger companies, with the increase of the size of the companies, at first the freedom and the encouragement to contribute openly goes down. But then it increases again with the 10,000 plus employees and it's, or that's my interpretation again, it's mostly because of, and that's also what I've heard in the presentations about this research, it's because of declarative policies. So at first no policies needed, then the lack of policy gives people a bit of uncertainty whether they can or cannot contribute. And then with the larger companies, there is again the need of policies and the need of hospitals. So I could really relate that to the fact that within the larger companies, 10,000 plus, which is also shown in the research, there is higher possibility or higher needs to have hospital or a dedicated person with open source contribution. So what I conclude out of that is in a way this circle, so more freedom to contribute is of course related to more creativity, more source, more projects. But this then drives the need to prioritize these projects and then be able to have better clarity and better policies. And I relate that to the sunsetting of projects again by being actively and developing more and contributing more and open sourcing more. At some point we really need to have a clear policy of how also we are doing that in terms of how we will manage it and whether we will sunset some of it or not. And it's here to know why it's also important, especially if you are like me or the person who needs to convince others that they need to consider deprecating some of their work. And it's hard conversation sometimes because it's a work that someone might be emotionally attached to. So knowing why and the benefits behind and being able to justify, of course, adapt the reasons because at first when I started this program I thought that it will be a great source of knowledge base to prevent deprecating projects. But after all, not everything can be prevented and it shouldn't be because this part of innovation that companies allow their employees or that individual contributors to experiment more and not everything will eventually succeed or become adopted. So having some of the projects being archived is just part of the life cycle and knowing that we will be more, yeah, less attached to having that necessary remain active. So one of the other reasons maybe just reducing costs of course and maintaining but also cleaning up space and by that I don't mean only like the space between GitHub or space as something material but also space in terms of having time to consider some alternatives and don't have the stress or space in the to-do list can be as well. So now when you're certain why you start to approach on some setting a project, it's tricky sometimes and it's again most for OSPOS or for people dealing with many projects to know so where to start with, so which are the projects that might be potentially inactive or I call them sometimes archive candidates and who to contact for in different cases. And yeah, and actually the picture might be pretty complex but what can help you to identify the potentially inactive repositories would be just sorting them out at first and that can be as simple as especially if you have a large amount of repositories like hundreds or thousands of repositories that's responsible for in any way, you can filter them out first by the last commit date or the pushed at date which is information you can easily see in GitHub. Then of course that just shortens the list, still there is a lot of work to be done because that can be the simple indicator. If the list is short enough to reach out to each of the projects individually that's the best option and that's sometimes always what I prefer to because then in conversation with the teams I don't not only understand the background of why certain projects that doesn't have commits in the past year or what the plans are, where they're going, do they need any assistance guidance from the open source program office but it also just speed up the process because everything else is kind of an investigation which takes more time if I do it offline than with talking with people. But sometimes there is a larger number of projects and then it's harder to really reserve the time to individually contact each person. So another filter would be checking on open PRs, issues, security alerts, so anything that might be an indicator that the team or the person who were working on that project were not actively or they might not have the resources. So that's actually the most common case from my observation and for the research on deprecated projects and I've talked about that in open source submit I think it was two years ago because it was virtual. That were some of the common reasons, so either lack of resources, lack of time, shifting priorities, but also it just doesn't hasn't been adopted. So here it's the link on the bottom is actually the script that Dawn has worked on as among many scripts, of course one of them were again to just have some of these data attend especially when you're working with more projects and I will reference to that also a minute later because it also helps when you're taking the decision of whether or not and checking on dependencies. Which is actually one of the next steps but first if you have decided or you have a short list or one project that you know you need to archive or to reprecate next question would be whether to keep that separate or not so is it is it enough to just click the button and say archive the project if that's on github or github or any other instances or is some more work or preparation needed and again in our experience in my experience as I was working with more project this was the better option was to keep things separate keep active any active project separate and there might be various reasons to do so some might be just costs because creating a new github organization that has no members and no activity there might be much more costly efficient than keeping all that on an older organization that can help you also easier to sort out members that are no longer active or and just just help you deal with access to these repositories although archiving can give up actually gives on read it on access so that that's pretty simple and doesn't break any links but we decided and and I'm happy to that went to that direction to create an organization that's called in our case VMware dash archive and this isn't also easier way to show to the community that this is an archived project and this was a one of the goals that I might have not mentioned but it's one of the main goals actually where you want to archive a project it's not all only because you don't have the resources or don't want to spend any resources on the project but you need to want to be transparent to the community around that so it wasn't the slide but I didn't mention but it's a transparency of what's active and what's inactive and and making sure that the community that will rely or might rely on that project will know that you'll not have the resources to actively maintain it which is the next point before the decision is taken whether to archive it or not and this is the again checking on and they are well even in cases where maintainers have confirmed so happily or happily that they they would want to deprecate their projects have you experienced such cases so who has experienced such cases then you needed to close up to close up or deprecate project that they've been actively working for some time on just curious yeah okay so where yeah it's a well it's not an easy decision but if even if you've taken that decision you can't always do it you need to check first who is depending on on that project and yeah some again some of the easy ways to check this contributors users forks criticality score that's a Linux foundation score so you can check it it helps a lot it goes through all this and also other indicators and can give you a score showing whether that's high again it's a probability that it's it would be critical if you deprecate that project or not whether that project is critical for others and I'm again referencing to to the to the viewpoint the script just if you are interested to help you check on certain repositories that are you are interested in and then yeah depending on the organization approval might not be needed or not where you go to the next step which is okay I decided I confirmed to deprecate a project I have all the approvals if I need any for example of the chief open source officer in the company if there is such a role or or simply by the maintainer or the other maintainers or within the community what what I do next do I just archive it again not always the best option just because it's better to communicate it first with the community in a way update read me reference to another project if there is such a project that you have moved on that's doing similar and that would be useful for the users of your project just reference it also use mailing click slack slack channels other media that would would be relevant for your project update web pages and wikis where that project is mentioned and this is important here to talk with companies again with branding marketing team because they know best where and for for more strategic larger projects in the companies there might be materials around that or information spread around that they need to consider if that project is no longer active to not advertise it openly and then we archive it which is probably the easiest steps well github provides the option to archive for repository I mentioned and it becomes read only access so it takes care of the access similarly in other I would advise to create a separate space to move it somewhere separate and this is also in a way to to make sure that if you and again I encourage you actively working into project health metrics monitoring the status of your active projects then you shouldn't have all this data for projects that are not active any longer it just saves time and and also security alerts or any other waste any other activities that actually take time and take energy to monitor you couldn't exclude all the unactive archive the deprecated whatever you call it project from that activities and this will save your energy for what's really prioritized for you and as I mentioned having all this done in some cases you need to be prepared to undone it and try to bother so much to do all the steps where you're allowing the door to be open back and to revive the project so at first it happens so it might happen that you have missed important dependency or that someone who is interested in that project want to pick them up and would be willing to revive it so it's good to have a process that will follow you through the steps and say it will be similar to the process if if you have some in mind about creating new projects going through a compliance check a license file there is it contributing contributing file is it up to date code of conduct do you have any code of conduct do I need to work on something else it's just similar checklist as if this is a completely new project because it might have been archived for a long time so there might have been things that have changed in between and also again check on security check on any other issues make sure that when you're bringing it back to life it will be a good healthy project and the other reason to have such a process what I've experienced it that's sometimes the tipping point when I talked with with a team that's considering whether to archive or not so they're me that they don't have the resources they admit that they won't be working on that for probably in the next year even but they hope someday they'll have the time that's usually that hope that so I if you are like me I still have that pair of jeans that I keep that I hope that I will wear someday but it's still there and takes takes place so it's like similar hope that okay I will find the time and I work on that or I will hire another engineer that will help me and to be honest that has hardly ever happened to bring a project back but giving that back door open and giving that promise to myself also because that's I've I've tricked myself also when I want to clean up things in my life in my work so more work or just in some other areas that I'm interested in allows me to better take that decision and yeah and with doing these steps what you next do is repeat them and that's that's really important because it's not one of activity it's not like okay I do a cleanup and and I also was naive enough when I first started the program to call it getting order because I thought okay I will I will put everything in order and that will stay in this way but no I do that every quarter mostly mostly of course there is ad hoc activities like merges acquisitions onboarding of teams companies that would require this check just just initial check and when you do that initial work is always harder than when you do that follow-up and only only check on certain projects that you have highlighted maybe or you've talked with the teams and they said well maybe I'll come back to it but I'll tell you next quarter and then check with them again next quarter so it's an iteration every time so go back through the process adapt some of it of course and yeah be really be be open to that conversation of costs and benefits I come back to the yeah to the finance background but it's again it costs not monetarily only but in terms of time energy spent just again to the freedom to experiment with something new or to to take more yeah to to to take or to prioritize some of the other projects which which someone would expect that they will bring more value and with that I'm actually uh yeah I've repeated the steps so I'm actually open to any questions that you might have yeah sure well I've I've actually experimented around that so at first I was considering having 18 months as like the date so if there was no commit 18 months so within 18 months then probably it's an active and then I started shortening the period because at first within these 18 months when I had like initial reviews it was sometimes too long ago to find out who has who has last work on the project so I just out of experience learned that like 12 months it's a better short frame so like with 12 months it's good to check it's not it doesn't mean that projects become inactive or are really inactive if they have not have any there are there are many many libraries that they're just stable so we don't really need to do much work on them if teams work on the issues and the PRs they don't really need to commit any code but with all this also security and other versions dependent dependencies updates it's just like kind of a red lamp and it says okay check with that project and yeah and maybe I will short on the time frame if I see that it's 12 months it's a bit too long it's also the way also the community develops and now how the projects work yeah yeah the contributor comparing to the user of this project when they are uh because they would spend the time and the passion in it but like this contributor have uh have enough passion to continue this project but there uh maybe programming still is not enough maybe they just focus on the documentation part of work but you the who well mainly control the program cannot continue do you think what is the good way to do with that contributor uh so I forgot to repeat the question but now I will try to rephrase it so the question is where uh what is the best way to work with the contributor if the project uh if they probably don't have uh the skill base or there are some other reasons that they don't work on the project I mean that how can you communicate with them yeah these well these are in the different projects and in different communities instead of settled in different ways so there are there are projects that they have have worked on the communities have worked on governance governance documents on how to exactly for these cases how to onboard new people how to teach them into maintain a role in other projects mostly when they're smaller or new and they've not considered that then you can learn actually from other people's example and see and just develop and use some of these examples because uh what I've seen is that uh everyone is happy when they decide to give up the project for whatever reason the maintainer or the originator or yeah the current maintainer or the originator that they don't have the resources to work on them they're happy if anyone else is interested so uh yeah it might not be always the case that they have time to onboard that person but they would at least be happy to to start that conversation and then individually to decide it so so I would encourage to uh for everyone such a situation to reach out to the maintainers say that they're interested and then they can negotiate in some time to work through that onboarding process okay continue your project but maybe one day you want to continue your project again well this again depends because in open source and in upstream philosophy so forking it's not always the the best option so if they can come along and continue working but if the company policy doesn't allow that that external person is a maintainer of a project that's being originated by the company forking might be the only option yeah as as you mentioned so again depends on the use case thank you and I think you had a question or well that factors in a lot and that's actually the step that I was uh previously going through in the decision making whether to do that so if it's and that's also our role as an open source program office is also to to to help in these conversations because it's not always everyone in the company understands the importance of a certain uh piece of open source software so then uh program office is supportive yeah we we need to help with that conversation and to to make sure that uh yeah this is really considered into the decision whether to continue or not and I completely forget to repeat the questions but I would try to try to summarize actually what Adam shared as an example was that when he started Harold project as part of the yeah as an open source project originated with the company but as you mentioned it's uh not a project that it's like strategic in terms of the VMware strategy in terms of open source it was also so he continues working on that it was donated to um to uh to the foundation so uh he could continue and he does really actively continue working uh on the project as a VMware employee yeah yeah yeah that's that's another case so what uh so what we actually also uh well it's it's different in each company so I try to I would try to generalize because there will be different use cases but uh uh you might be uh contributing to as part being in the company you might be contributing or someone might be contributing to a project in their personal time but still needing some um approval from the company to do that contribution and it's not only company policy it's sometimes country policy and through country legislation so that's that gets complicated when the work has started within the company and the company doesn't want to deprecate it then it's it's it's always best to advise within the certain uh program office or whatever uh experts in that environment is to and as I said it's always advised to if there is the interest to continue working on that project and to encourage a person to continue working that project and uh and again it's a conversation not all managers would understand if they don't have the open source background but yeah you can work with some data and justification why that's important for the community and help them understand that it's uh it's in the uh it's the win-win case so actually we're looking for the win-win game in uh in open source but those in all business that's the only game that it drives people forward any questions I think we only have two minutes or one minute three minutes okay so if not I really thank you all and uh I just wanted to share by putting so much pictures of sunsets that I that mostly I did well actually all of the pictures were mine the other sunsets some of them had sunrises so you can hardly tell what what the sunset and what the sunrise is and that's usually what happens with the beautiful sunset we have then there is a beautiful sunrise so we can't have the one without the other so don't be afraid to close something that's not active when you have the energy enthusiasm for something else so thanks everyone