My DEI Journey

, , ,
diversity equity inclusion

This article originally appeared on the Open Mainframe Project’s blog. It is written by Earl Dixon, Principal Client Services Management at Broadcom. 


making our strong community stronger a collaborative initiative

After watching the first Making Our Strong Community Stronger panel on “How Personal Experiences Shape Corporate Inclusion,” I was very interested in the topic and engaged my management team to see what I could do to help in the effort. As a result, I was given the opportunity to participate in the second panel discussion focused on UNMASKING in the work place. I was very eager to participate as I felt the panel would be a great way for me to share my experiences.

As we started to discuss the structure and questions, I did get a little nervous.  I would be going from “not unmasking at work” to “unmasking” for my peers, management, and others in the industry.  We had a dry run for the panel, and I left that being even more nervous.  The other panelists (outside of my peers) were executives and managers who were white and had no issue with unmasking at work.  It was intimidating, but as I talked with Dr. Chance about my feelings, she made me feel more comfortable about moving forward.  As the days wound down closer to the event, I actually grew nervously excited.  Once that day came, I wanted to make sure that my story would be told the way that I needed it to be told. I wanted my story to be real and give an understanding of what it is like being a black man coming up in a white dominated field.



Much to my surprise, the panel went very well, and immediately after doing it, I felt a great sense of relief. It was as if a weight had been lifted off my shoulders.  The experience was very therapeutic for me.  The next day, the Making Our Strong Community Stronger initiative hosted a Town Hall for webinar attendees that had attended the panel discussion live and wanted to ask questions or provide feedback.  I felt even more confident in answering the questions posed by the audience, and it actually made me feel even better that I had been involved.

For the next few days, I received numerous emails, LinkedIn notes, and friend requests from individuals who applauded the webinar and the conversation we were able to have. I also heard stories from others who had similar experiences. Someone even asked me to discuss how my experiences could help him better understand how to support his diverse workforce.

In fact, I met with some of my own management team to discuss what they could be doing better from a DEI perspective. Having leaders from my company ask me questions and listen to what I had to say gave me a sense of appreciation that what we did in our panel was not only being heard, but real action was also occurring to help others coming into this mainframe space to work.

Overall, I am proud of the fact that I was able to participate in the DEI panel and look forward to doing more to help with DEI in the future.  It was a pleasure to work with Dr. Chance and her team in this effort to bring awareness to the truly important DEI issues that go unnoticed in the industry.

/by

‘Master,’ ‘Slave’ and the Fight Over Offensive Terms in Computing (Kate Conger, New York Times, April 13, 2021)

, , , ,

Nearly a year after the Internet Engineering Task Force took up a plan to replace words that could be considered racist, the debate is still raging.

Anyone who joined a video call during the pandemic probably has a global volunteer organization called the Internet Engineering Task Force to thank for making the technology work. The group, which helped create the technical foundations of the internet, designed the language that allows most video to run smoothly online. It made it possible for someone with a Gmail account to communicate with a friend who uses Yahoo, and for shoppers to safely enter their credit card information on e-commerce sites.

Now the organization is tackling an even thornier issue: getting rid of computer engineering terms that evoke racist history, like “master” and “slave” and “whitelist” and “blacklist.”

But what started as an earnest proposal has stalled as members of the task force have debated the history of slavery and the prevalence of racism in tech. Some companies and tech organizations have forged ahead anyway, raising the possibility that important technical terms will have different meanings to different people — a troubling proposition for an engineering world that needs broad agreement so technologies work together.

While the fight over terminology reflects the intractability of racial issues in society, it is also indicative of a peculiar organizational culture that relies on informal consensus to get things done.

The Internet Engineering Task Force eschews voting, and it often measures consensus by asking opposing factions of engineers to hum during meetings. The hums are then assessed by volume and ferocity. Vigorous humming, even from only a few people, could indicate strong disagreement, a sign that consensus has not yet been reached.

The I.E.T.F. has created rigorous standards for the internet and for itself. Until 2016, it required the documents in which its standards are published to be precisely 72 characters wide and 58 lines long, a format adapted from the era when programmers punched their code into paper cards and fed them into early IBM computers.

“We have big fights with each other, but our intent is always to reach consensus,” said Vint Cerf, one of the founders of the task force and a vice president at Google. “I think that the spirit of the I.E.T.F. still is that, if we’re going to do anything, let’s try to do it one way so that we can have a uniform expectation that things will function.”

The group is made up of about 7,000 volunteers from around the world. It has two full-time employees, an executive director and a spokesman, whose work is primarily funded by meeting dues and the registration fees of dot-org internet domains. It cannot force giants like Amazon or Apple to follow its guidance, but tech companies often choose to do so because the I.E.T.F. has created elegant solutions for engineering problems.

Its standards are hashed out during fierce debates on email lists and at in-person meetings. The group encourages participants to fight for what they believe is the best approach to a technical problem.

While shouting matches are not uncommon, the Internet Engineering Task Force is also a place where young technologists break into the industry. Attending meetings is a rite of passage, and engineers sometimes leverage their task force proposals into job offers from tech giants.

In June, against the backdrop of the Black Lives Matter protests, engineers at social media platforms, coding groups and international standards bodies re-examined their code and asked themselves: Was it racist? Some of their databases were called “masters” and were surrounded by “slaves,” which received information from the masters and answered queries on their behalf, preventing them from being overwhelmed. Others used “whitelists” and “blacklists” to filter content.

Mallory Knodel, the chief technology officer at the Center for Democracy and Technology, a policy organization, wrote a proposal suggesting that the task force use more neutral language. Invoking slavery was alienating potential I.E.T.F. volunteers, and the terms should be replaced with ones that more clearly described what the technology was doing, argued Ms. Knodel and the co-author of her proposal, Nielsten Oever, a postdoctoral researcher at the University of Amsterdam. “Blocklist” would explain what a blacklist does, and “primary” could replace “master,” they wrote.

On an email list, responses trickled in. Some were supportive. Others proposed revisions. And some were vehemently opposed. One respondent wrote that Ms. Knodel’s draft tried to construct a new “Ministry of Truth.”

Amid insults and accusations, many members announced that the battle had become too toxic and that they would abandon the discussion.

