Making Desktop Frameworks More Accessible with Electron | Episode 4 | The GitHub Podcast

Key Concepts

• Electron: A framework for building cross-platform desktop applications using web technologies (JavaScript, HTML, CSS).
• Electron Forge: A module within Electron that handles packaging and creating installers for applications.
• Interprocess Communication (IPC): A mechanism for different processes within an application to communicate with each other.
• Maintainer: An individual responsible for the ongoing development, maintenance, and community management of an open-source project.
• Google Summer of Code (GSoC): A global program that offers stipends to students who contribute to open-source projects.
• Runbooks: Pre-defined sets of instructions or responses for common tasks or issues.
• AI-generated spam: Content, such as project proposals or issues, created by artificial intelligence and submitted to open-source projects, often without genuine intent or effort.
• Critical Thinking: The ability to analyze information objectively and make a reasoned judgment, identified as a key skill for the future by the World Economic Forum.

Introduction to Electron and Key's Role

The GitHub podcast features Abby and Cadesha interviewing Keely, a core maintainer for the Electron project. Keely has been involved with Electron since 2019 and is also part of the Electron desktop team at Slack. Her journey into maintaining Electron began at her first engineering job at Invision, where she proactively sought to specialize in Electron due to the team's lack of expertise. She reached out to the then-manager of Electron and found the community to be very welcoming to new contributors.

What is Electron?

Electron is described as a framework that allows developers to build cross-platform desktop applications using web technologies. This means an application built with Electron can run on macOS, Windows, and Linux, using JavaScript, HTML, and CSS, similar to web development. A key component of the Electron ecosystem is Electron Forge, which simplifies the process of packaging applications and creating installers. Keely draws a parallel between Electron and frameworks like React Native or Flutter, but specifically for desktop applications.

Prominent Electron Users

Electron is utilized by many well-known companies and projects, including:

• Slack
• Discord
• OnePassword
• Anthropic
• OpenAI
• Cursor (an AI company)

Building a Welcoming Open Source Community

Keely highlights the welcoming nature of the Electron community, which was instrumental in her own onboarding. Despite being new to Electron-specific concepts like Interprocess Communication (IPC), she received quick and supportive responses from existing maintainers. This responsiveness and friendliness are actively maintained by the current team through prompt handling of issues and pull requests in the issue tracker, providing actionable feedback.

The intentionality behind this welcoming culture is attributed to both the initial founders and ongoing efforts as the project grows. A specific example is Electron's participation in Google Summer of Code (GSoC). For GSoC, the Electron team proactively establishes clear behavioral guidelines for mentors, develops runbooks with pre-written responses to common questions, and sets up workflows to centralize communications, ensuring timely responses to student inquiries. This systematic approach helps manage the high volume of incoming work and fosters a positive environment.

Misconceptions About Electron

A common misconception about Electron is that applications built with it are inherently more bloated and slower than native applications. Keely acknowledges that there are "foot guns" that can lead to this outcome if not managed carefully, but argues it's not an inherent characteristic. She points out that many native applications also consume significant resources, while some Electron apps are quite efficient. The performance often depends on the quality of the JavaScript code itself, rather than the framework.

Electron also prioritizes security, maintaining three active release lines and a beta line. A dedicated individual works full-time on "Chrome rolling," which involves backporting security patches from Chromium to Electron.

Maintainer Structure and Volunteer Engagement

The Electron project has a robust maintainer base. The Slack Electron team consists of five full-time members, and there is a Microsoft Electron team with approximately four full-time engineers and a manager. While these individuals have other responsibilities, they dedicate at least part-time to Electron. Additionally, there are 10-12 volunteer maintainers who are not paid to work on the project full-time.

To ensure volunteer maintainers feel valued and integrated, Electron employs a governance structure with seven working groups (e.g., security, releases, upgrades, API). This distribution of work allows maintainers to specialize. Many volunteers are former app developers who identified and addressed needs within the Electron ecosystem, particularly in areas like packagers and installers. The project also seeks funding through OpenJS to cover expenses like travel for maintainer summits, reducing the financial burden on volunteers.

Managing Contributors at Scale

Managing a large number of contributors is an ongoing effort. Electron actively monitors its issue tracker and pull requests. A weekly releases working group reviews these to ensure timely responses and prevent stagnation. While acknowledging room for improvement, the project aims to provide quick feedback to contributors.

GitHub's improvements to the issue tracker, including a labeling system with canned responses, have been instrumental. For instance, automated responses can request missing information or a minimum reproducible example from issue filers, freeing up maintainer time for actual debugging. These automated responses and labeling systems are visible in the Electron repository's issue tracker.

For GSoC interactions, a Notion playbook with pre-written responses is used, as most communication occurs via email.

Open Source Lessons Learned

Keely shares a key lesson for open-source maintainers: the importance of investing in automation and systems to manage the overwhelming volume of work. This includes developing automation for repetitive tasks, creating runbooks for common responses (like PRs and emails), and utilizing issue tracker features. By offloading manual and frustrating work, maintainers can preserve their mental capacity and emotional energy for more complex problem-solving and community interaction.

The Rise of AI and Spam in Open Source

A significant change Keely has observed in the last couple of years is a substantial increase in AI-generated spam. This is particularly evident in GSoC proposals, where a large portion can be AI-generated, adding noise and making it harder to identify genuine, thoughtful submissions. This poses a challenge because over-correction could inadvertently filter out legitimate contributors, especially beginners.

The discussion touches on the potential for AI to be used constructively, such as by non-native English speakers to improve communication. However, the focus remains on developing effective spam filters without hindering genuine contributions.

AI as a Teaching Moment and Critical Thinking

The conversation shifts to how to handle AI-generated content. Kadesha suggests framing interactions with AI-generated submissions as teaching moments, encouraging contributors to demonstrate critical thinking and genuine understanding of the technical problem. This involves guiding them to ensure they have put thought into their submissions beyond simply using AI.

Keely echoes this, emphasizing that open-source contributions require understanding the core technical problem, not just generating an essay. She highlights that the World Economic Forum's 2025 job report identifies critical thinking, resilience, and creativity as top skills, underscoring the importance of human cognitive abilities. Developers should validate and understand any code generated by AI to maintain their own skills.

Best Practices for Contributors

A crucial best practice for contributors is to be able to stand behind the code they submit. While not every contributor is expected to be an expert in every aspect of a complex codebase like Electron, they should understand the code they are submitting and be able to validate it. Acknowledging areas of uncertainty in a pull request is acceptable and part of the collaborative open-source process. However, submitting code without understanding it is problematic for both the contributor and the project.

Final Thoughts and Call to Action

Keely encourages anyone interested in developing with Electron or contributing to the project to reach out. Her GitHub handle is FertBend. Electron is actively seeking new contributors and maintainers.

Abby and Cadesha conclude by reflecting on the insightful conversation, particularly appreciating Electron's intentionality in building a welcoming culture for both maintainers and contributors, and its unique blend of community focus with corporate sponsorship. They reiterate that the GitHub podcast is dedicated to the open-source developer community on GitHub.