Open source developers are unique: Tips for working with and managing community-centric dev teams

Is there anything unique about working with, managing or being an open source developer? On a recent episode of Dynamic Developer, I spoke with Todd Moore, vice president for open technology and developer advocacy at IBM, about these topics as well as what he looks for when hiring open source developers, the right way for companies to turn their open source projects into open standards and some of the coolest open technology initiatives IBM is working on.

Todd has a long history in software and hardware development and is a leader in the open source world. He and his team of developers have worked with leading open source communities like the Apache Software Foundation, Linux Foundation, Eclipse and OpenStack.

The following is a transcript of the interview, edited for readability. You can listen to the podcast player embedded in this article, watch a video above or read a transcript of the interview below.

Bill Detwiler: Todd, thanks for joining us.

Todd Moore: Excellent. And I’m happy to be here. I really appreciate it. The topics of developers are really near and dear to my heart, especially when they’re working on something that’s open source. I put a lot of my time out into open source communities like the OpenJS Foundation and Node.js and other topics in the cloud-native space, cloud-native computing foundation, things like that. So it’s something that I view as part of my give back into the communities.

Bill Detwiler: Well, let’s start there. As someone that’s managed development teams and been part of the developer community. And, is now focusing around open source and development and the open source community, what’s changed in the last couple of decades in terms of just developer career tracks and managing development teams, and some of the challenges that both developers and managers face? I think that’s a really interesting place to start. Especially someone like yourself that has a long experience in this space.

Todd Moore: Well, I think the first thing that’s changed, was open source really took a dominant position in the development process. And what we find is that a large percentage, 50% of organizations are now using open source in a fairly substantial way. And sometimes as much as 90% of a product that someone’s putting out is based on open source, right? They’ve done the customization and the other things around it to produce something unique, but open source is its core. So, what’s happened with that is when you’re looking for people who are participants in your development process, you also want them to be participants in the open source communities as well too, to have good acumen, to have the ability to influence direction, but also to make the changes necessary to keep things rolling in case you might have a problem or one of your customers might have a problem.

So it’s really become paramount that you look for skills that also have good development in open source skills, and they’re different people sometimes. In the classical developer, who’s out building something just for a product that’s proprietary, right? The proprietary products, the developers can create large chunks of code and immediately put them into the CI stream and build a product. But when you’re out working in the community, that behavior doesn’t really work well, right? You need small, manageable chunks of code that people can review in a setting, and one sitting, I should say. And then, be able to relate to and decide that yes, plus one that can be included, and let’s go, get it into the build, right, into the tree. So it’s a different approach and people need some different skills.

I guess the thing that when we look at somebody who’s coming in, we look at what they’re doing and GitHub first, right? Is their behavior one that supports community example would be, do they just jump into the fray or are they listening? Have they built up some rapport with the community? Do they understand how the community likes to structure their code and behave? Do they do code reviews? Have they been a mentor? Did they seek a mentor to help them get going in the work that they’re doing, right? Because you have to develop others in the community, too. You’re doing this because you want that project to have a long-term life and be well supported because you’re going to be dependent on it. You’re building your product on it, right?

So you want to make sure that your folks are good community builders that build trust and they create good, clean, manageable code. And you can find that just by looking at GitHub these days, right? So your resume as a coder, as a developer, it is GitHub, right? So important to really take that really seriously, right? One of the other things that we’ve seen is that, we like to see people who don’t just drop code and run, but are in there and make sure that if there’s a piece of code, especially if there’s a lot of dependency on it, that they help others either through maintaining it and continuing to have a maintenance plan, or they gracefully handed off to somebody else and say, “Go through the process.” So those are the things I look for when I’m looking at somebody’s coding and their participation, how do they handle issues? What do they do?

SEE: Open source vs. proprietary software: A look at the pros and cons (TechRepublic Premium)

Open source developers need “soft skills”