The pushback didn’t surprise Ms. Knodel, who had proposed similar changes in 2018 without gaining traction. The engineering community is “quite rigid and averse to these sorts of changes,” she said. “They are averse to conversations about community comportment, behavior — the human side of things.”

In July, the Internet Engineering Task Force’s steering group issued a rare statement about the draft from Ms. Knodel and Mr. ten Oever. “Exclusionary language is harmful,” it said.

A month later, two alternative proposals emerged. One came from Keith Moore, an I.E.T.F. contributor who initially backed Ms. Knodel’s draft before creating his own. His cautioned that fighting over language could bottleneck the group’s work and argued for minimizing disruption.

The other came from Bron Gondwana, the chief executive of the email company Fastmail, who said he had been motivated by the acid debate on the mailing list.

“I could see that there was no way we would reach a happy consensus,” he said. “So I tried to thread the needle.”

Mr. Gondwana suggested that the group should follow the tech industry’s example and avoid terms that would distract from technical advances.

Last month, the task force said it would create a new group to consider the three drafts and decide how to proceed, and members involved in the discussion appeared to favor Mr. Gondwana’s approach. Lars Eggert, the organization’s chair and the technical director for networking at the company NetApp, said he hoped guidance on terminology would be issued by the end of the year.

The rest of the industry isn’t waiting. The programming community that maintains MySQL, a type of database software, chose “source” and “replica” as replacements for “master” and “slave.” GitHub, the code repository owned by Microsoft, opted for “main” instead of “master.”

In July, Twitter also replaced a number of terms after Regynald Augustin, an engineer at the company, came across the word “slave” in Twitter’s code and advocated change.

But while the industry abandons objectionable terms, there is no consensus about which new words to use. Without guidance from the Internet Engineering Task Force or another standards body, engineers decide on their own. The World Wide Web Consortium, which sets guidelines for the web, updated its style guide last summer to “strongly encourage” members to avoid terms like “master” and “slave,” and the IEEE, an organization that sets standards for chips and other computing hardware, is weighing a similar change.

Other tech workers are trying to solve the problem by forming a clearinghouse for ideas about changing language.

That effort, the Inclusive Naming Initiative, aims to provide guidance to standards bodies and companies that want to change their terminology but don’t know where to begin.

The group got together while working on an open-source software project, Kubernetes, which like the I.E.T.F. accepts contributions from volunteers. Like many others in tech, it began the debate over terminology last summer.

“We saw this blank space,” said Priyanka Sharma, the general manager of the Cloud Native Computing Foundation, a nonprofit that manages Kubernetes. Ms. Sharma worked with several other Kubernetes contributors, including Stephen Augustus and Celeste Horgan, to create a rubric that suggests alternative words and guides people through the process of making changes without causing systems to break. Several major tech companies, including IBM and Cisco, have signed on to follow the guidance.

Priyanka Sharma

Priyanka Sharma and several other tech workers in the Inclusive Naming Initiative came up
with a rubric to suggest alternative words

Although the Internet Engineering Task Force is moving more slowly, Mr. Eggert said it would eventually establish new guidelines. But the debate over the nature of racism — and whether the organization should weigh in on the matter — has continued on its mailing list.

In a subversion of an April Fools’ Day tradition within the group, several members submitted proposals mocking diversity efforts and the push to alter terminology in tech.

Two prank proposals were removed hours later because they were “racist and deeply disrespectful,” Mr. Eggert wrote in an email to task force participants, while a third remained up.

“We build consensus the hard way, so to speak, but in the end the consensus is usually stronger because people feel their opinions were reflected,” Mr. Eggert said. “I wish we could be faster, but on topics like this one that are controversial, it’s better to be slower.”

Kate Conger is a technology reporter in the San Francisco bureau, where she covers the gig economy and social media. @kateconger

/by

New Open Source Projects to Confront Racial Justice

, , ,

Today the Linux Foundation announced that it would be hosting seven projects that originated at Call for Code for Racial Justice, an initiative driven by IBM and Creator David Clark Cause to urge the global developer ecosystem and open source community to contribute to solutions that can help confront racial inequalities. 

Launched by IBM in October 2020, Call for Code for Racial Justice facilitates the adoption and innovation of open source projects by developers, ecosystem partners, and communities across the world to promote racial justice across three distinct focus areas: Police & Judicial Reform and Accountability; Diverse Representation; and Policy & Legislation Reform. 

The initiative builds upon Call for Code, created by IBM in 2018 and has grown to over 400,000 developers and problem solvers in 179 countries, in partnership with Creator David Clark Cause, Founding Partner IBM, Charitable Partner United Nations Human Rights, and the Linux Foundation.

As part of today’s announcement, the Linux Foundation and IBM unveiled two new solution starters, Fair Change and TakeTwo: 

Fair Change is a platform to help record, catalog, and access evidence of potentially racially charged incidents to enable transparency, reeducation, and reform as a matter of public interest and safety. For example, real-world video footage related to routine traffic stops, stop and search, or other scenarios may be recorded and accessed by the involved parties and authorities to determine whether the incidents were handled in a biased manner. Fair Change consists of a mobile application for iOS and Android built using React Native, an API for capturing data from various sources built using Node JS. It also includes a website with a geospatial map view of incidents built using Google Maps and React. Data can be stored in a cloud-hosted database and object-store. Visit the tutorial or project page to learn more. 

TakeTwo aims to help mitigate digital content bias, whether overt or subtle, focusing on text across news articles, headlines, web pages, blogs, and even code. The solution is designed to leverage directories of inclusive terms compiled by trusted sources like the Inclusive Naming Initiative, which the Linux Foundation and CNCF co-founded. The terminology is categorized to train an AI model to enhance its accuracy over time. TakeTwo is built using open source technologies, including Python, FastAPI, and Docker. The API can be run locally with a CouchDB backend database or IBM Cloudant database. IBM has already deployed TakeTwo within its existing IBM Developer tools that are used to publish new content produced by hundreds of IBMers each week. IBM is trialing TakeTwo for IBM Developer website content. Visit the tutorial or project page to learn more.

