Level up your project: The open source challenge at the Eclipse Foundation

This talk discusses how to elevate open source projects within the Eclipse Foundation by focusing on community engagement and sustainable growth. The speaker, Marta Teresa Delgado, emphasizes that successful projects require more than just code; they depend on active community participation, transparency, and clear governance. Delgado highlights the importance of adopting best practices, such as regular releases, open communication, and inclusivity to promote collaboration. Furthermore, she introduces the idea of measuring project health through a traffic light model, which will provide insights into areas needing improvement and encourage the adoption of good practices while fostering a welcoming environment for contributors.

Hi, welcome. Thank you for being here. Um Welcome to this talk. It's called level up your project at the open source the open source challenge at the Eclipse Foundation. Um just a quick word about me. I think most of you already know me, but I am Marta Teresa Delgado. I I work with the Eclipse projects every day to strengthen their long-term health. And what I do mostly

is identify which are the good practices that have worked for as long as the Eclipse Foundation has been founded and is working. And I kind of translate these practices into action actionable items that you can implement in your day-to-day life cycle. Okay? Today, I would like to talk about how we can level up our projects at the Eclipse Foundation. And this isn't about perfection. It's about understanding

what really helps projects grow, stay active, and remain welcoming over time. So, what kind of helps you being sustainable over time? Um think of this as a journey, not a destination. It's not a switch on switch off one event, but it's more like a sustained effort over time that you need put into your project. When we talk about open source, we often focus on code, right? We

think it's just software. Um probably most of you already have open source projects. Can you raise your hand if you already have an open source project? I know you. Yes. I know that. Uh but those of you who are thinking about going open source or about bringing your project to the foundation, please know that is so much more about code. well, we've heard keynotes from our speakers

about AI. So, code is everywhere. Can be generated by basically anyone, even people with absolutely no knowledge of. um main takeaway here, great projects are actually built by people, not just pull requests. it's the contributors, it's the discussion, it's the interaction, it's this community and the way we interact with each other what keeps uh projects active and makes them sustainable over time. Small daily habits will keep

your project alive and will help shape this long-term success that you are all trying to achieve. code matters, but at the end, collaboration is what sustains it. So, the big question, what makes a project work? Um I forgot to mention something. We are talking about projects that have already chosen to go open source, right? Uh you've chosen an a pre-approved OSI license, you have come to the

Eclipse Foundation or are thinking about coming to us. You have done trademark uh checks, you've done you've you've cleared, you know, the initial checklist that we have in order to um onboard your project. So, once your project is created, why do some projects flourish while others stall? What signals real health? And how do we make projects welcoming at all times and sustainable First of all, like I

said, open source software is a journey, not a growing an open source project has some implications. A project evolves and when it reaches maturity, it's usually not a fixed state. Continuous improvement is key. What matters is that is that you keep always moving forward even in small steps and we need to think about this as progression and not perfection. If we combine this with um what we've

identified as the three core values of um and we bring them as the Eclipse Foundation principles, we are already in a good path, right? So, um which are these principles? You've heard Mike talked about them. You always will hear us starting our presentations with these, but they are really really important and uh even if they seem simple, they are not so simple to implement. So, it's really

really important that you remember these: openness, transparency, and meritocracy. Um they might seem to be overlapping, but they're not. So, being transparent is choosing public communication channels to do all communications related to your project to your project, open um public repositories like the ones we provide when you bring your project to the transparent decision-making, open decision-making, right? So, again, engaging with your community, putting things in the

open so they're accessible and reachable for everyone. Being open though, it's a little bit different. Being open means that you are being open to newcomers, new ideas, and that you are actually thinking and prepared to give up full control of your project because it's a little bit like having a child. Might be an overstatement, but um you bring your project to the community, but if the community

likes it, the project might evolve in a way that you didn't foresee at the beginning, right? yes, pretty much like uh parenthood or motherhood. Um this this model that is based on openness and transparency of of course meritocratic contribution, which is not always easy to follow or to understand because sometimes funding is not uh vendor neutral. Um helped us reach this vendor neutral collaboration model that we

have. So, at Eclipse of Nations, one of the things and the key messages that we're always trying to pass to our projects and community is that that are part of project teams need to earn their way in by providing some meaningful contribution. This might not be just code. Like I said, code can be generated nowadays by pretty much anyone. So, it's about actually adding some value to