Bill Detwiler: Yeah. And that’s what I was just going to ask. I was really going to try and drill down on. You talk about technical skills and, but what I hear you describing is more of, I don’t know, when I was in IT full time, 20 years ago, we would call it soft skills, right? It was those people, skills or communication skills; the ability to work and play well with others; the ability to sort of reach out beyond that individual project that they’re working on or their part of the project. How important are those skills?

I mean, it sounds like they’re very important from what you’re describing. How do you identify those skills beyond maybe what you just talked about in either as part of an interview process? Is looking at GitHub and talking to others or seeing what they’ve done is that enough, like you were talking about, or, are there other ways that people who are hiring developers, people who are looking for talent and developers themselves who are looking to showcase those skills, how do you find that person with the right skillset?

Todd Moore: I think this is, it’s a great topic and you’re right on because it’s the soft skills that make for better open source developers, right? And we’ve seen that time and time again, that we can’t necessarily just take someone who is a very good, productive developer in our product side of the house and turn them loose in open source because of this soft skill. And so, the GitHub set of things gives you sort of the first look into them, right? You can see how they behave, the types of language that they use. Are they really playing nice within the community, but then in that interview process that you have with them, you need to sort of ask those questions, right? What’s your approach to joining a new community? And people who respond with, “Well, I feel my way in, I look for a technical mentor to help me and at the same time, I help them get their work done.”

Those types of responses tell you that this person knows how to behave in a community, right? That they’re actively listening as much as they’re contributing code, and they’re doing it in a thoughtful way. And I learned so much about that just a long time ago from folks who were out and working in communities, that it was just so important to do that. And then we’ve since written our own etiquette guide for our developers who are participating in open source that codify those principles so that they’re out there and they’re taking that into account. And then I look for those same things as we go through that interview process with the developer.

SEE:
How to be a good open source community citizen

(TechRepublic)

IBM’s code of ethics for open source development

Bill Detwiler: So talk a little bit about that. I’d love to hear more, what are some of the, you don’t have to recite the entire document, but what are some of the main points that you put into that code of ethics that you developed there at IBM around open source development?

Todd Moore: Okay. Well, there’s seven things in the etiquette guide, and I won’t hit them all too hard. But understanding the community the way they do things, not just jumping into the fray, but listening first; understanding the rules, looking for a code of conduct when you come into the community, making sure that’s there and you abide by it, right? Treat others the way you want to be treated. The golden rule thing here really comes into play. People don’t care about the degrees you have or what other things you’ve done or whatever. They want you to treat them well, right? And understand that, and if you do, that, most communities will be very friendly back to you. And they’ll hand you the keys to the kingdom. If you’re a committer, right, into a process, if you really are that respectful and helpful and know how to get involved, right?

Start small, build trust; you can’t just jump in with great, big, huge changes and expect people are going to go and embrace that. That’s one that we often have to teach many times to people as we go through this, because people get excited. They want to get something in there. Contribute good, clean, manageable, tested code that can be consumed within one sitting when you’re trying to go and do a code review, because remember, people on the other end of this are doing code reviews. And the other thing for etiquette is, if you’ve got five IBM guys in a project and 10 other people, make sure it’s the other people who are doing the reviews and saying it should be committed into the tree as opposed to just the IBM as just an example, right?

You don’t, I think it’s really bad form to see people within a company also, plus one somebody’s contributions. When we really need to make sure it’s a quality of the code and the type of function and feature that we want as opposed to the other way around. So make sure you get your code maintained and keep it maintained. Be a mentor, look for mentors as well too, as you go about this.

Find a mentor who is somebody who’s prominent in the community and support them, and they’ll help you in your path towards committer in a community. But more importantly, you’ll be getting good, positive, important community work done, and then people respect that. And that’s just part of giving back. So give back is something that we ask people to do. And then lastly, licensing is important, right? There’s permissive licenses and not so permissive licenses and know what it is you’re dealing with and where that code is going to be used in your own projects. As you go back and support, those who are back at, trying to build something on this and make sure that you keep the interfaces clean and that you’re practicing good hygiene around that as well, too. So that you’re very aware of and friendly, too, of the license that is going on within the community, that you’re involved in.

SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic)

Bill Detwiler: Yeah. And as I’m listening to you describe this, it really sounds like, and I don’t mean this in a negative way. It’s a lot for a single person to take into account, or at least it sounds like it is, as opposed to just sitting down and banging out code or sitting out and bang… I mean, there’s a lot of extra, and I think in a good way, but there’s a lot of things to think about when you’re doing this.

Todd Moore: But there’s a benefit to that. There’s a benefit to that, right? Because O’Reilly Media did a recent survey that we helped to sponsor because we wanted to know what was going on. And they talked to more than 3,500 developers and managers. And what they found was is that open source code was just to those people developing just as good as any other proprietary code that they were doing that when they were looking to go and host and use this on a cloud that 94% of them wanted to have open source software. I should say, 70% of them wanted open source software to be the basis for what was going to be their cloud application, cloud-native application, they were developing.

The managers, 65% of them preferred people who understood the base technologies, not some specific cloud kind of thing, but the basic technologies underneath this and the developers realize that, at least 65% of them did, that if they had good open source skills, they were going to be more marketable to the people who might want to employ them as they went. So it’s in everybody’s awareness; managers, developers, the businesses who are using this. So it’s just part of where we are now.

Tips for managing open source dev teams: It’s about passion and community

Bill Detwiler: Yeah, and that’s exactly what I was going to ask you was, and I love that transition because you mentioned managers and I was going to ask is there anything different or unique about managing open source developers or an open source project, or people working on open source projects managing within this community? That’s unique. And so, because I think, with all this extra or just all these sort of extra considerations, it seems to me that’s not only going to be on the developer, but it’s also on the managers themselves to really sort of help guide folks along with some of this etiquette.

Todd Moore: Yeah. The manager needs to be involved. He needs to understand, where things are going. He’s got to also realize that many of these developers have these qualities, also want to work on the things that are interesting to them. They have passion for the community. There might be something that the community is doing that doesn’t quite support something that’s back at the ranch, but that’s okay. A good portion of the time that they spend in the community can be also developed, developing things that are community important. I call it carrying water, chopping wood, and you just have to do those things for the community. So we’d make sure that when we’re talking with the managers and giving them some training, that they understand that that community participation piece is a piece of this and that it’s not like managing a program and a project with really tight deadlines and the types of things you do. Communities move at their own pace.

They have their own directions that they take. What you get out of that community is what you put into it. So if you need to see it move, you put resources in, you help them. You make sure that it’s good resources, obviously, that understand open source, but it’s different. It’s not that same kind of world, but hopefully, they’re following a process where their whole CI process is moving fairly quickly.

That’s a nice thing about open source. It generally does. And especially if they have the ability to have releases that are both a long-term stable release, as well as the leading edge bleeding thing that everybody’s contributing to, to try new features and functions and really try to move the ball forward. That allows you to have something that’s dependable for the guys back home, but at the same time, be able to have the fun things go on in there too, to test the boundaries of where you’re going with a project. So managers have to understand that that’s going on and that good open source skills are very curious skills as well, too, to want to participate in things.

Resolving conflicting in an open source community: Taking a collaborative approach

Bill Detwiler: I think that’s also a great point to talk about. Community is a little different when conflict comes up, or when disagreements may come up. Is there anything unique about sort of the open source community and that the etiquette and the model you’re talking up when there are disagreements, whether they’re minor disagreements or whether they’re more serious disagreements about code or licensing issues, or just how a project to proceed, how do you approach those disagreements in a community setting?