In addition to the two new solution starters, The Linux Foundation will now host five existing and evolving open source projects from Call for Code for Racial Justice:

  • Five-Fifths Voter: This web app empowers minorities to exercise their right to vote and ensures their voice is heard by determining optimal voting strategies and limiting suppression issues.
  • Legit-Info: Local legislation can significantly impact areas as far-reaching as jobs, the environment, and safety. Legit-Info helps individuals understand the legislation that shapes their lives.
  • Incident Accuracy Reporting System: This platform allows witnesses and victims to corroborate evidence or provide additional information from multiple sources against an official police report.
  • Open Sentencing: To help public defenders better serve their clients and make a stronger case, Open Sentencing shows racial bias in data such as demographics.
  • Truth Loop: This app helps communities simply understand the policies, regulations, and legislation that will impact them the most.  

These projects were built using open source technologies that include Red Hat OpenShift, IBM Cloud, IBM Watson, Blockchain ledger, Node.js, Vu.js, Docker, Kubernetes, and Tekton. The Linux Foundation and IBM ask developers and ecosystem partners to contribute to these solutions by testing, extending, implementing them, and adding their own diverse perspectives and expertise to make them even stronger. 

For more information and to begin contributing, please visit: 

https://developer.ibm.com/callforcode/racial-justice/get-started/

https://developer.ibm.com/callforcode/racial-justice/projects/  

https://www.linuxfoundation.org/projects/call-for-code/  

https://github.com/Call-for-Code-for-Racial-Justice/

/by

Interview with Shuah Khan, Kernel Maintainer & Linux Fellow

, , , , , , , ,

Jason Perlow, Director of Project Insights and Editorial Content at the Linux Foundation, had an opportunity to speak with Shuah Khan about her experiences as a woman in the technology industry. She discusses how mentorship can improve the overall diversity and makeup of open source projects, why software maintainers are important for the health of open source projects such as the Linux kernel, and how language inclusivity and codes of conduct can improve relationships and communication between software maintainers and individual contributors.

JP: So, Shuah, I know you wear many different hats at the Linux Foundation. What do you call yourself around here these days?

SK: <laughs> Well, I primarily call myself a Kernel Maintainer & Linux Fellow. In addition to that, I focus on two areas that are important to the continued health and sustainability of the open source projects in the Linux ecosystem. The first one is bringing more women into the Kernel community, and additionally, I am leading the mentorship program efforts overall at the Linux Foundation. And in that role, in addition to the Linux Kernel Mentorship, we are looking at how the Linux Foundation mentorship program is working overall, how it is scaling. I make sure the LFX Mentorship platform scales and serves diverse mentees and mentors’ needs in this role. 

The LF mentorships program includes several projects in the Linux kernel, LFN, HyperLedger, Open MainFrame, OpenHPC, and other technologies. The Linux Foundation’s Mentorship Programs are designed to help developers with the necessary skills–many of whom are first-time open source contributors–experiment, learn, and contribute effectively to open source communities. 

The mentorship program has been successful in its mission to train new developers and make these talented pools of prospective employees trained by experts to employers. Several graduated mentees have found jobs. New developers have improved the quality and security of various open source projects, including the Linux kernel. Several Linux kernel bugs were fixed, a new subsystem mentor was added, and a new driver maintainer is now part of the Linux kernel community. My sincere thanks to all our mentors for volunteering to share their expertise.

JP: How long have you been working on the Kernel?

SK: Since 2010, or 2011, I got involved in the Android Mainlining project. My first patch removed the Android pmem driver.

JP: Wow! Is there any particular subsystem that you specialize in?

SK: I am a self described generalist. I maintain the kernel self-test subsystem, the USB over IP driver, usbip tool, and the cpupower tool. I contributed to the media subsystem working on Media Controller Device Allocator API to resolve shared device resource management problems across device drivers from different subsystems.

JP: Hey, I’ve actually used the USB over IP driver when I worked at Microsoft on Azure. And also, when I’ve used AWS and Google Compute. 

SK: It’s a small niche driver used in cloud computing. Docker and other containers use that driver heavily. That’s how they provide remote access to USB devices on the server to export devices to be imported by other systems for use.

JP: I initially used it for IoT kinds of stuff in the embedded systems space. Were you the original lead developer on it, or was it one of those things you fell into because nobody else was maintaining it?

SK: Well, twofold. I was looking at USB over IP because I like that technology. it just so happened the driver was brought from the staging tree into the Mainline kernel, I volunteered at the time to maintain it. Over the last few years, we discovered some security issues with it, because it handles a lot of userspace data, so I had a lot of fun fixing all of those. <laugh>.

JP: What drew you into the Linux operating system, and what drew you into the kernel development community in the first place?

SK: Well, I have been doing kernel development for a very long time. I worked on the LynxOS RTOS, a while back, and then HP/UX, when I was working at HP, after which I transitioned into  doing open source development — the OpenHPI project, to support HP’s rack server hardware, and that allowed me to work much more closely with Linux on the back end. And at some point, I decided I wanted to work with the kernel and become part of the Linux kernel community. I started as an independent contributor.

JP: Maybe it just displays my own ignorance, but you are the first female, hardcore Linux kernel developer I have ever met. I mean, I had met female core OS developers before — such as when I was at Microsoft and IBM — but not for Linux. Why do you suppose we lack women and diversity in general when participating in open source and the technology industry overall?

SK: So I’ll answer this question from my perspective, from what I have seen and experienced, over the years. You are right; you probably don’t come across that many hardcore women Kernel developers. I’ve been working professionally in this industry since the early 1990s, and on every project I have been involved with, I am usually the only woman sitting at the table. Some of it, I think, is culture and society. There are some roles that we are told are acceptable to women — even me, when I was thinking about going into engineering as a profession. Some of it has to do with where we are guided, as a natural path. 

There’s a natural resistance to choosing certain professions that you have to overcome first within yourself and externally. This process is different for everybody based on their personality and their origin story. And once you go through the hurdle of getting your engineering degree and figuring out which industry you want to work in, there is a level of establishing credibility in those work environments you have to endure and persevere. Sometimes when I would walk into a room, I felt like people were looking at me and thinking, “why is she here?” You aren’t accepted right away, and you have to overcome that as well. You have to go in there and say, “I am here because I want to be here, and therefore, I belong here.” You have to have that mindset. Society sends you signals that “this profession is not for me” — and you have to be aware of that and resist it. I consider myself an engineer that happens to be a woman as opposed to a woman engineer.

JP: Are you from India, originally?

SK: Yes.

JP: It’s funny; my wife really likes this Netflix show about matchmaking in India. Are you familiar with it?

