 We will be kicking off Brian's talk on aligning open source community and business goals in two minutes So hopefully everyone's on the edge of their seats and ready to listen I hope everyone listening here has gotten as much out of devconf us as I have over the last couple days It's been an excellent event and probably the best virtual conference that I've been part of so I very much enjoyed it It's definitely not the first either Good day, my name is Brian profit manager with the open source program office And I'm pleased to have you viewing this session of devconf us 2020 Where we'll be talking about the alignment of community project and business goals and how we bridge that gap to make those goals Align, this is something that we do a lot in the open source program office Where we get we help upstream projects that Red Hat Stewards You know figure out how to get their goals to align with the business needs of Red Hat as a whole This is something that's pretty common within any kind of open source project that's interfacing with a corporate environment We certainly see this on a daily basis But it's also a difficult task because as you might expect The the alignment of community goal and a business goal, which is mostly going to be for profit On the surface doesn't sound like it's going to actually, you know fly very well But in reality it kind of does You just have to take the time to work it out and get those goals set and aligned Now setting goals is not something that's super fun But it does need to be done and you if you do it in a realistic way You'll find that setting goals isn't that arduous of a task and that those goals can be, you know Realistically created and probably met 2020 notwithstanding So let's start on the business side of things and we're just going to talk about what businesses do what they're all about and you Know if you have been to business school, sorry, we're breaking this down for you in just a few minutes So sorry you put in all that money, but this is what what it's going to be about At least from the perspective of this presentation today so businesses are all about creating goods or services and They optimize the marketplace for receptiveness to buy those goods and services. So euphemistically what we call marketing And then they distribute those goods and services And then finally hopefully they generate a profit from the sale of those goods and services And repeat so there you go all your business school knowledge in one easy to follow slide But beyond that, you know, that seems pretty straightforward And we're not going to break new ground here talking about what a business might be doing but we do need to understand what a community's needs are and How they might align because when you first think about a community, you're going to be thinking about wow They're just about creating things and free flow and it's very organic And and how would that ever mesh with the rigorous demands of a you know For-profit business and a capitalist framework. Well, let's give it a see and find out if that's certainly the case So in a community, you're also creating goods It may be software. It may be hardware. It may be documentation It could be a lots of different things. There are many open-source projects out there now for this presentation You may find me slipping into the lazy person's way of saying it and just say we're talking about software Expand that a little bit when you hear me say software specifically because 99 times out of 100 I'm going to be talking about software hardware Content everything else around that could be done in an open-source way But let's back to this we're going to be talking about okay communities are going to be creating goods whatever those goods might be They're going to the project's going to try to optimize the user and developer audience To be receptive to those goods So it may not be formal marketing although certainly some larger open-source projects do do formal marketing But it's marketing ish in the sense that we're talking about, you know Giving the users and the developers an idea of what the project is making why it's making it and what good is the thing that's being made Will be for the end consumer or you know developers who might want to contribute to the project. So again, possibly not formal marketing, but certainly in marketing ish In the way that the community gets the word out They will distribute those finished goods with the source of the whatever is being created. So software, it's going to be source code. If it's hardware, it's going to be the specs and so forth and so on. And those will be distributed however way the license dictates those the source is distributed with those goods. They're going to generate users and contributions and more use. So they're looking for, you know, getting, you know, the project more and more used and then ideally more and more contributions to the project. So this is where it varies a little bit from the actual sale because, you know, after you Sell something in a commercial sense, you're not really looking for contributions. You're really just looking for users and or, you know, currency. In this case, you're looking for users and ideally more people to contribute to your project. So it grows in a healthy and sustainable way. And of course you repeat all this. You repeat this with new iterations of whatever you're creating or if you're very successful, you will have some projects that will build off the main project and off you go to just start it all over again. So as you can see, if you look at businesses and communities in this way and what they're doing and what they're trying to accomplish, there are a lot of differences in their end goals. They're still both trying to make something. They're still both trying to get as many people to use it as possible. It's just that, you know, a business is going to be looking for some kind of, you know, transactional exchange. And a community is going to be looking for more of a collaborative exchange where you can have ideas and new input coming in in the form of contributions. And certainly, let's face it, it's not, you know, it's not for nothing if your project is successful and you have a zillion downloads a month. That is not the big marker for a healthy community, but, you know, it's nice to be liked. And certainly a community is going to be part of that as well. So when we talk about the alignment of business goals and community goals, it's really important that we understand the concept of open first. And this is something that anyone who works for Red Hat will certainly understand. And anybody who's familiar with, you know, how Red Hat and other open source companies work will feel that this is a very familiar topic, but it is not a universally applied topic with organizations who do use open source. So we want to go kind of through it real quick and emphasize that this is the framework in which all of this is coming from. Open first is when the core values of the business are aligned with the community. And it's very important that we do the wording in that order because it is not the other way around. The community should not be aligning itself with the needs of the business. And that's really key to understand because in a lot of situations, a business will start a community and want to make sure that the community is always in lockstep with the business goals. That is not a way to a sustainable and healthy community. It is the way certainly to building a software or hardware project that the business really likes and the business can sell in, you know, in a way that's better for the business. But the community itself will suffer very quickly because if you just have people in the business who are dictating the way that project is going to go. No one from outside of the business is going to really feel empowered or incentivized to jump in and contribute. So therefore you have what is known as a universally stagnant community in terms of diversity of organizations that are involved in it. And that's really something that's not good to see. So it's important to remember that the community values should go first. So when you're developing in a community, everything starts in the community to build documentation, everything should start in the community and so forth and so on. For every aspect of that, it has to start in the community first. Now, it is important to clarify and we'll touch on this a little bit later, that we're not saying that the community should completely ignore the needs of the business. Or businesses, poor all that might be involved in the project. They should be willing to compromise and, you know, make allowances for each other. But it's, but the priority should always be with the community. And that's what we're trying to get out here in this presentation today. In the open source way, there are five key elements of that philosophy that should show up when we're talking about how a business should be operating within an open source framework. So it definitely should have transparency where everybody involved in the project should have access to the information and materials necessary to do the best work they could possibly do. And collaboration. If everybody's free to participate and collaborate and you don't have this massive hierarchy of, you know, only certain people can put in new ideas. You're going to have a much healthier community in terms of open source project management. One and the good one, the release early and release, release often mantra that is certainly very healthy or an open source community to do the more that you release the faster you can find new discoveries and possibly old bugs that will show up. So it's good to have that going for any open source community. So and for the second part of that too, it is also key because it just keeps people interested if you wait years to release the next version of the software. I guarantee you the human attention span will cool get people leaving your project and going off and finding the new shiny thing. So there's a, there's a more of a sneaky way about release early release often beyond the philanthropic idealism of making sure that everybody can collaborate as much as possible. So either way you cut it release early and release often is a key part of the open source way. Meritocracy touched on this a little bit when we were talking about collaboration but certainly any healthy community is going to have good meritocracy where it doesn't matter where the idea comes from. It matters what is the best idea and where that you know, and how that idea can be applied. Good governance is important to keeping the good meritocracy in place because governance that allows, you know, a clear and accurate decision making process if they're conflicting ideas being brought to the table, and how those conflicting ideas are resolved. And that is a key part of keeping, you know, a community healthy and also keeping meritocracy straight you don't see favoritism creeping in, if you have good governance. And then finally the community itself. When the community is given a common purpose and when it is given common goals, and they can take their goals and, you know, build on them and work with their shared values to guide your decision making. And that will also be the mark of a really healthy community. So those are the five things that, you know, really are key to the open source way, and certainly a big part of what it means to be open first. Okay, so we've done the high level theory, we talked about how we're going to be, you know, doing everything in the open and this is great because we, I'm sure a lot of us have seen this before. How do we tactically apply this grand strategy? Well, in the Red Hat open source program office, we have two different tools that we use to help figure out how healthy a community is, and then also how that community can be aligned with the goals of Red Hat. Now, you can apply the, you can use these methodologies in one way or another in your own organization, if you so choose. But here's what Red Hat is going to be doing and has been doing for at least a few years now. The first tool that we have are called audits. And audits examine community projects on a regular basis, usually annually, from an outsider's point of view, in order to determine how that community is perceived, and how they can be joined by any contributor or user. That is a big, long, fancy way of basically saying, we look at a community as if we were coming in from the outside, and how easy is it to join the community? How hard is it to get involved with the community? And from there, we build statistics and dashboards to sort of quantify if we indicate the community's health. And if you have a community that is very difficult to be involved in, that is not really a good thing. It's certainly not going to be healthy for the community, and it's certainly not going to, you know, get you access to new contributions and new ideas. Remember, ideas and contributions are the currency here and the community environment, not necessarily, you know, actual paper currency. So audits are the one tool that we use. The second tool we use that are very related to audits are called stakeholder reviews. Again, these are also regular, probably annual examinations, although in some cases they are done more often than annually, from the business's point of view, not an outsider's point of view. These stakeholder reports also determine the efficiency and the health of the project, and it also helps figure out how the project is aligned with the business goals. So they will go in, determine the health of the project, determine the project's goals, which are, again, the priority here. And then they will work to see how they can match the business goals to, you know, match those of the project goals. And so we have audits and stakeholder reviews. They sound similar in many ways there. They are similar, and we use that to our advantage, but we'll talk about audits first. So an audit is going to be examining several different elements of the community to kind of ensure that, you know, things are going to be set up well for onboarding, which is the process of getting new community members in. The only aspect that we talk about with an audit, but that is certainly the emphasis on the audit, because how an outsider perceives a community is a really good indicator of what things the community should be fixing to get things to work better. So the first thing are going to be, you know, the easy things, the public facing access assets rather, sorry, the websites, the mailing list, the chat channels, whether it's IRC or Slack, anything that you use to communicate that the community sees first. We euphemistically call that infrastructure that is probably not the right way to use that word, but that's the name that we've kind of assigned to it. We look at these assets to see how well they're designed, how clear they are, how well worded they are. It may come as a shock, but there's so many free and open source projects out there that don't really have a clear website. And something as basic as what is the project about? What does it do and how do I get it? There are complicated and convoluted websites all over the place in the open source ecosystem, and they really need to get, you know, themselves fixed. So this is something we try really hard to avoid in the Red Hat ecosystem. In case management, how often does a project come out? When it comes out, you know, how is it announced? Is it clear? Is it done on a regular cadence? Again, these are all markers of a healthy community. Documentation. This is another key element of onboarding in a community where you've said what the project is, you may have clearly said how to get the project. But if you don't explain how to use the project or what the project is good for and what use cases, again, you've created a barrier. So documentation is always going to be a key part of a healthy community. Contributions. Now, we'll talk about this a little bit later. This is actually the one part of the audit that we might not be looking at from purely an outsider's point of view. In that most outsiders, when they first look at a project, are not going to be looking at the contribution levels of a given project to see if it's healthy or not. They should, but most of us are not going to be doing that. So this is the one part of it that we might be getting a little more insider baseball with. We'll talk about that a little bit later. But certainly contributions to a project, whether they are increasing or decreasing, and what part of the life cycle that project is in is certainly an element of a healthy project. Outreach. What is the project doing to let itself be heard? Are there blogs? Do they have an active social media account? Are they present in a lot of events? Do they host their own events, whether they're online virtual meetups that we do now in the time of COVID? Or were they doing regular meetups at local organizations around the world prior to COVID? These are all things that we look at when we're looking at an audit. The license, this is probably by far the least worrisome part of an audit, because all the projects that Red Hat works with have some kind of OSI approved open source license. But if we are looking at a project that we're not directly stewarding, certainly we're going to be looking at the license to make sure that it's got an actual open source license and is applying it correctly. So let's look at each one of those quickly. Infrastructure. And again, we're talking about website, communications channels. How easy is it to access the product? So how easy is it to download the software? And then how easy is it to actually find the documentation? You can have documentation, but if you don't actually put it in and make it easy to access, it's going to be difficult to use. Release management. What kind of releases are coming out? Is it done VA? Is it done VA RPMs or some kind of source tour ball? How is it released? Because that can make it easier or harder to implement. How are the release announcements done? Are there QA processes built into the system? Are there continuous integration and continuous deployment process built into the release management? This is not always a given. It seems like this is fairly straightforward, but there are a lot of projects that don't have all these elements in place, and they probably should. Documentation. When you talk about it, is there a quick start guide? That's an easy to use. How do I get this thing going and how do I start using a guide? That is something that's missing from a lot of projects. Is there a change log? Are there use cases? Some projects are complicated and not always easy to understand why you would use them. Talking about how another user implements something in a use case can be very helpful. Is there a guide to installing it from source? Usually that's buried somewhere and it can't have repository. That's fine, but maybe make sure it's highlighted somewhere and say, hey, if you want to run this from source, here's where to go to find that piece of information. Contributions. Again, this is the one where we kind of kick the uphill a little bit and see what's going on inside. We're deviating from the insider's perspective a little bit because we do see the level of contributions and how fast issues are closed and how contributions are growing. We see a lot of this as a marker of health. Now, anybody can actually take the time and find this. We're not deviating too far from the insider's perspective, but we also recognize that most people are not going to be doing this. We are looking at things like pull request contributors and issue contributors and contributions itself and how many contributors are coming from a certain organization. The average time to close an issue and the average time to first attention that an issue gets. These are things that we are going to be looking at and making part of the audit. Outreach. As I said earlier, we're talking about blogs. We're talking about social media. We're talking about events, whether in real life or virtual. We're talking about meetups. Not every project has to have a blog. For instance, if you're very small and you just have a few contributors working on your project, then no, you're probably not going to want to take a lot of time to generate blog content. You're busy working on the project, but you might want to try to set up some kind of social media account, whether it's something on Instagram or Twitter, something that you can kind of get the news out quickly about what's going on in your project and generate interest in it. Not only using it, but then contributing to it. The license itself, most of the time, it's pretty straightforward. There's got to be an OSI approved license. We need to make sure there aren't any incompatibilities within the project. It's not going to be rare anymore, but that does crop up occasionally. Is there good governance for the project? And also, is there a privacy policy in place? Certainly things like the European Union's GDPR policy makes it important that all participants in a project understand what their privacy options are when they're participating within the project. Okay, so that's basically what an audit is. I do these audits for the open source program office. They don't take exceptionally long. We use a spreadsheet. We sort of fill these out and most of the time it takes about two or three hours to conduct an audit. The longest part of doing the audit is writing up the general report afterwards because that will take probably another hour or two just to kind of get that set up and word it in the correct way. Stakeholder reviews are very similar to audits. In fact, you're going to see a lot of overlap between the two. And again, as I hinted earlier, we actually use that to our advantage. So what are we looking at when we talk about stakeholder reviews? Well, here we're looking at the goals of the project. And we're also looking at the project health. And we're also looking at the goals of the community. And I sort of said that backwards. So the first goals we were looking at were looking at what the business goals are now. We're looking at the project health. And then we're looking at the community goals. And remember, the community goals have priority. So even though we're, you know, they're listed last year that actually doesn't mean anything. They are certainly the priority. So when we talk about goals, we're looking at the project schools as documented by the business unit. So what we mean there is if a business unit within Red Hat or any organization is working intimately with that project, we want to know what that business unit schools are for the project. We're also going to be looking at the organization's goals from the company itself. So what does the company want to be doing inside the software? Usually that's going to overlap with the actual business unit that's interfacing with the project, but there might be some deviation. So we're going to be looking at what those goals are. Project health. Well, most of the time this is basically what we're covering in an audit. And so we're, you know, there are a few deviations like a stakeholder review is still looking at things like the target audience. And also how, you know, the general ecosystem is. So what other projects are out there that are doing about the same thing. But other than that, a lot of things are going to be looking a lot like what we do in a community audit. So nothing really new there. And then finally, we look at the community goals so we can orient the direction of the project. And, you know, from there, we're looking at what the project goals are from the business unit, the overall organization, we're taking the health, we're rolling and all that. And then we're also talking to other members within the community. This is very, very important. If we, especially if we're working in a project that actually has multiple organizations working for it. We are going to be talking with all those different players within the community to figure out what their goals are for the project. And we're going to work with them to make sure that our goals align with those of the project itself. We're also going to be looking at any kind of metrics that might, you know, help us determine the project health. Any dependencies that the projects work on that need to be addressed and identify any challenges moving forward, whether it's the next quarter or the next year. Those are things that are going to be coming out of the community goals part of the stakeholder review. How we do it at Red Hat specifically. So remember how I've been saying that, you know, there's a lot of overlap with the audits and the sticker holder reviews, especially in the terms of project health. Well, guess what? We're going to be doing the audits first. So typically I work with the community architect that is assigned to a given project and determine, okay, when are you going to be actually doing your stakeholder reviews? And if they are doing it annually, then it's basically a question of me setting up a time to do their audit about, you know, anywhere from two to three weeks before they actually do their stakeholder review. The goal there is very simple. I can basically give them most, if not all, of the project health data that they were going to be including in their stakeholder review. And if I do it in a timely enough fashion, they don't have to do it over again. So we save a lot of work there by merging that part of the process together. The audits will be, you know, basically there is a spreadsheet where I will go through and step-by-step look for key elements of the project that are going to be in place. So things like, is there a website? Are there subdomains for the website? Do those subdomains have the same navigation? A lot of times if you set up wiki.project.org, the wiki's navigation is going to be possibly not the same as the main website. That's an unfortunate, you know, byproduct of using a subdomain. And then you have to give that information to the project people and say, hey, this might look confusing to newcomers. Is that something you want to spend a lot of time? Those are the kind of questions that are going to be asked on the audit questionnaire. We also look at that contributor data. We use a tool called Cauldron. This is an open source tool that is fostered by Baturgia. If you're not familiar with Baturgia, they're a company out of Spain that does a lot of work in community metrics. We take all of that and put that together and then we generate a multi-page report that includes all of the information that we gathered and any suggestions that we might have for the project. We then present that report to the community leaders of the given project with the option of, you know, telling them that, you know, they don't have to fix all this. We never actually put, you know, restrictions down and saying, oh, this is something you have to fix. We always give them the option to decline or accept any suggestions we might make. We also, as part of our work within the open source program office, give them the option that we will help them. So if they need a website, you know, tune up as one example, we have the skill set and the resources available to help them with that if they don't. Or they can take that information and do it themselves at a time that they deem, you know, they can fit it into their schedule. So either way, you know, audits are never compulsory. They are never done negatively. Even if we find things that are, you know, really need improvement, we never approach people and say, oh, you people are the biggest screw ups ever. No. We're trying to be positive here and trying to point out, hey, we see you need some help here. We've got some people that are willing to help you with that if you need it. And we're, you know, we work together to try to make the community better. The stakeholder reviews, as I said, those are done next. The data from the re-audit or the data from the auditor is reused. And that helps make the stakeholder process go a lot faster. Somebody's already done the legwork on the project help. The business unit coordinates with the community architect to get the goals and everything else identified. And then they work together and align those goals and finally generate a final stakeholder report. Stakeholder reviews at Red Hat are sort of treated like annual reports for a business. And they are very important and they're key to the operation of a project that we work with. And with that, that is how we put audits and stakeholder reviews together. Thank you very much for your attention today. We certainly do appreciate it. We look forward to getting your questions and comments in the rest of the presentation. Thank you very much, Brian. That was a very good presentation. And it's complex subject how a for-profit company deals well with communities that have very different names. So it was very well done and I appreciate that. Great. Thank you very much. So do we have any questions for Brian? We have a lot of people here watching so we should have some comments or anything like that. Brian, do you want, would you like to add something or do you like to make any comments yourself? You know, not really. I mean, I think that, you know, for us, the process continues to evolve. We're always looking for suggestions and ways to improve how we can, you know, more closely align community goals with business goals. It's, you know, it's never going to be a perfect system. It always varies from project to project, but it's certainly something that we are continuing to look at. So beyond questions, suggestions and comments would also be welcome. Do you have links or contact information where you'd like to do that? I'm Sue. Let's see. Well, one of the things that I noticed during the presentation was I mentioned this tool called RIN, which I did not put into, I'll put it into the chat. Oh, thank you, Brian. And then we actually have a question from Jen Krieger who asks, any advice on when open source project goals do not align with business goals? Yeah. So historically, and this, this, this has even happened a few times historically at Red Hat. So you, again, giving a lot more weight to the open source project versus the business goals. But then there's also that immediacy of getting the business goal out. You're trying to satisfy some customer need or some market need. So it really becomes a really true collaboration and both sides are going to have to sit down and try to figure out how to, you know, how to get the project in the direction that each one wants to go. This doesn't happen very often because usually, unless it's a drastic technology dependency change, most of the time the goals are going to not be too disparate. But the advice would be to set up, you know, teams that are going to be representing all, you know, anybody who's got a major stake in the project. With, you know, the business and have them all just sort of sit there, technology action committee or something like that to sort of figure out what the roadmap for the project is going to be. It is really important that all players have a stake in deciding how the project is going to go. And if the business has a persuasive argument, then that should do it. Oh, excellent. Well, well, thank you very much, Brian. So we have one more question here. We have a question from Carson Wade who asks, how do you see the evolution of meritocracy as a core concept going forward. To understand the correct question correctly. I think that, you know, meritocracy as a as a thing seems to be kind of evolving because in the past meritocracy was very much key to the individuals within a given project. So a certain person had, you know, awesome skills became a maintainer became the lead maintainer. And that's how it seems to have happened. Now, because a lot of us are working on open source projects. Full time we have that luxury and that's a whole different conversation about, you know, the privilege of being getting paid versus volunteering, which is something we should all be discussing too. But let's just say in the current framework, the way things are going, there's much more corporate environment. I don't see that. I've heard a lot of people talk about how meritocracy is getting dulled because of that because now, you know, some cynics would say now it's becoming more of a pay to play kind of situation. I do agree that meritocracy at the individual level has been dulled slightly by the the influx of corporate participation. But I think it's just been dulled it's not being eliminated because individuals at the end of the day, they're the ones responsible for getting the code in there responsible for making sure the code works and works well. And when somebody comes along and makes it work better. So as long as it's people who are actually still doing the work, no matter where they're coming from, I think, you know meritocracy is still going to be a prevalent driver for projects moving forward. Excellent. Excellent commentary. I'm going to ask a follow on based on that is, do you see meritocracy and diversity is diverging as divergent topics, you know, some people will bring up and say, if you go exclusively on meritocracy using one person's view of merits or small groups view version of merits. I'm going to. So I'm going to ask a quick clarification, like when you're talking about diversity or talking about any diversity or we talk to any diversity. Yeah. The broadest sense of the term. So for me personally, the more diversity project is the better off it is. And that's I, I, I strongly believe that because different cultures and different, you know, different gender outlooks and different, you know, different levels of ability. You know, and and corporations and and and and that you're bringing in so much more talent and perspectives, my, my best conversations come when I am talking to people that think completely differently from me because I'm bringing what I bring to the table. You know, and you bring your stuff and you know, but the more different we are the more diverse the background or history. There is the more, you know, you know, it's challenging but it's also awesome because you just have this. You know, these new perspectives that you just never would have seen before. I don't understand why this is so hard to figure out for me or diversity. I don't want to work with a bunch of people who look and think like me. I want to work with people who are going to bring more than the table and and give us give the project rather better and more innovative ideas. So diversity really drives meritocracy then. So I believe so I think, I think it drives. Yeah, it drives creativity meritocracy. It drives so much. Okay, now I tend to agree. Karsten has an interesting comment he says there's historically a correlation between people with merit and open source project in the life of those folks have. Yep. And I would agree. I would agree with that strongly. And that is something that we all need to work on both, you know, certainly at an individual level within projects, definitely at the corporate level. It is not easy. And it but it's still something that we have to try to do, because, again, I'm coming at this from two ways I'm coming at this like I'm trying to be a better person. Right. But let's just say I'm not let's just say I'm being very selfish and non altruistic from even that point of view, even if I were being the most cynical person ever. I'm not, but diversity is an advantage. It is an advantage for the project so I do not understand why this is so hard for people to figure out. You know, Well, I think it's about change. I think change is tough. I think that's really what it is is that any sort of change if you're used to saying one thing if you're used to working with a group that's just like you, even if there's a major advantage to change, it is a hard thing to accept. So, that's what it is and I think pointing out the things you just said about how so drives creativity and projects to have diversity and to give the diversity of opinions and things like that and the viewpoints. I think that's one way to counteract that. Yes. Well, excellent, excellent talk Brian I really enjoyed it. Thank you and I think this conversation is giving me an idea for my next talk so we'll see what happens there. Excellent. Well, and then that talk for for the Brian has given me a great segue our next talk starts in six minutes and Brian will be remaining, as well as some of the other folks that are in this room already so please stay and we're going to have a panel discussion with the experts on open source and process starting at 10 after the hour.