Todd Moore: Yeah. I had the honor of being on a front row seat to the Node.js community when it was going through its fork and then healing that fork back into a solid community. And it can be really tough because people get very personal very quickly when those things happen and things can be, typing something into a node or typing something into a message can be very imprecise and people can take the wrong message back as a result of that. So when a community goes awry, my first thing is to try to get the main participants together. And I helped heal that fork. I was one of the people who gathered up the folks and said, “Hey, look, we’re going to go and work on this together and let’s figure out how to bring this back together again.”

And it started with getting the main folks back together and having them chat and talk and talking about what was important to them. I think the place where communities go awry is that there’s oftentimes when they’re not out in open governance, as part of a foundation, they’re have a steward who is, it’s somebody who’s, a company who’s put that code out there. And there’s a certain set of expectations and things run around all along, just fine for a while. But then, after a body of work is done, suddenly, that steward may have other ideas of what they want to do. They might be off trying to promote the community or use it in a different way or whatever, and start to create friction within the team. And there may be changes that they want to make, but the steward no longer wants to make, right?

Those are the places where the friction starts to come to life. And as a result of that, that’s where you start to see forks, or really a discussion starts around going and placing the code into a foundation to support it as you move forward in the future. And we’ve seen that time and time again, that the communities get to a certain point and then suddenly there’s unrest among the community members and oppress towards open governance, because they don’t want to be beholden to a single vendor. Especially, if it’s something that’s going to be a de facto standard. Code has become de facto standards now, right? Kubernetes is an example, right? Great de fact that standard that’s come about in the container space, because it’s hosted in a foundation supported by more companies than anything you can imagine and has a great developer base.

Who’s done a great job of creating a culture and standing up something that now will endure the test of time. And it’s a de facto standard of code. So I always recommend to folks who are working in communities or companies that I work with. If you’ve got something significant and you want it to become that de facto standard that people can depend on, because there are things that are generally plumbing that we all should just share in. Why should we all be developing competing plumbing when we can go and put that together in something, keep it maintained, and then work on the things around it that expand markets and create new ecosystems and build partnerships. And do the things that we all really want to do, which is build a big marketplace for us all to participate in. So.

How to take an open source project from in-house to open standard

Bill Detwiler: Yeah, and that’s a really interesting way to describe it because it made me think of a story that a coworker of mine told me a while back when he lived in Japan for a long time. He said that a lot of the houses over there were built by different companies and each of the companies would install fixtures that were just a little different from each other; the outlets, the doorknobs, the screw sizes, everything was just a little bit different. So there wasn’t a lot of standardization. So it made it difficult as someone who was living in the house to go buy a new door knob or to go buy the… Even the electrical outlets or the light fixtures, everything was just a little off and it made it hard as a user and it made it hard as someone that was going to want to come in and fix it because you had to get that brand to fix it.

How do you over… And I think the foundation model and the way you talked about that sounds like, the way to overcome that, to settle on a standard. What do you see maybe as the next standard to come out, or how does that process work successfully? You gave the example of Kubernetes. I mean, how do companies make the decision to take something maybe that they were the sponsor on, they were working on and then to move it out, give up maybe a little control or to put it out in the community in a way that’s going to create that standard that is beneficial to them and everybody, how difficult a conversation is that to have with folks?

Todd Moore: So it’s actually not that hard to have, but it’s good if you get something out there to start with so people can see it. The most important thing to starting the conversation is the code’s going to be out there and be visible so that people can look at it. And if you just come to someone and say, “Well, I’ve got this little thing over here and it really should be open source, don’t you want to come work with me?” That’s not going to work, right? You got to have, it’s got to be out in the open. You’ve got to start to see some community participation in it. Maybe it’s got quite a few stars that have happened in GitHub, right? So, you know that it’s both useful and people are using it, et cetera. There’s forks that are happening, et cetera, right. That’s really important because now you have at least some level of confidence that this is something that might be significant.