SK: <laughs> Yes I enjoyed the series, and A Suitable Girl documentary film that follows three women as they navigate making decisions about their careers and family obligations.

JP: For many Americans, this is our first introduction to what home life is like for Indian people. But many of the women featured on this show are professionals, such as doctors, lawyers, and engineers. And they are very ambitious, but of course, the family tries to set them up in a marriage to find a husband for them that is compatible. As a result, you get to learn about the traditional values and roles they still want women to play there — while at the same time, many women are coming out of higher learning institutions in that country that are seeking technical careers. 

SK: India is a very fascinatingly complex place. But generally speaking, in a global sense, having an environment at home where your parents tell you that you may choose any profession you want to choose is very encouraging. I was extremely fortunate to have parents like that. They never said to me that there was a role or a mold that I needed to fit into. They have always told me, “do what you want to do.” Which is different; I don’t find that even here, in the US. Having that support system, beginning in the home to tell you, “you are open to whatever profession you want to choose,” is essential. That’s where a lot of the change has to come from. 

JP: Women in technical and STEM professions are becoming much more prominent in other countries, such as China, Japan, and Korea. For some reason, in the US, I tend to see more women enter the medical profession than hard technology — and it might be a level of effort and perceived reward thing. You can spend eight years becoming a medical doctor or eight years becoming a scientist or an engineer, and it can be equally difficult, but the compensation at the end may not be the same. It’s expensive to get an education, and it takes a long time and hard work, regardless of the professional discipline.

SK: I have also heard that women also like to enter professions where they can make a difference in the world — a human touch, if you will. So that may translate to them choosing careers where they can make a larger impact on people — and they may view careers in technology as not having those same attributes. Maybe when we think about attracting women to technology fields, we might have to promote technology aspects that make a difference. That may be changing now, such as the LF Public Health (LFPH) project we kicked off last year. And with LF AI & Data Foundation, we are also making a difference in people’s lives, such as detecting earthquakes or analyzing climate change. If we were to promote projects such as these, we might draw more women in.

JP: So clearly, one of the areas of technology where you can make a difference is in open source, as the LF is hosting some very high-concept and existential types of projects such as LF Energy, for example — I had no idea what was involved in it and what its goals were until I spoke to Shuli Goodman in-depth about it. With the mentorship program, I assume we need this to attract fresh talent — because as folks like us get older and retire, and they exit the field, we need new people to replace them. So I assume mentorship, for the Linux Foundation, is an investment in our own technologies, correct?

SK: Correct. Bringing in new developers into the fold is the primary purpose, of course — and at the same time, I view the LF as taking on mentorship provides that neutral, level playing field across the industry for all open source projects. Secondly, we offer a self-service platform, LFX Mentorship, where anyone can come in and start their project. So when the COVID-19 pandemic began, we expanded this program to help displaced people — students, et cetera, and less visible projects. Not all projects typically get as much funding or attention as others do — such as a Kubernetes or  Linux kernel — among the COVID mentorship program projects we are funding. I am particularly proud of supporting a climate change-related project, Using Machine Learning to Predict Deforestation.

The self-service approach allows us to fund and add new developers to projects where they are needed. The LF mentorships are remote work opportunities that are accessible to developers around the globe. We see people sign up for mentorship projects from places we haven’t seen before, such as Africa, and so on, thus creating a level playing field. 

The other thing that we are trying to increase focus on is how do you get maintainers? Getting new developers is a starting point, but how do we get them to continue working on the projects they are mentored on? As you said, someday, you and I and others working on these things are going to retire, maybe five or ten years from now. This is a harder problem to solve than training and adding new developers to the project itself.

JP: And that is core to our software supply chain security mission. It’s one thing to have this new, flashy project, and then all these developers say, “oh wow, this is cool, I want to join that,” but then, you have to have a certain number of people maintaining it for it to have long-term viability. As we learned in our FOSS study with Harvard, there are components in the Linux operating system that are like this. Perhaps even modules within the kernel itself, I assume that maybe you might have only one or two people actively maintaining it for many years. And what happens if that person dies or can no longer work? What happens to that code? And if someone isn’t familiar with that code, it might become abandoned. That’s a serious problem in open source right now, isn’t it?

SK: Right. We have seen that with SSH and other security-critical areas. What if you don’t have the bandwidth to fix it? Or the money to fix it? I ended up volunteering to maintain a tool for a similar reason when the maintainer could no longer contribute regularly. It is true; we have many drivers where maintainer bandwidth is an issue in the kernel. So the question is, how do we grow that talent pool?

JP: Do we need a job board or something? We need X number of maintainers. So should we say, “Hey, we know you want to join the kernel project as a contributor, and we have other people working on this thing, but we really need your help working on something else, and if you do a good job, we know tons of companies willing to hire developers just like you?” 

SK: With the kernel, we are talking about organic growth; it is just like any other open source project. It’s not a traditional hire and talent placement scenario. Organically they have to have credibility, and they have to acquire it through experience and relationships with people on those projects. We just talked about it at the previous Linux Plumbers Conference, we do have areas where we really need maintainers, and the MAINTAINERS file does show areas where they need help. 

To answer your question, it’s not one of those things where we can seek people to fill that role, like LinkedIn or one of the other job sites. It has to be an organic fulfillment of that role, so the mentorship program is essential in creating those relationships. It is the double-edged sword of open source; it is both the strength and weakness. People need to have an interest in becoming a maintainer and also a commitment to being one, long term.

JP: So, what do you see as the future of your mentorship and diversity efforts at the Linux Foundation? What are you particularly excited about that is forthcoming that you are working on?

SK: I view the Linux Foundation mentoring as a three-pronged approach to provide unstructured webinars, training courses, and structured mentoring programs. All of these efforts combine to advance a diverse, healthy, and vibrant open source community. So over the past several months, we have been morphing our speed mentorship style format into an expanded webinar format — the LF Live Mentorship series. This will have the function of growing our next level of expertise. As a complement to our traditional mentorship programs, these are webinars and courses that are an hour and a half long that we hold a few times a month that tackle specific technical areas in software development. So it might cover how to write great commit logs, for example, for your patches to be accepted, or how to find bugs in C code. Commit logs are one of those things that are important to code maintenance, so promoting good documentation is a beneficial thing. Webinars provide a way for experts short on time to share their knowledge with a few hours of time commitment and offer a self-paced learning opportunity to new developers.

