Last Updated: March 21, 2025
Lightweight governance guidelines for National Instruments (NI) open source projects – This document outlines how NI’s open source projects are managed in a transparent, collaborative way. It is intended for both external contributors and NI internal maintainers across all NI open source repositories (not just LabVIEW-related projects). These bylaws are not formal legal rules, but rather a common understanding to help our community work together effectively.
These bylaws apply to all open source projects under the NI GitHub organization. They provide a framework for how decisions are made, how contributors interact, and how leadership roles function across projects. Every NI open source repository (for example, the LabVIEW Icon Editor and others) should follow these guidelines, ensuring consistency and fairness in how we collaborate.
The purpose of this document is to make governance clear and accessible. It describes who is responsible for what (from NI Open Source Program Managers to volunteer contributors) and how we work together. By keeping our governance lightweight and transparent, we encourage broad participation and smooth project operations. Everyone – NI employees, community members, and users – should feel empowered to contribute and understand how decisions are made.
Our open source community includes various roles, each with specific responsibilities. We emphasize clarity in these roles so that everyone knows how to participate and who to turn to for guidance or decisions. NI Open Source Program Managers and the Steering Committee have special leadership duties, while Maintainers and Contributors handle the day-to-day development and collaboration.
NI Open Source Program Managers (OSPMs) are NI employees who oversee the health and process of NI’s open source initiatives. They act as coordinators and facilitators rather than traditional “bosses.” Their responsibilities include:
Overall, NI Open Source Program Managers are champions of open source culture within NI. They bridge internal NI teams and the external community, making sure contributors have a positive experience. They also handle any internal NI requirements (such as legal compliance or contributor license agreements) behind the scenes so that contributors can focus on what they do best.
The Steering Committee is a group of experienced project leaders (both NI staff and, optionally, community experts) who guide the technical direction and governance of NI open source projects. This committee works as a team to make collaborative decisions for the benefit of the projects and community. Key aspects of the Steering Committee’s role:
The Steering Committee is essentially the “brain trust” of NI’s open source efforts. However, it operates openly: discussions and decisions should be visible to the community (through meeting notes, GitHub issues, or other public forums). This transparency helps build trust. The committee does not control day-to-day development – that’s up to maintainers and contributors – but it provides guidance and oversight to keep projects on track with their objectives.
Project Maintainers are the people with direct responsibility for the upkeep of a specific repository. Maintainers can be NI employees or community members (or both). They have write access to the repository (i.e., they can merge pull requests) and are expected to drive the project forward. Responsibilities of maintainers include:
ROADMAP.md, or simply via milestones in the issue tracker) so that contributors know where the project is heading.Contributors include anyone in the community who contributes to the project in any form – this could be code, documentation, design suggestions, or answering questions. Contributors do not have commit rights to the repository (unless they later become maintainers), but their role is vital. Responsibilities and expectations for contributors:
Contributors who show dedication, good judgment, and quality work may be considered for elevation to Maintainer status over time.
In this section we outline how decisions are made and documented.
For day-to-day changes (like fixing bugs, adding minor features, refactoring code), project maintainers can make decisions and accept pull requests following the normal review process. Maintainers should use their best judgment and consult others when a change could be contentious.
For larger technical decisions (e.g., adopting a new major dependency, significant architecture changes, or any change that could impact multiple projects), the Steering Committee should be consulted. Often, these decisions will be discussed in an issue or a discussion thread. The goal is to reach consensus among active maintainers and, when needed, Steering Committee members. If consensus cannot be reached on a major decision, the Steering Committee will vote or otherwise decide as described under Decision Authority above.
All decisions (even if made in meetings or privately) that affect the project should be documented openly – typically via the issue tracker or in meeting notes posted to the repository. This ensures transparency.
New project proposals (for entirely new open source tools or libraries under NI) go through the Steering Committee. The proposal should outline the project’s scope, goals, and how it fits into the broader NI open source ecosystem. The Steering Committee will discuss and either approve the creation of a new repository or provide feedback. Once approved, the new repository should adopt these governance guidelines from the start.
If a community member wants to donate or contribute an existing project to the NI organization, this is also discussed and decided by the Steering Committee, with input from NI’s Open Source Program Managers to ensure licensing and CLA compliance.
Most technical collaboration happens in the open – via GitHub issues, pull requests, and discussion forums. However, the maintainers and Steering Committee may hold periodic meetings (for example, a monthly sync-up call or an annual roadmap planning meeting). If meetings occur:
Day-to-day communication: We use GitHub for most discussions. Some quick questions might be discussed in chat (e.g., Discord), but any decision or important context from chat should be captured in an issue or discussion post so it’s searchable and archived.
Our contribution process is designed to be as simple as possible while ensuring quality and coordination:
develop branch (or appropriate branch as per project workflow).develop will be included in the next release. At release time, maintainers merge develop into main (after bumping version numbers, etc.), and create a tagged release.Contributors should ensure they sign the CLA (if external) and sign off their commits (DCO) as described in CONTRIBUTING.md. All code contributions are assumed to be under the project’s license (MIT, unless otherwise specified).
For significant changes, as noted, discuss in an issue or forum first. This helps align contributions with project roadmap and avoids duplicate efforts.
All participants in the project must adhere to the project’s Code of Conduct. This is essential to maintaining a healthy, welcoming community. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the project maintainers or NI’s Open Source Program Managers.
Enforcement of the code of conduct will be a joint effort between the Steering Committee and the OSPMs. Consequences for violations may include a warning, temporary ban, or in severe cases, permanent removal from the community, depending on the offense and in accordance with the Code of Conduct’s escalation process.
These governance guidelines can evolve as the project grows. Amendments can be proposed by opening an issue or pull request against this GOVERNANCE.md file. The Steering Committee will review proposed changes, and after discussion (and community input), decide whether to adopt them. We aim to keep governance lightweight, so changes will be made cautiously and with consensus.
Any update to this document will be notated with the date of change and a summary of what was changed, to maintain a revision history.