In this episode of the Open at Intel podcast, host Katherine Druckman chats with Divya Mohan, a principal technology advocate at SUSE, and discusses the importance of documentation in open source projects and her work with the Rancher project and the Bytecode Alliance. She emphasizes the need for better coordination within teams and the importance of documenting code to avoid issues and improve understanding, drawing from her experiences leading the Kubernetes SIG Documentation group. Divya also discusses her involvement in the Bytecode Alliance, a nonprofit organization developing WebAssembly standards. She explains that WebAssembly is a bytecode format that can be used beyond the web and aims to unify the ecosystem and improve software development as a team sport.
“Software development is a team sport, but even within the team sport, we have formed small subteams and we're trying to achieve the same goal, but we are not doing it very well, because the teams themselves aren't in coordination.” — Divya Mohan
Katherine Druckman: Hey Divya, thank you so much for joining me. I'm excited to talk to you. I sought you out. I saw your talk on the schedule and arranged an introduction, so I appreciate you accepting the invitation and joining me here.
Divya Mohan: The pleasure's all mine because I have been a subscriber to this podcast for quite a bit now.
Katherine Druckman: Really?
Divya Mohan: Yes.
Katherine Druckman: Thank you.
Divya Mohan: And an avid follower. I got introduced to this podcast because you interviewed Nikhita Raghunath, I believe, sometime back.
Katherine Druckman: She's wonderful.
Divya Mohan: She had posted about this on one of her socials. I listened to that conversation, and I was like, "Interesting conversation." So, that's why you got a follower.
Katherine Druckman: I highly recommend if you're listening to this, to go back and listen to the Nikhita Raghunath episode. She had inspiring things to say. Her path has been remarkably interesting.
Divya Mohan: She is one of the most inspiring people that I have had the good fortune of working with and crossing paths with in general. I don't know if you caught the keynote today, but I've heard people saying that it was one of the most kick-ass keynotes they've ever been part of.
Katherine Druckman: I believe that. She's pretty fantastic.
Divya Mohan: Yes.
Roles and Responsibilities at SUSE
Katherine Druckman: But so are you, and I appreciate you being here. I want you to tell us a little bit about your work, and for those who don't know, you work for SUSE and you are heavily involved in the Rancher project, among many other things that you do. But tell us more about what you do.
Divya Mohan: At SUSE, I am on the community team. I'm a principal technology advocate, according to my designation. What I do is similar to what you would talk about regarding developer relations and evangelism. That's the subset of roles that I take on in SUSE. When I talk about the Rancher side of things, it's not just the Rancher side of things that I work with, it's also the SUSE side now. We function as a community evangelism team. We've named ourselves that, unfortunately. It should have been more around developer evangelism or technical advocacy, but with a community team, we've named ourselves that because we also talk often to the community and about the community here at SUSE. I interact with and help foster the community around our projects, whether that be through live shows, talking about it at events such as KubeCon, open source summits, events in general, local, and international, or even creating courses.
We have a course catalog up on Rancher.Academy, which is one of our learning portals that we managed to launch last year. That is another thing that we actively work on. It's not just advocating that you try out our projects, we also teach you how. We also teach you how it fits into the larger cloud native context because we understand that our Kubernetes distributions or our Linux distributions aren't the only ones on the market.
Katherine Druckman: Right.
Divya Mohan: We understand that the onboarding curve can be steep, even from the perspective of just trying it out locally. As a documentation maintainer, one of the things I advocate, when I look at a project, is that you give people the opportunity to try it out locally and teach them how to do it, rather than just saying, "Hey, this works locally." That's one of the things that we are working on at SUSE. Of course, at KubeCon, we have a podcast booth right across from the Intel booth where we're hosting interviews in addition to working at the booth whenever we are free. Does that explain everything?
Importance of Documentation
Katherine Druckman: I'm curious how you ended up here. Did anything attract you to Rancher, or did you fall into it? I talk about this often on this podcast, but documentation is so important. It's one of those things where people repeat that a lot, but they don't internalize it, because I can't tell you how frequently I see people's code, and my one piece of feedback would be, "You might want to document it a little bit better." Right? Because it's one of those things that so frequently gets overlooked when you're getting the job done. And I wondered what attracted you to documentation.
Divya Mohan: That's a good question. It's a bunch of production incidents that I've had throughout my career of eight years in systems engineering. Ninety-five percent of it is a result of poorly documented code, and people are unable to figure out how it all went wrong.
Katherine Druckman: Mm-hmm.
Divya Mohan: Even if it's not that, it's mostly around how the documentation was, in general, a very incomplete artifact that is a part of the release. Therefore, the systems were not documented properly, or the code was not documented properly. Documentation was very integral in my previous job, which I held with HSBC. The reason for that was that we were one of the frontline support folks responsible for maintaining systems. When you're in that level of support, you need to know everything there is about the system that is in a crisis during a crisis.
Katherine Druckman: Absolutely, right? You need to find the answer quickly.
Divya Mohan: You can't just say to a customer who's having a million dollars stuck in the pipeline, "Hey, just wait a little bit. We will get your problem in five minutes when we find the appropriate documentation for it." That was what set me out for bettering documentation in general across the organization I worked with previously. When I started with Kubernetes, the documentation special interest group was the very first one that I got attracted to, because I learn by reading, and I'm an avid reader. My choice of education or learning mode is to learn by actually reading. I do not do things first. I read about them and then act. So, for me, learning Kubernetes was first consulting the documentation and my very first contribution to Kubernetes happened to be through documentation, because I figured that it could be reworded a particular way, or this could be a better feature as an addition.
Of course, thereafter, I did move on to SIG release and then came back to chairing the documentation SIG, which I do currently. That's where it all started. When I started learning Kubernetes, I figured, "Hey, I could tweak this a little better so that the documentation could work better." And that's all it took. There was no motivation for me in terms of, "I want to contribute to open source." I just started with, "I want to make this documentation more accessible for anybody else reading it." Because I was on the receiving end of production incidents I thought, "Maybe this could work better if it was done in a particular way."
Katherine Druckman: That's great. I love the, “see a problem, fix a problem” attitude. It's so important for the sustainability of the projects that we're using, and we're involved in. One of the people who taught me the most about software and the technologies and stuff that I have worked with throughout my career was also a documentation lead. That's something I hope isn't overlooked, but if you want to learn something, make friends with a documentation lead.
Divya Mohan: I have to give a huge plus one to that. I need to give this person a shout-out, Tim Bannister, he's the documentation tech lead currently. He steps down this year, but he's been the documentation tech lead for Kubernetes for quite a while and was one four years back. He's one of those people who knows everything there is to know about the Kubernetes project.
He's very handy during trivia, by the way.
Katherine Druckman: I bet.
Divya Mohan: It's a proven fact. We had a trivia night during one of the Contributor Summit socials in Valencia. The team he was part of won. So, there is value in documentation, folks.
Challenges in Documentation and Code Commenting
Katherine Druckman: Over and over in conversations I feel like I give the feedback of "More comments, please." Right?
Divya Mohan: Yes,
Katherine Druckman: We all fall into this trap, especially when we're working on personal projects or something that we think only we use.
Divya Mohan: Yes.
Katherine Druckman: And whether that ends up being true or not, I think it's easy for us to overlook and say, "Oh, well, this isn't for the community anyway. I can get by. I don't need to comment my own code if it's just for me." And that's one of those things where I also feel like I need to remind myself and others, "Yeah, you absolutely do." Because here is a fact of life. You will look at that even a couple of weeks later and you won't remember why you did anything.
Divya Mohan: I have been there so many times. I've never written code that's made into proper software because I was a systems engineer. I've written plenty of shell scripts.
I can guarantee you that happens every so often when you write scripts where you can't quite figure out the flow.
Katherine Druckman: Absolutely.
Divya Mohan: You ask yourself, "Why did I write this here?" You have to reread it at least a couple of times and even then, you don’t figure it out. It's important to comment your code wherever possible because again, just commenting code might not work in the longer term, but at least it's a start.
Katherine Druckman: It's a start. Absolutely.
Divya Mohan: At least comment your code if nothing else. But do consider having documentation if it's an open source project because commenting code won't be sufficient.
Katherine Druckman: Two different things, but they go hand-in-hand.
Divya Mohan: Yes.
Katherine Druckman: With shell scripts, it's even more important because you're usually talking about automation that you need to understand and remember.
Divya Mohan: It's difficult once you put it into production, it typically doesn't undergo maintenance until it breaks. If it doesn't break, nobody fixes it. That's the policy followed in production, right? If it is not broken, don't try fixing it. Especially with legacy in production, it's really difficult. So, shell scripts aren't often touched, and like you said, it's important. You might not be there when it's being fixed the next time around.
Katherine Druckman: Exactly.
Divya Mohan: Better comment your code, folks.
Single Maintainer Projects and Documentation Advice
Katherine Druckman: That reminds me of a presentation I gave recently and one of the things I mentioned was the rise of single-maintainer projects. It's a thing in open source. It's very much a reality. Shout out to Josh Bressers for his blog post and episode on the topic. So, it's funny when you think of the open source ecosystem, if you can think of it as a single thing, right? Because there are so many ecosystems within it. But, again, when you think of how many people are out there starting new projects and working in small groups or even alone, that's interesting to think of, because those things may pick up steam, and may build a community. It's easy to overlook the documentation when you're working in a small team or alone. What advice would you have for people who are working on fledgling projects about making sure your documentation is good from the beginning?
Divya Mohan: That's an incredibly good question. One that deserves a whole talk.
Katherine Druckman: Yes, that'll be your next conference talk.
Divya Mohan: Yes. Now you gave me my next conference talk. But it's also something we are looking to pitch in terms of sustainability when it comes to docs’ maintenance in general. Believe it or not, even Kubernetes in general, has some of the best written documentation out there. We are still looking for contributors. We still have very few contributors. Kubernetes is one of the largest projects in the cloud native ecosystem.
Katherine Druckman: Yes.
Divya Mohan: If we are finding it difficult, I'm sure it is tough for fledgling projects. My advice would be to consider docs as important as you would consider your code. Firstly, shift it left.
Katherine Druckman: Like security.
Divya Mohan: Yes, you would shift everything to the left if it were an important part of your process, like security is now the hot thing that everybody's worried about. So, shift your documentation to the left.
Challenges in Maintaining Documentation
Katherine Druckman: What happens if we shift everything left, then there's nothing on the right. What's on the right? That'll be the second conference talk.
Divya Mohan: My advice is to document as you go because it's difficult to maintain and create documentation for small projects. It's difficult, because most of them, like you said, are single maintainers or a group of maintainers. When Kubernetes is such a big problem, I completely understand that fledgling projects can have a problem, too, so you need to shift it left. I understand that shifting left also means putting extra effort into writing documentation as you go and maintaining it. What I would suggest is treat it as an artifact that can be incrementally improved. You don't have to get everything fleshed out right at the first goal. It would be good to have it, sure. As a fledgling project, it would be good to have extensive documentation about their features. Who wouldn't love it? But if you're starting out, at least give it the bare minimum and then incrementally improve it, as in when you have cycles.
It's what we do even in Kubernetes. We try to have alpha features or features that aren't user-facing. We try and have a mention of them and incrementally work on documenting and fleshing them out as time goes by because sometimes it's not important to a user to learn what that feature is or to learn what that enhancement is unless it affects them. If it's not being leveraged by a particular user, it's just something that is available and is not affecting the user in any way. Having minimal documentation and incrementally improving upon it is what I would recommend. If you don't mention it, you are likely to forget that you had it in the first place. And this is easy because it's once out of sight out of mind for me. I don't know about everybody else, but it is the case for me.
So, at least mention it and write a line or two about it, then incrementally improve it, as in when you have cycles. Invite contributors and those contributors could use your project and improve the documentation around that particular feature. Those are the two things I can think of for fledgling projects. For larger projects, there's more that you can do concerning advocacy, but for fledgling projects, it's fair to start small and then incrementally improve your content.
Introduction to Bytecode Alliance and WebAssembly
Katherine Druckman: Fantastic. I want to pivot and talk about something else that you're involved in, and that is the Bytecode Alliance.
Divya Mohan: Yes.
Katherine Druckman: Tell us about what that is for those not familiar.
Divya Mohan: The Bytecode Alliance is a nonprofit organization that's developing WebAssembly standards. Now, what is WebAssembly is the next question?
Katherine Druckman: Yes, thank you.
Divya Mohan: WebAssembly unfortunately is a misnomer now because it's neither web nor assembly. Of course, it's relevant to the web, because it is bytecode-ish format, like a binary code-ish format, that's a compiler target. But it's not assembly-level language and it's not just for the web alone. Initially, it was initiated and conceptualized for the web, but when we realized that its applications could go far beyond the web and could be taken to the serverless side of things, to the server side of things, to AI, and other areas, we realized that there was no actual way to do that without developing standards that assist the original specification, which is how standards like WASI have come up. Bytecode Alliance along with W3C, CNCF, and the other partnering organizations who are also nonprofits develop these standards around the WebAssembly ecosystem. I don't know if that summarizes it.
Katherine Druckman: Yes, that's a great summary. What is your involvement?
Divya Mohan: I have been the program co-chair for many events. That's just one small part of it. I advocate for WebAssembly run times and play a community advocate role within the Bytecode Alliance ecosystem. I'm also a community co-chair now. We've not officially started the meetings around the SIG community, but our aim with forming that special interest group, SIG, is to broaden the horizon for the people who get into the WebAssembly ecosystem because a lot of it revolves around misinformation and a lack of information around what WebAssembly is.
Katherine Druckman: That's interesting. Okay.
Divya Mohan: It's important, if you want people to get involved in the ecosystem and help you standardize and develop software, or contribute to open source projects, you need to have something that promotes community involvement. That's what we're trying to do with the special interest group community we've just started. Our first meeting is going to be in the first or the second week of April. That's where it's all going to start because we just put in a proposal, and it got accepted in February. It hasn’t been that long. But other than that, I've also been contributing to documentation in that sphere. Code is important, but for people to understand that code is even more important when it comes to adoption and use.
Katherine Druckman: If nobody's using it or figuring out how to use it, it can only go so far.
Divya Mohan: That's been the two areas that I've been heavily involved in. Of course, the program committee work, and everything is an add-on.
Katherine Druckman: Despite any naming challenges, you're excited about WebAssembly. Why is that and why should other people be excited about WebAssembly?
Divya Mohan: I am going to talk about why I'm excited. I've been in the JavaScript ecosystem for a long time as a system administrator, engineer, and then senior consultant. I've seen a lot of problems arise when you try bringing higher-level programming languages to the web. I have focused on more web applications and mobile application sites since I was working at the bank. I was not working on developing libraries or anything. I can't speak to that standpoint. I can talk about where I come from. I have noticed that there were performance issues when it came to bringing more high-level programming languages to the web. And that's because JavaScript as a target, back then, now is not a great compilation target. It works because there were people who rallied around the ecosystem to get more things accepted, but it was not designed to be a compilation target. Similarly with Java.
I hosted a virtual meetup a while back, wherein when I was researching for it, I found that even in the Java ecosystem, we have the JVM bytecode, right? Even that was not designed to be a compilation target for all the other languages that came in. Like Jython, JRuby, the opcode that introduced that dynamic nature was added fairly later on and it was an afterthought. When you talk about writing code and running anywhere, you can’t achieve it with many of the languages that are currently there, and you can't achieve it with the ecosystem that we have, which is fragmented.
There's this fantastic keynote that I had the great fortune of attending yesterday at Cloud Native WebAssembly Day, where Bailey Hayes said that software development is a team sport, but even within the team sport, we have formed small subteams, and we're trying to achieve the same goal, but we are not doing it very well because the teams themselves aren't coordinated.
Katherine Druckman: That's a good way of putting it.
The Role of Standards in WebAssembly
Divya Mohan: We are not trying to reinvent the wheel by saying, "Okay, just adopt this new programming language and you're all set." We're trying to unify it to enhance the experience across the board. Now, this is a massive task to try to take on, and there have been such initiatives previously. I'm not going to say that this is the very first extremely novel technique that has come out of the minds of the people here, because there have been previous efforts in this space. What WebAssembly does differently is function more inclusively and openly by bringing the ecosystem together, not excluding folks by forming standards, and, developing those standards in the open.
Previous things like native client, portable native client, or even JS, which was the precursor to WebAssembly, all of these were spearheaded by individual companies or organizations. Although they were good solutions, they were not streamlined or developed together. What WebAssembly is trying to do is bring all of these people together who are interested and develop an ecosystem around it, so that we can help standardize across the board, rather than one person doing their own thing, the second person doing the third thing, and make software development a team sport, rather than it being in the current state that it is, which is teams within teams within teams, which is not a great way to play any sport, in my opinion. And I'm not a very sporty person, by the way.
Katherine Druckman: I was. That's a long story for another time. Oh, anyway, your enthusiasm comes across very clearly and I appreciate that, and I hope the ecosystem does as well.
Divya Mohan: I am enthusiastic about the ecosystem because I've been learning it since I started in tech as an electronics engineer. We had this necessary course material in C++ and Java. And everybody kept on saying, "Write once, run anywhere." However, I said, “Nothing actually does scream right once and run anywhere. Nothing."
Katherine Druckman: It's a good slogan.
Divya Mohan: Yes.
Katherine Druckman: I think it's from the '90s though.
Divya Mohan: Yes.
Katherine Druckman: It has to evolve.
Divya Mohan: Everybody in the whole ecosystem and all the academics who taught me, all of them said, "Write once, run anywhere." I said, "Okay, but we are not exactly doing that. What about the newer technologies that come in? What about devices like edge devices or devices that have different CPU architectures? How would you manage all of that? If you are not catering to everybody you're serving; you're not thinking forward. That's what drew me in. We are actively trying to think of what we did wrong or what we were mistaken about in the past. Trying to learn from that and trying to see that it doesn't reoccur again when we are trying to implement things. And I know it's a bold call and a bold journey to start, but even if we fail, it's at least a learning journey.
Katherine Druckman: Well, I like that. I can't top that. Is there anything else that you hoped I might ask you?
Divya Mohan: I enjoy this conversation.
Katherine Druckman: Me too.
Divya Mohan: I am a huge fan of documentation in general, and cloud native has been my jam for the past four years.
Katherine Druckman: I appreciate your efforts and I bet other people out there trying to make their way through this complex ecosystem do as well.
Divya Mohan: Webby landscape, you mean.
Katherine Druckman: I like that, webby landscape. It can get sticky.
Divya Mohan: Yes, it can get sticky.
Katherine Druckman: Thank you so much. I appreciate you, again, taking time out and talking to me, and I think everybody listening will, too.
Divya Mohan: Thank you so much for having me on here. It's been a pleasure chatting with you.
Katherine Druckman: Likewise. You've been listening to Open at Intel. Be sure to check out more from the Open at Intel podcast at open.intel.com/podcast and at OpenatIntel on Twitter. We hope you join us again next time to geek out about open source.
Guest:
Divya Mohan is a senior technical evangelist at SUSE, where she contributes to Rancher’s cloud native open source projects. She co-chairs the documentation for the Kubernetes and LitmusChaos projects and she has previously worked extensively in the systems engineering space during her tenure with HSBC & IGate Global Solutions Pvt Ltd. A co-creator of the KCNA exam and a CNCF ambassador, she is invested in making technical communities and technologies more accessible and inclusive.
About the Host
Katherine Druckman, an Intel open source security evangelist, hosts the podcasts Open at Intel, Reality 2.0, and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she's a long-time champion of open source and open standards. She is a software engineer and content creator with over a decade of experience in engineering, content strategy, product management, user experience, and technology evangelism.