Additionally, I have started the Linux Kernel Mentorship forum for developers and their mentors to connect and interact with others participating in the Linux Kernel Mentorship program and graduated mentees to mentor new developers. We kicked off Linux Kernel mentorship Spring 2021 and are planning for Summer and Fall.

A big challenge is we are short on mentors to be able to scale the structured program. Solving the problem requires help from LF member companies and others to encourage their employees to mentor, “it takes a village,” they say.

JP: So this webinar series and the expanded mentorship program will help developers cultivate both hard and soft skills, then.

SK: Correct. The thing about doing webinars is that if we are talking about this from a diversity perspective, they might not have time for a full-length mentorship, typically like a three-month or six-month commitment. This might help them expand their resources for self-study. When we ask for developers’ feedback about what else they need to learn new skill sets, we hear that they don’t have resources, don’t have time to do self-study, and learn to become open source developers and software maintainers. This webinar series covers general open source software topics such as the Linux kernel and legal issues. It could also cover topics specific to other LF projects such as CNCF, Hyperledger, LF Networking, etc.

JP: Anything else we should know about the mentorship program in 2021?

SK: In my view,  attracting diversity and new people is two-fold. One of the things we are working on is inclusive language. Now, we’re not talking about curbing harsh words, although that is a component of what we are looking at. The English you and I use in North America isn’t the same English used elsewhere. As an example, when we use North American-centric terms in our email communications, such as when a maintainer is communicating on a list with people from South Korea, something like “where the rubber meets the road” may not make sense to them at all. So we have to be aware of that.

JP: I know that you are serving on the Linux kernel Code of Conduct Committee and actively developing the handbook. When I first joined the Linux Foundation, I learned what the Community Managers do and our governance model. I didn’t realize that we even needed to have codes of conduct for open source projects. I have been covering open source for 25 years, but I come out of the corporate world, such as IBM and Microsoft. Codes of Conduct are typically things that the Human Resources officer shows you during your initial onboarding, as part of reviewing your employee manual. You are expected to follow those rules as a condition of employment. 

So why do we need Codes of Conduct in an open source project? Is it because these are people who are coming from all sorts of different backgrounds, companies, and ways of life, and may not have interacted in this form of organized and distributed project before? Or is it about personalities, people interacting with each other over long distance, and email, which creates situations that may arise due to that separation?

SK: Yes, I come out of the corporate world as well, and of course, we had to practice those codes of conduct in that setting. But conduct situations arise that you have to deal with in the corporate world. There are always interpersonal scenarios that can be difficult or challenging to work with — the corporate world isn’t better than the open source world in that respect. It is just that all of that happens behind a closed setting.

But there is no accountability in the open source world because everyone participates out of their own free will. So on a small, traditional closed project, inside the corporate world, where you might have 20 people involved, you might get one or two people that could be difficult to work with. The same thing happens and is multiplied many times in the open source community, where you have hundreds of thousands of developers working across many different open source projects. 

The biggest problem with these types of projects when you encounter situations such as this is dealing with participation in public forums. In the corporate world, this can be addressed in private. But on a public mailing list, if you are being put down or talked down to, it can be extremely humiliating. 

These interactions are not always extreme cases; they could be simple as a maintainer or a lead developer providing negative feedback — so how do you give it? It has to be done constructively. And that is true for all of us.

JP: Anything else?

SK: In addition to bringing our learnings and applying this to the kernel project, I am also doing this on the ELISA project, where I chair the Technical Steering Committee, where I am bridging communication between experts from the kernel and the safety communities. To make sure we can use the kernel the best ways in safety-critical applications, in the automotive and medical industry, and so on. Many lessons can be learned in terms of connecting the dots, defining clearly what is essential to make Linux run effectively in these environments, in terms of dependability. How can we think more proactively instead of being engaged in fire-fighting in terms of security or kernel bugs? As a result of this, I am also working on any necessary kernel changes needed to support these safety-critical usage scenarios.

JP: Before we go, what are you passionate about besides all this software stuff? If you have any free time left, what else do you enjoy doing?

SK: I read a lot. COVID quarantine has given me plenty of opportunities to read. I like to go hiking, snowshoeing, and other outdoor activities. Living in Colorado gives me ample opportunities to be in nature. I also like backpacking — while I wasn’t able to do it last year because of COVID — I like to take backpacking trips with my son. I also love to go to conferences and travel, so I am looking forward to doing that again as soon as we are able.

Talking about backpacking reminded me of the two-day, 22-mile backpacking trip during the summer of 2019 with my son. You can see me in the picture above at the end of the road, carrying a bearbox, sleeping bag, and hammock. It was worth injuring my foot and hurting in places I didn’t even know I had.

JP: Awesome. I enjoyed talking to you today. So happy I finally got to meet you virtually.

/by

Linux Foundation Support for the Black Community

, ,

The Linux Foundation and its communities stand in solidarity voicing support for the Black community. The system under which we operate requires change to make justice and equality a reality. We support the individuals and organizations offering solutions for such changes, and we will be planning how we can support change as well.

We are proud (and privileged) to work with communities and members that support our initiatives and reflect the same values. We have collected statements from across our communities that voice this collective support.

Statement from Arpit Joshipura, General Manager of Networking, IoT and Edge (LF Networking and LF Edge)

Members,

We at LFN and LF Edge are disheartened by the current situation of injustice, hate, and division we are seeing and believe recent actions are the opposite of our values. LFN and LF Edge are global umbrella organizations based on diversity, collaboration, mutual understanding, and respect. It is the essence of the very community building we engage in professionally.

The Linux Foundation has long stood for inclusion and open participation and has supported individuals and collective communities in our knowledge that diversity is a strength. We will continue to promote those values and do more.

Finally and most importantly, this is a time for most of us to listen, to listen to the experiences of our members who experience racism in their personal and professional lives. This is not a time to be defensive; this is a time to hear about experiences of our fellow members. We at LFN and LF Edge are here to listen. If you would like to have a discussion about this topic, please send me a note as well.

Statement from Kate Stewart, Sr. Director of Strategic Programs (Zephyr Project)

Dear Zephyr Project Community