your project. Might this a collaboration, a thread, a comment, a discussion, challenging something in your project, or even just making a commit of something that might be uh useful to evolve your project. Okay, these principles all combined create this stable environment where you can foster collaboration and this this model can thrive. At the core of everything, of course, there is the community. Every successful project has a

healthy in in its majority. Um it's not just about how many contributors you have. You have to know how engaged they are. Active contributors drive momentum around your Diversity is also important. Different perspectives make projects stronger and more resilient. And this is diversity in the meaning that um you get more than just one company sitting at the table uh on the project teams of of your project,

right? this makes, like I said, uh they make projects stronger, more resilient, and of course um recognition encourages participation. Also, conversations are a sign of life, right? So, healthy discussions are even unhealthy discussions are a better sign than just silent. Okay? So, beyond governance, uh we are seeing certain habits in successful projects. We've identified very clearly, and it was interesting to see that someone actually used data

to identify some of these habits. A couple of days ago, someone presented uh its work um from a master thesis, and they were the same. And we actually didn't run any data on it. We just it's a feeling that we have at the foundation over the experience we had over time. Projects that thrive tend to release regularly, maintain clear and accessible documentation. So, openness to newcomers. It's

easy to enter, or it's easy to try to participate in the game of contribution, collaboration. They welcome new contributors, they're open to reply questions, to provide help, and they communicate openly. So, people are always up to date on what's happening at the project. None of these are particularly complex habits. Of course, you know, releasing regularly takes a lot of effort, I get that, but they are not

It's It's not complex. It's not something that It's difficult, right? Or difficult to understand. Uh but all of these small habits together, they make a huge different, and they can in the long run create a big impact in your project. Of course, if you combine all of these small habits that I just mentioned with the principles and you have a good governance and process framework, this is

even a better combination and this is where we step in, right? We are defining processes that reduce friction around your project. So, interactions around your project are easier because there is this well-defined framework or at least defined at foundational level, but then you get another one with your top level and your PMC and if you're part of a working group, even more, you know, that that the

the granularity of these processes depends on what you're doing, but um the more the better, I think. Open decision making builds trust. You learn how important trust is if you were at the keynotes this morning, it's basically everything about trust. So, if you're trustable, people will want to come to you, collaborate with you they they have faith in what you're doing, they know what you're doing and

they can trust you. Uh predictable workflows improve collaboration. So, if you have actually consider how the workflow or collaboration in your project is, you have periodic meetings, you have transparent communications, it's easier that just for example, developing in parallel in your own private repositories and doing a code dump every couple of weeks. And well, again, transparency attracts contributors because they're always up-to-date on what the project is

doing and it's easier to just jump in at any This when when things are predictable, these people are just more likely to engage, right? Okay, something that sometimes seems like it's bureaucracy or legal or administrative task is getting more and more important, right? I'm thinking that IP management is going to be huge thing with the CRA when it's implemented. Uh so, it's really about trust again. When

people use the project, they need confidence that the code is safe to adopt, that the liability is reduced to a minimum, or that the risk is slow. And at the Eclipse Foundation, we try to support this through processes like the um intellectual property due diligence uh process that is written. We have tools like the IP Lab that allows you to create automatic review request for your dependencies.

We have tools like the Dash License Tool that in combination with the IP Lab does this. Um these aren't supposed to be barriers. These aren't supposed to be a burden on your project. They're supposed to be enablers, right? They're supposed to help you and help us evaluate um your project to provide uh some some advice. They make it easier for organizations to adopt and contribute because the

risks are better understood and managed when you are actually vetting your IP. So, strong IP practices are in the best case scenario a sign of a mature and trustworthy project. In not so best case scenario, it's a sign that you care, at least. So, you're putting in the work, and that's also sending a clear message to your audience and your community. Something else that has emerged in

the past couple of years, security. No longer optional. It's a first-class citizen. So, we have modern open source software expectations. We need to have in our secure development practices, dependency awareness. They need to think about managing their dependencies, handling vulnerabilities, and having a a well-defined responsible disclosure process. Security is a part of trust, and trust, like I mentioned, is essential for adoption. So, these modern expectations are

not just about security, of course. AI is also a growing influence in open source. Um so, in this sense, this brings new opportunities, but also new challenges. We need transparency around AI-generated contributions. We need clear traceability of the code that's been generated there, and thoughtful, responsible use of AI tools. AI is, of course, becoming part of our ecosystem, so we need to adapt. Um I I have

to say we I think we're a little behind on this, but um this is also work in progress. We've uh released the first AI guidelines for the Eclipse Foundation projects, and it's something that is evolving, and I think will be evolving very fast over I'm going to introduce now what we're thinking for the next cycle. And is the Eclipse Foundation Eclipse Foundation projects core metrics. So, why

