Skip to content

Energy IoT Open Source Policy

Jump to bottom
AXM Software edited this page Mar 29, 2024 · 2 revisions

Source Code Repositories

Use the public GitHub organization https://github.com/energy-iot/ to manage top-level repositories for this project.

Use repositories for each runtime dependency open source code. Prefix runtime-only with docker-

Use separate repositories for source code forks

Use separate repositories for net new source code

Energy IoT Open Source requires signed contributions

We will use Developer Certificate of Origin (DCO).

Contributors should use the git commit -s option, each commit will have a message embedded such as: Signed-off-by: Some Developer <some-developer@example.com> Enable DCO enforcement on Github repos

Procedures for Open Source Licenses

  • Follow the dependency license for any fork contributions
  • For net new code, use Apache 2.0
  • Add GitHub Action to select Apache 2.0 for each new repo in the energyiot org unless it is a fork of an existing OSS project.
  • We will use Apache 2.0 license when using docker/binaries from non Apache 2.0 OSS to create new turn-key deployments.

Training

Community participation and outreach

  • Contribution Monitor - Aidan Barnes, Bello Afeez. Each monitor acts as an admin for one or more repositories in the Github energy-iot organization.
  • Outbound Marketing & Communications - Arila Barnes, Robert Carlson. Leverage Github Wiki/Project and Energy IoT Open Source website
  • Procurement - handled by the Program Office
  • Legal - handled by the Program Office

Mentorship and Monitoring

Keep discussions in the open.

  • Make sure reviews and rejections are based on issues and have clear explanations.
  • Avoid abusive, even toxic tones in discussions, even between senior members who know each other well and may not take offense, possibly due to cultural factors.
  • If you are a maintainer, don’t just exert control over submissions because you can. Lead by explaining the logic of decisions, by suggesting what would be a more acceptable change set, and encouraging others to contribute their views
  • One should not respond in kind and accelerate the conflict. Within a given project there is probably an explicit code of conduct and senior maintainers, which set the framework for dealing with such uncomfortable matters.

OSS Code Contributions

Why does this project exist and why was it started?

This project was started as an effort to broaden the adoption of OpenEMS and democratize energy infrastructure for microgrid applications. The project exists and is committed to pioneering the development of cutting-edge Energy IoT solutions whereby it is designed to empower people across diverse sectors, including both the public and private domains and 3rd world countries. The primary goal is to not merely adapt to the ever-changing technology landscape but to actively shape it and provide viable energy solutions for everyone around the globe.

Does it have a collective or singular governance structure?

Energy IoT Open Source non-profit governs contributions to this project. Thus the governing body is made up of the non-profit board members acting as a decision body. Current steering committee members are AXM Software LLC and Kaleidoscope Inc.

What does working code mean?

Based on best practices identified by the Continuous Delivery Foundation: Your code should be locally tested before submitting a pull request.
Make a best effort to address any critical and high vulnerabilities prior to submitting a pull request. Credit dependency projects and track versions used. Document your work so fellow volunteers and developers can use it effectively. All unit tests and deployments should be automated via GitHub actions and Infrastructure as Code (i.e. Terraform) Generate a Software BIll of Material see https://github.com/david-a-wheeler/spdx-tutorial?tab=readme-ov-file

Maintainers Work Flows and Methods

Process and timelines for PR reviews:

  1. For new code, create a feature branch dev-<feature>.
  2. Submit a pull request(PR).
  3. One of the maintainers will merge the PR when all checks have passed successfully and reviewer comments have been addressed.

We reserve the right to use Gerrit as a strategy for code contributions in the future as our community grows.

Continuous Integration = CI + CDelivery + CDeployment

How we build the code, test the code, deploy via Terraform, and run on AWS. Please use a feature branch for any new work. GitHub Actions are leveraged to validate code on each pull request prior to merging. In addition, all docker containers published for AWS ECR will be periodically scanned for vulnerabilities as well. See also https://github.com/opensbom-generator/spdx-sbom-generator.

Clone this wiki locally