When we started the Zephyr project, one of the goals was to come up with a solution to a very fragmented ecosystem for applications where Linux was just too big. Thanks to you, we have been succeeding, step by incremental step. We are focused on the common goal of building the best RTOS in the landscape while establishing a diverse and inclusive community. And while we may not always agree with each other in all details, one of the things that stands out for me is we’re all willing to listen to each other.

As we watch the news, the events in the U.S. over inequality and the ongoing COVID-19 pandemic, it’s hard to figure out how we can make a difference as individuals and as a larger group. Injustice, division, and isolation are causing harm in our society, and the effects are touching every single one of us. We’ve seen Zephyr members and our community start creating solutions to help with COVID-19, and it would be wonderful if the same creativity can be focused on the wider diversity problems as well.

While I don’t have the answers here, I do see this as a moment for us to listen and build from. We must seek to understand the enormous injustice and pain that results from inequality and isolation. Please take the time to engage on this topic with your families, friends, local and global communities, and use the creativity I see being demonstrated every day by the Zephyr community to help us come up with ideas for change.

If you would like to have a discussion about this topic, please send me a note as well.

Above all, let us continue to be examples within our broader and local communities, while staying engaged so that we can be a part of a larger change for the better.

Statement from John Mertic, Director (Open Mainframe)

We are all disheartened by the current issues in the US brought to the forefront of the news. Injustice and division are causing harm in our society, and the effects are touching every single one of us. I’ve personally seen the effects of this amongst my immediate family and close friends, which saddens me deeply. This is the opposite of our values as humans and my hope is that this brings the conversation of diversity to the forefront.

The Open Mainframe Project, along with The Linux Foundation, is an organization based on collaboration and mutual understanding. It is the essence of the very community-building we engage in professionally. All of us are stronger than one of us and diverse communities have always driven greater outcomes.

Our strength over the past decades has been the community’s desire to continue its legacy well past our lifetime. The only way to achieve this is by emphasising the focus on diversity – and events like what we’ve seen unfold nationwide illustrate how far we still need to go.

While I don’t have the answers here, I do see this as a moment for us to listen. We must seek to understand the enormous injustice and pain that results from inequality in our society. Please take the time to engage on this topic with your families, friends, local and global communities.

If you would like to have a discussion about this topic, please send me a note as well.

Above all, let us continue to be examples within our broader and local communities, while staying engaged so that we can be part of a larger change for the better.

/by

How Contributing to Diversity in Technology Made Me a Better Engineer

, ,

Because my family couldn’t afford tuition, I couldn’t pursue my true interest Computer Science and, instead, studied Metallurgical Engineering — a field that I had absolutely no interest in.

As I waited in line for the interview with an Iron extraction company, millions of thoughts running through my mind:

“Will be able to work in a field with no interest for my entire life?”,

“Will I be happy and satisfied here?”

“Is this opportunity big enough for the ambitions I have?”, “Has fortune done justice to all the sleepless nights of mine?”.

There was a part of me that kept asking whether this is what I wanted to do.

The very next moment, I left the line and went back to my room, skipping my interview.

After doing a lot of research for the next two days, I came to know about Google Summer of Code (GSoC), a program run by Google where students make contributions to open source software in return for recognition in the technology industry. I had 6 months in hand, for the only chance of getting selected in GSoC and steering my career path into software engineering.

I started learning to program, from basic algorithms in C, to building backend APIs in Django and building frontend UI in Angular and React.js. I gave it my all. This was followed by making significant contributions to open source projects to get selected for the program. Day in and day out, I kept making code contribution to recognised organisations such as Zulip, FOSSASIA, National Resource for Network Biology(NRNB) and Oppia. I decided to submit proposals for the first three, and managed to get shortlisted in all of them, finally going ahead with NRNB.

The following month, I got selected for another open source program called CodeSprint run by the Open Web Application Security Project (OWASP), a recognised organisation in web and application security. I worked on both the programs simultaneously and successfully completed my work, receiving good reviews from my mentors. A few months later, after making code contributions for 4 long months, I managed to become the Grand Prize Winner of another open source program called CodeHeat run by FOSSASIA.

Although I graduated with a degree in metallurgical engineering, I secured a job as a software engineer in the silicon valley of India, Bangalore. Open source software provided me a platform to showcase my skills, network with other developers and expand my knowledge of software development.

I also learnt about the lack of diversity in the technology field, and realized that I can actually make a difference to it through open source. I began mentoring students, the majority of which were women. I delivered talks about my journey and career transition in local meetups to inspire people and tell them how open source can help someone. I kept on teaching women, and people underrepresented in technology, in various open source programs such as GSoC, Google Code In, Rails Girls Summer of Code, LearnITGirl, Wootech Mentorship program Singapore to name a few. By that time, came to know about cloud native, and open source organisations such as Linux Foundation and CNCF. I also realized that I would need to learn more about these technologies in order to be better developer and mentor. I began learning more and more about these technologies to be better than average developers.

In order to improve myself and learn more of these advanced technologies, I went out of my comfort zone and started going to local hackathons and conferences. But I wanted to learn more about these technologies and also enhance my public speaking skills to deliver tech talks in conferences. I discovered the Linux Foundation’s Open Source Summit North America 2019, and how attending the event would help me improve myself. However, I did not have sufficient funds to support my trip to California. I applied for travel fund through Linux Foundation, but wasn’t very optimistic about it. But one fine day after 3 months of wait, I woke up to an email titled “Congratulations, your travel fund request for OSSNA has been accepted”. It was when I realized how much the community cherishes an open source contributor. I was thrilled and overjoyed!

The conference week arrived, I landed in Los Angeles, travelled to San Diego by Train, and arrived at the conference venue at Hilton. I started getting the Open Source Summit vibe the moment I arrived. I used the Sched app in order to plan my schedule and decide which talks to attend. The sheer diversity in the topics covered in talks from cloud technologies to embedded systems, coupled with an opportunity to network with attendees of various backgrounds doing phenomenal work in open source has made my experience memorable. The event started with keynote by Jim Zemlin, Executive Director at Linux Foundation, where he shared about Confidential Computing Consortium. This was followed by Jeff Clune, Senior Research Manager at Uber AI talking about Fueling Innovation by creating, collecting, and improving stepping stones. One other keynote that I would like to highlight is A.I. and Stephen Hawking ACAT by Kairan Quazi. He is truly an inspiration.