measure anything at all? Um well, because metrics can actually help you and us understand the state of your project health. It can identify risks in an early stage, and it can encourage adoption of good practices, the ones that we've in project that are beginning or even are in a mature state. There is a balance, always, because metrics must be useful, not be burdensome, and well, because I

heard this morning that whatever you kind of lots loses its value over time, right? Because we kind of find a quick fix for these metrics are not just metrics about code. They are supposed to provide some visibility into your project health and your project community. And they are supposed to support you in your project growth. So, we started exploring this idea of introducing this score, which is

supposed to be a very simple way of reflecting your project health. It's supposed to be based on real data from official APIs from the foundation and your repositories. Should use clear understandable signals and is designed to guide not to punish as most of our processes are because if you've gone through a review at the foundation, you know that we don't want to fail you. We're just trying

to check that some of the things that are actionable you have implemented in your project and this hopefully helps you being a little stronger, right? For adopters. So, this is this is a work in progress. So, if you want to collaborate with us, your input matters. I will not presenting a finished solution. We're inviting collaboration. This is I thought we were going to be a little ahead

with this work by this moment, but so many things are happening right now that this has been has lost a little priority. So, this is what we're looking to measure. These are the key dimensions of project health we've identified. Of course, documentation because you have to have good documentation if you want people to understand how your project works, how they can contribute, how they can collaborate with

you. A good release cadence. We're not asking you to release every quarter, but you know, a a that hasn't released anything in the past year is is not a good sign. Um review participation, this is about engagement with the Eclipse Foundation. Uh usually we have this issue in which even creating a project, we ask project leaders to subscribe to notifications, stay up-to-date in our very open and

transparent communications with them. And it's amazing you you wouldn't believe how many of them don't don't even know that there are there is a GitLab issue to track uh their project creation. So, yes, there is a little overhead, but I promise it's little and we've reduced it to a minimum. So, uh please uh if you if you're new to this community, uh do engage with us. I

know it's a little bit of a mindset change and I think I should be giving this talk at the automotive sector because it's just a different way of doing things. and it's not always that easy because you're used to doing things in the in a very closed environment. You want to be perfect before you deliver. You don't want to make mistakes in in the public because it's

just humiliating and this is just not the way things work at the Eclipse Foundation. Um we were supposed to be tracking repository and issue activity um and community engagement. This might be done by I don't know um we thought about checking the mailing list activities. comments, interactions on your on your discussions, GitLab discussions, for example, GitHub. And uh measuring also a little bit of the committer diversity

that your project has. Again, this is about having more than just one company sitting at the table in your project team. Not just, you know, having I don't know, uh gender diversity or some other diversity. It's about that's also important, but it's not something that we can even measure because we don't gather that data, so that's it. So, the goal here is to capture a holistic view

and not just one metric and to keep things simple. We're just thinking in terms of a traffic light model. Maybe with a number, maybe not. Someone suggested that a number is a bad idea because then projects will start, discussing about who gets a better number or something like that or maybe even questioning our proprietary algorithms. No, I'm joking, but um the idea is that um new people

or potential contributors to your project can come to your project page and see very fast what's the project health they are they're looking at, right? So, green healthy will mean that you have good documentation, that you have good release cadence, that you have active engagement in your channels. Um this will also consider the results of our yearly reviews, but this is not even if you don't do

reviews with us, I think it's important that you are active on your project, right? So, we'll get there. Every project will get to the one-year review cadence, but that's why it's not uh listed there. Of course, yellow will be warning. Um it uh signal that the diversity in your project is not very good. Maybe that you don't have a uh functional project team. So, we have projects

that have absolutely no project leads or maybe just one committer that hasn't contributed in 5 years, something like that. well, maybe you have pending IP due diligence, something that hasn't been solved in a long time. These kind of things. And red, of course, will give you the sense that something is off with your project and will help us also identify which are projects that could be considered

as candidates for terminating and archiving its resources. So, the idea is simple signals that still provide minimal meaningful insights. Um we're also including here some security related um metrics like S-bomb generation or IP due diligence, but um they will be combined somehow to provide usability. So, this is where you come in. We really want your input. Um if you feel like there is something here that we're

not taking into consideration, please reach out to us, EMO or myself directly. And what would be actually useful for you? For example, if you're thinking about, I don't know, finding a collaboration with another Eclipse project, what would you like to see? Like to understand how much of your effort is actually worth putting into that collaboration. that's that's it. And we I I would like to get your