We do it all the time. For us right now, trusted AI is really important. If you look at where the world is going and I look at the types of things that customers are trying to do, they’re trying to solve problems with AI now. We’ve been through the machine learning phase. There’s a real appetite to understand how to engage in and build things in AI. And that therefore means that having trusted AI is really important. So our own example, we put out our AI Fairness 360 tool kit. And we’ve put that now out into the Linux Foundation’s AI group, LFAI, so that we have people around the world now working on tools that help you do good, do, do things that are ethical, right? Make sure that you’re not being sabotaged in some way, because someone is spoofing that image, say that your AI is trying to look at and figure out what to do with, or that you have bias in your models, such that you’re penalizing one particular group when you really shouldn’t be, those types of things.

So trusted AI as an example of where we’re making sure that things come out in their standards. And I think that’s going to be so important, the developers who come to us all the time are looking to solve their problems with AI now. And it’s been really, really cool and interesting to see that.

Quantum computing, right? We put out a kit on Qiskit so that people could get going in quantum computing and actually play with real hardware and test out algorithms and see what would happen. And hopefully that then becomes the basis for building compilers and other things on top of that technology, right? Because it’s in its infancy, but here we can start to build the standards together because we’ve seen this whole, how do you make computing work before, right? We know you’ve got to build compilers and other technologies in order to then enable the masses to be able to use it, right? So there’s exciting things going on and we’re putting code out there, and so we decide that based on this is going to be important to the basis. It needs to be things that are plumbing, that is just good hygiene that we all can work on together. And then put them into a place where there’ll be accepted and can be moved on.

How do companies attract top open source developers?  

Bill Detwiler: Yeah. I love the Qiskit stuff. And I have a question. Building on that and also going back to something you said earlier, which is talking about people that have passion for projects and people that want to work on interesting things and people that want to solve problems, because that leads me to something I wanted to ask about, which is if you’re a company and you’re looking to attract open source developers or people that would be interested in working on open source projects and open source code that you’re working on, what are the best ways to do that from the organization, the foundation, the company’s perspective of attracting people? When you’re looking for developers, we talked about the skills that you’re looking for, but let’s say, you’re finding people with those skills, how do you make it attractive for them to come in and join your organization?

Todd Moore: Well, I think the thing that we’ve seen is you show your commitment to open source, right? We’ve been at this for 25-plus years, we’ve got 3,000-plus developers at any given time putting code out there. 15,000 commits a month happening, things like that, right? 1,900-plus repositories opened on up on GitHub. So you put that on display. You make sure that folks know that you have a commitment and that you’re out working in that space, but then we have for ourselves and others do as well too, developer.ibm.com, right? Everybody’s got a developer site, developer.ibm.com. But if you go in there, you can find that there’s quite a bit of guidance for developers on open source. There’s mentors that you can get through working with our advocates. You make sure that people understand that you’re in it with as much passion as they may be in it.

And you show people all the projects that you’re out working on and working in, and that it’s code content and community is how we view the world here. And we put good code examples out there. So people can see open source projects being consumed and used. And as part of the technology stacks that allow them to solve problems, right. We tell them, the communities that we’re a part of and participate in. As well as how to participate in those communities, and then we have good content around all of that, so that they can discover and find new information that will help them and guide them. And it’s not a marketing site. That’s the last thing I think you want to do with developers, is ever market to them. You want to show them and talk to them about good technologies and what they can do with them.

And the rest sort of follows because if they’re passionate, they’re curious, they’re interested. They’re going to go follow through with that. And eventually they’re going to find the other pieces that build on those technologies that are IBM products. But regardless of whether they go the product route or not, they have some trust in us as a partner and maybe work a little better with us without an open source communities as well, too. So, and once you have that trust, people are much more willing to come and join you as an organization. I mean, the folks who come to me and work in my organization love the fact that they get so much freedom in the open source work that they can go and do, and that’s really the thing that attracts them the most, quite honestly.