Some of the talks that really stood out includes “Peeling Layers: A Deep Dive into Kubernetes Networking”, “Helm 3: Navigating To Distant Shores”, “Machine Learning Made Easy on Kubernetes”, “Kubernetes Housekeeping”, “Out of the Box Observability and Tracing in Kubernetes with Kong, Zipkin and Prometheus”, “Use cases of Kubeflow” etc.

I also attended the sponsor showcase to know more about the latest advancement of their products, network with some of the most amazing people in open source, and learn more about the job opportunities they provide. Also, I would never be able to forget the Attendee Reception at USS Midway Museum and Puppy Pawlooza <3

I learnt so much and had lots of fun at the conference. This would not have been possible without Linux Foundation and I couldn’t thank them enough for giving me this opportunity. Special thanks to Jacynth Roberts for being so helpful. Looking forward to keep on contributing to FOSS and speaking at future Open Source Summits.

/by

The Linux Kernel Mentorship program was a life changing experience

, ,

By Bharath Vedartham

Operating systems, computer architectures and compilers have always fascinated me. I like to go in depth to understand the important software components we depend on! My life changed when engineers from IBM LTC (Linux Technology Center) came to my college to teach us the Linux Kernel internals. When I heard about the Linux Kernel Mentorship program, I immediately knew that I wanted to be a part of it to further fuel my passion for Linux.

One of the project in the lists of projects available to work during the Linux Kernel Mentorship program was on “Predictive Memory Reclamation”. I really wanted the opportunity to work on the core kernel, and I began working with my mentor Khalid Aziz immediately during the application period where he gave me a task regarding the identification of anonymous memory regions for a process. I learned a lot in the application period by reading various blogs, textbooks and commit logs.

During my mentorship period, I worked to develop a predictive memory reclamation algorithm in the Linux Kernel. The aim of the project was to reduce the amount of time the Linux kernel spends in reclaiming memory to satisfy processes requests for memory when there is memory pressure, i.e not enough to satisfy the memory allocation of a process. We implemented a predictive algorithm that can forecast memory pressure and proactively reclaim memory to ensure there is enough available for processes.

We achieved a reduction of upto 8% in the amount of time the kernel spends in reclaiming memory! We submitted RFCs on the kernel mailing lists of our work. [1]

I also worked with John Hubbard on his project to track get_user_pages(). I converted a couple of drivers to use the new get_user_pages API as proposed by John. John was a real pleasure to work with!

Throughout my internship, I have learned that the kernel community is very helpful, kind and willing to help new developers. The key was to take the feedback and put in the required effort and work as well as accept constructive feedback and act on it. Working on open source projects was a very liberating experience for me. There are no barriers in open source space. Anyone can work on open source code irrespective of their nationality, creed or company affiliations, which I find very beautiful and liberating. I believe it is a very intellectually stimulating experience for anyone.

I would like to thank my mentor Khalid Aziz and the Linux Kernel community for helping me throughout the mentorship program. I also would like to thank the Linux Foundation for providing this opportunity and especially Shuah Khan for her guidance on how to work with the community.

https://lkml.org/lkml/2019/8/12/1302

/by

The Linux Kernel Mentorship is Life Changing

, ,

Guest Post By Kelsey Skunberg, Linux Kernel Mentorship Program Mentee

 

My name is Kelsey Skunberg and I am starting my senior year for my Undergraduate in Computer Science at Colorado State University. This summer, I had the honor of participating in the Linux Kernel Mentorship Program through CommunityBridge. Throughout the mentorship, I grew very fond of working on open source projects, learned to work with the open source communities, and my confidence as a developer has grown tremendously.

Since the beginning, I found the Linux kernel community to be very welcoming and willing to help. Many of the developers and maintainers have taken time to answer questions, review patches, and provide advice. I’ve come to learn contributing is not quite as scary as I first anticipated. It’s ok to make mistakes, just be open to learning and new ideas. There are a lot of resources for learning, and developers willing to invest time in mentoring and helping new contributors.

Before learning of the Linux Kernel Mentorship Program, I was interested in learning how to contribute to the Linux kernel, but didn’t know how and where to start. The application process alone helped me learn the basics of Linux kernel development, how to get started contributing, and more importantly how to work with the kernel community.

The application process gave me the foundation needed to contribute to the Linux kernel by teaching me how to build patches, debug, complete boot tests, and start working with open source communities. I was able to grow these new skills throughout the mentorship program while working on my selected project.

I chose to work on PCI Utilities and Linux PCI with Bjorn Helgaas as my mentor. Bjorn has been an incredible mentor who provided me with a great amount of advice and has introduced me to several tools which make the development process easier.

My project has consisted of multiple tasks that helped clean up code, and enhance existing PCI features.

I enhanced lspci to:

  • Decode AIDA64 log files (Started by Bjorn Helgaas)
  • Decode earlydump output (Started by Bjorn Helgaas)

I restructured and improved lspci and Linux PCI code by:

  • Finding and removing unused code (functions, API)
  • Moving functions to better locations
  • Improved logic to improve maintainability of Linux PCI code paths

I’ve been able to study how PCI works, learn how to navigate the kernel tree, and gained a lot of experience working with the Linux kernel community to get patches applied successfully.

I am also very thankful for the mentorship program for bringing me to Open Source Summit 2019 in San Diego, where I’ve been able to learn, network, and work on my public speaking. I co-presented with Shuah Khan about my experience as a mentee. View my presentation slides.

Moving forward, I plan to continue contributing to the Linux kernel and being part of the Linux kernel community even after the mentorship ends. I’ve truly enjoyed the past three months and while I continue to learn, I hope I can pass on what knowledge I’ve gained to future mentees and others interested in learning Linux kernel development while I continue to grow myself.

Thank you Shuah and the Linux Foundation for this opportunity. I am thankful to everyone who has helped me get my feet on the ground.

/by

Announcing The Linux Kernel Mentorship project on CommunityBridge, a new Linux Foundation platform

, ,

The Linux Kernel Mentorship ProjectWhen Jim Zemlin asked me to come to the Linux Foundation as a Linux Fellow to work on mentoring programs and initiatives to make Linux secure I didn’t have to think twice. I am very excited to be working at the Linux Foundation alongside talented and dedicated individuals on initiatives near and dear to my heart. It is a unique and special opportunity to share my knowledge and passion by helping aspiring developers discover the joy of being a part of the largest open source project  in the world.