opinion on if this just feels like noise or overhead to you or might be something that you think might help. I definitely think it can help, even not just your project, but the community outside your projects. So, at the end of the day, um this is something that we build together. So, uh we have to also act as a community here. And with this, I end my

very short presentation. If you have any any questions or if you have any questions at all about our processes, I'm happy to answer them. Okay. We've got a mic for the Yes, thanks for the this introduction. I mean, I think I found the metrics really helpful uh for all the projects, but also for uh, somehow checking the status also of the some other project that as you

mentioned may be of a relevance to find some synergies connection. What is probably missing uh, is uh, how we can really use this matrix. So, apart from the traffic light model that can give us a glimpse on which is the results, which is the check of the of the health of the I would have expected I mean, I hope that we can work on that direction that

uh, the foundation can also suggest uh, some pathway on how to improve from one level to the other. It's just not on the project side to be sure to move somehow between the different uh, colors of the schema, but just uh, having also some uh, again shared collaborative way to create this pathway in order to improve ourselves. Yeah. Um, so we have a derivative idea from this

traffic light model and easy use of labels. Since you know, there are some a few things that we're going to be using for uh, this score. Um, I think we're going to have add some labels to your project in which you will get some little bit more fine-grained information about what are the strengths of the project. Like for example, security approved. That's really important. Reviews done and

maybe you get like a I don't know, review cycle check um, or you know, if you're missing something from the IP, you will see you know, a little label saying IP pending. Um, something like this or maybe communication channels not active. This kind of uh, label labels that might have different status might help. That's still not defined, but um, even if we don't share that because we

don't know how much of this might be perceived as useful or not be good for your project, right? In front of the community. I mean, if we're already having issues with this mindset of working the open, imagine having a bad label in your project, right? So, it's more like this traffic light is help or provide a very quick overview to potential contributors and newcomers. But, like I

said at the Eclipse Foundation, every project has to have acts or have to go through a review every year, and during that review, we definitely provide much more feedback on what can be improved uh from the licensing point of view, trademark point um legal documentation, security, IP management, everything. We We do a quick check. So, um yes, definitely the idea is that we use this to show

in a very simple and fast way to the potential contributors around your project what's the status of your And this is maybe why we won't have a score, just a light. But, the idea is that maybe we can combine that with labels, good labels that we can, you know, uh can highlight the strong points of your project. I think it's uh good initiative and it's a good

way also for the project to identify where they need help and maybe recruit newcomers in the in the community. So, yes, it's good to scan the project when you consider entering the project, but it's also helps you to see where you can add some value. So, think it's positive, basically. >> Yeah. Uh Tim. Oh, by the way, um Tim here uh just shared with me yesterday that

one of the results of a research project that we used to do together many, many years ago um has become a standard in open source and it's actually being used in OSGi. He can attest for small habits, good good practices, and continuous effort. So, if you want to know more about how to run a successful open source project, please do talk to Tim because I was impressed

by the results that he kept uh after all these years, he continued to put in the effort and do the work, and it has I think it has paid off. So, yeah, that's a really good um successful story. Sorry, Tim. Go ahead. Um so, I just want to say obviously traffic light system is great, and you've got all of these different measures, and I think be knowing

knowing areas where you're weak is often quite useful. So, I see, you know, if you if you have a a green tick, it's great. Yeah, everybody's happy, but I think I probably see more use in the amber and the red, especially if we could alongside that have flags as to which which would be the most important things to focus on first. Because obviously, if you've got you

know, if you slip down the rankings, and you know, which are the things that have the highest impact, and which are the things that you should you should be trying to fix first to you know, get yourself maybe from red to amber, or rather than rather than you know, tweaking something that was already kind of okay, or doesn't have as much impact you know, generate your S-bomb,

or Yes, definitely there is a priority. Of course, you know, having a legal documentation is important, but security kind of fits that after ground. So, yes, we have to think about these and prioritize them. I think So, I think the main issue is how to present this to projects that still haven't, you know, digested having issues it's okay and to have them in the open is okay

and to ask for help is okay and it actually might some people that wants to come in and participate, right? it's a balancing act, but we'll definitely think about, you know, providing more fine granularity, adding priorities to the feedback that we can get from this traffic light model and somehow keep everyone peace of mind in the process. Thank you. Okay, no more questions? Good. So, we get

to have an early lunch. Thank you for participating.