IBM’s hottest open source projects

Bill Detwiler: I’d love to wrap up, you mentioned developer.ibm.com, and I’d love to wrap up by hearing about maybe some of the really interesting things that you can talk about. Projects that you’ve gotten going on there and open source projects you’ve got going on at IBM and where folks might be able to go to learn more about those? If it’s different than developer.ibm.com

Todd Moore: It’s really developer.ibm.com is the place to go and learn. There’s so many projects that we’re involved in it.

Bill Detwiler: Anything you’re excited about, I guess?

Todd Moore: So one of the things I really like that the team has done recently is project of the Elyra. So we have the center for open data and AI technology. That’s also what you’ll find under developer as well, too. And Elyra helps people who are working in Jupiter notebooks to actually manage workflow, because it’s a lot of work to both create, train, test, and go back through this. And so Elyra is a project for folks who are working with notebooks that really manages that workflow and helps them go. And people really love that. So I’ve been really excited about the things that are going on with the Elyra.

Bill Detwiler: And that’s an AI centric project, right? We were talking about AI before.

Todd Moore: Yeah, exactly, exactly. The Qiskit thing. We’ve already talked about the adversarial robustness toolkit work, the AI fairness work, the explainability work. The thing that goes on in AI that bugs the hell out of most people is, that you get this black box and you can’t understand it. So being able to sort of work back through how it’s making its decisions so that you can figure out whether that’s what you really intended and want to have is something that’s pretty neat. So that’s one that really, I’m excited about. Homographic. Gosh, we’ll have to edit this part because I got a… Fully homographic encryption tool kit, right? It doesn’t just roll off the tip of your tongue. I argued with the guys when they were putting it out there that they really just needed a cool name, but they didn’t do it.

Bill Detwiler: That’s the engineer, that’s the developer in everybody. We need a name that is descriptive about what this is and not splashy, but I understand, but you’ve got to overcome that reluctance to go with a marketing name, something that’s catchy.

Todd Moore: So just a quick aside, so Qiskit, right? I probably shouldn’t say this one, but I’ll do it anyway. We were trying to get a really sexy name and we said, “Gee, it should be something like Knife, right?” And of course, the marketing team were just, “Oh, you can’t do that.” So if you go look up “QIS” in Klingon, you’ll find that it’s a big knife.

Bill Detwiler: I love it. Now that’s an amazing insight. That’s a little Easter egg hidden in the name. I love that. And it does roll right off the tongue. So it solves for both of those problems.

Todd Moore: So, but anyway, the encryption tool kit allows you to work on data on the fly, it staying encrypted, right? And not having to understand encryption technologies in order to be able to go and do that and think about the problem that we have in AI is access to data so often, right? So if you can work on somebody’s data encrypted, not be able to see it, share data among people, and then be able to do your training and do it on a much broader pool without someone giving up their crown jewels, but at least building that better model, that’s a wonderful thing, right? And what we’ve also done is to help in AI put out our data sets, right? So there’s a project underneath us called DAX, which is our Data Asset eXchange process.

And that’s available soon through Red Hat marketplace. I guess it’s up on Red Hat marketplace now. So you can actually find it and get it easily and deploy it through a container on OpenShift and be able to go and use it. So those are the things I’m somewhat passionate about, I guess. It’s making sure that the folks understand that. Really, again, also all around the theme of AI, I think it’s just so important right now as we help developers over that hump of going from machine learning to truly exploiting AI.

Bill Detwiler: Well, Todd, it’s been a fantastic discussion. I mean, I can’t thank you enough for being here and talking open source with us and talking just developer trends in general. Thank you again.

Todd Moore: Well, and thank you, Bill. I really appreciate the time. And this is, again, I’m passionate about this, and maybe you could tell, my hands are telling you the story too, right? But it’s a great topic and something that really, we need to give people good guidance. So appreciate you doing a series on this too.

Dynamic Developer interviews and more