Contributing to the Linux kernel and working in open source is my passion. It is an honor to be a contributor to the software that influences and touches everybody in the world whether they know it or not.  Being a part of something that has changed the way we communicate, conduct business, learn, and interact with each other is something that myself and thousands of developers worldwide share with pride as part of the Linux community.

My journey as a Linux Kernel contributor started as a fun experiment to help take Android code and make it part of the core Linux project. I loved the experience of being part of the community and started looking for more opportunities to engage with it. When Greg Kroah-Hartman was looking for volunteers to help him with the stable release maintenance activities, I signed up.

As I continued to work in the kernel community, Greg asked me to help take on the task of improving Linux kernel quality by maintaining the Linux Kselftest subsystem. This has given me the opportunity to work with developers and maintainers with vast experience in various parts of the kernel. It keeps me on my toes and gives me a tremendous opportunity to learn and to help strengthen Linux kernel quality and validation efforts. In addition, I assist stable release maintainers, maintain USB over IP, cpupower tool, contribute to Linux media subsystem, and I have served on the kernel technical advisory board.

Like so many people in open source, I believe in sharing my knowledge and expertise. Mentoring developers is an important aspect of being a maintainer and a good citizen of open source. It is vital for any community to spend time and energy to bring in new talent and grow the next generation of leaders for its continued success.

I found the Linux kernel community to be a very welcoming place to people of diverse backgrounds such as myself. I have had great mentors who took time to help me find my place in the community and make it my home. I am looking forward to sharing my experiences with the community to help newcomers overcome their apprehensions, if any, and help them find a place and feel at home in this community.

Since joining the Linux Foundation, I have been working to build out a new mentoring initiative. Today I am excited to announce our new Linux Kernel Mentorship Program on CommunityBridge, a platform that will bring opportunities for new developers to join and learn from our community and improve it at the same time.

CommunityBridge is a place where kernel mentors can sign up to share their expertise and pair them with anyone who has the basic skills to apply to work and learn from our community as selected mentees. CommunityBridge will give individuals the opportunity to get paid $5500 plus a $500 travel stipend for a 12-week program to learn from us and solve problems such as finding and fixing bugs that will make the kernel more stable and secure.   At the end of the program, mentees will also be paired with CommunityBridge employers for opportunities to interview with some of the top names in tech.

What’s more, in order to improve diversity in our community, the Linux Foundation will provide full financial sponsorship for the first 5 mentees from diverse backgrounds in the upcoming summer session starting this April. Even more, the Linux Foundation will match dollar for dollar for donations to support the first 100 diverse mentees across all projects hosted on the CommunityBridge platform.

In short, we can improve kernel code, bring new people into our community, and find job opportunities for aspiring developers from diverse backgrounds; all at the same time on CommunityBridge.

I would like to invite mentees to start your open source journey with experts as guides and mentors by applying for the program on CommunityBridge today.  I urge community partners to donate to the Linux Kernel Mentorship project early to secure the LF matching grants for the Linux Kernel project.

Please  join me in this exciting endeavor to make the Linux Kernel strong, diverse, and secure.  And for important open source projects beyond the kernel, I encourage you to take advantage of CommunityBridge to improve your communities as well.

/by

Diversity Empowerment Summit Highlights Importance of Allies

, ,

allies for inclusion

Diversity Empowerment Summit provides insights, ideas, and examples to help open source projects and professionals adopt inclusive practices.

Diversity and inclusion are hot topics as projects compete to attract more talent to power development efforts now as well as build their ranks to carry the projects into the future. The Diversity Empowerment Summit co-located with Open Source Summit coming up in Vancouver August 29-31, will offer key insights to help your project succeed in these endeavors.

Although adoption of diversity and inclusion policies is generally seen as simply the right thing to do, finding good paths to building and implementing such policies within existing community cultures continues to be challenging. The Diversity Empowerment Summit, however, provides hard insights, new ideas, and proven examples to help open source professionals navigate this journey.

Nithya Ruff, Senior Director, Open Source Practice at Comcast

Nithya Ruff,  Senior Director, Open Source Practice at Comcast, and member of the Board of Directors for The Linux Foundation, says “the mission of open source communities to attract and retain diverse contributors with unique talent and perspectives has gathered momentum, but we cannot tackle these issues without the support of allies and advocates.” Ruff will be moderating a panel discussion at the conference examining the role of allies in diversity and inclusion and exploring solid strategies for success.

Along with Erik Riedel of Dell EMC, Ruff will also present “Everyday Opportunities for Inclusion & Collaboration.” In this talk, the speakers will share specific examples and stories illustrating some less obvious opportunities for communication, networking, mentoring, and collaboration encountered in  on-the-job activities as well as at events and forums.

We talked with Ruff about the importance of the Diversity Empowerment Summit as well as some of the upcoming  highlights.

The Linux Foundation: Why is the Diversity Empowerment Summit important?

Nithya Ruff: A big part of open source is the developers who feel included and valued as human beings. And the Diversity Empowerment Summit helps us celebrate and discuss how we can continue to create inviting, inclusive and healthy communities. This conference welcomes talks on growing our community to practices for inclusion to being allies to people who are under-represented in our communities.  It is great to see The Linux Foundation make valuable space and time for this track every year.

The Linux Foundation: Who should attend?

Ruff: Everyone who cares about the health of the community should attend.  Projects are successful because of the people behind it and if you are interested in creating a sustainable project, you should attend these sessions.

The Linux Foundation: What are you looking forward to at the Summit?

Ruff: This year, I am excited about the panel on building allies as it brings some great speakers in one session to the audience. I’m looking forward to truly great speakers like our keynote speaker, Jennifer Cloer, and others like Tameika Reed, Deb Nicholson, Chloe Condon, Lucy Wyman, and Guy Martin.

There are also many terrific talks about welcoming and helping new contributors to open source, which is critical considering women comprise less than 10 percent of open source community members and many underrepresented communities account for less than 5 percent of open source community members.

Check out the complete schedule and register now to attend the Diversity Empowerment Summit at Open Source Summit in Vancouver.

Sign up to receive updates on Open Source Summit:

/by