Application from .NET nanoFramework

josesimoes commented 4 years ago

1. General Information

Project Name: .NET nanoFramework

License: Apache 2.0 & MIT

Contributor (Company, Organization or individual name(s)): @josesimoes @AdrianSoundy @networkfusion @piwi1263 @eclo

Existing OSS Project? Yes:

Source Code URL: https://github.com/nanoframework

Project Homepage URL (if different): https://www.nanoframework.net

Project Transfer Signatories: Submitted via e-mail to contact@dotnetfoundation.org

2. Description

.NET nanoFramework is a free and open-source platform that enables the writing of managed code applications for constrained embedded devices. It is suitable for many types of projects including IoT sensors, wearables, academic proof of concept, robotics, hobbyist/makers creations or even complex industrial equipment. It makes the development for such platforms easier, faster and less costly by giving embedded developers access to modern technologies and tools used by desktop application developers.

Developers can harness the powerful and familiar Microsoft Visual Studio IDE and their .NET C# knowledge to quickly write code without having to worry about the low-level hardware intricacies of a microcontroller. Desktop .NET developers will feel “at home” and are able to use their skills in embedded systems development, enlarging the pool of qualified embedded developers.

Summary Making it easy to write C# code for embedded systems.

3. Project Governance

The project will keep following the existing organization with a core team overseeing the project, contributions and community support.

Project Lead: Name: José Simões Email: jose.simoes@eclo.solutions
GitHub Profile URL: @josesimoes

Committers:

This project is organized in several repos, all under GitHub nanoFramework organization. We had (have) several committers since the time the project started. Follows a list of the ones responsible for most of the commits on the majority of the repos. @josesimoes @AdrianSoundy @networkfusion @piwi1263

Governance Model:

Code changes arrive to the project trough 2 channels: 1. issues on GitHub with bug reports or new features proposal or 2. conversations on our Discord channels that end up on suggestions/hints/thoughts for new features/improvements.

For the most obvious ones, there is usually no discussion about it, they are picked up from the issues or cards in the various projects of the project and implemented. The ones less consensual or that have higher/broader impact are discussed in the appropriate Discord channel or by the core team.

We have an ongoing policy towards community participation and we are constantly encouraging new contributors and asking for new developers to join the core team. The latter usually follows a conversation on Discord about a question they have or new feature suggestion after which they are encouraged to pursue and submit a PR with the implementation. Or after a "cold" PR with a new feature or a fix for a bug.

CLA

We have a [CLA]() in place since we went public. The signing and check is automatic and handled by CLA assistant and it's part of the PR checks on each repository.

CLA Notification Alias Provide an email address that will receive CLA related notifications from the .NET Foundation CLA automation nanoframework@outlook.com

Project Transfer Type

[ ] Assigment
[X] Contribution

4. Repository Layout

Due to the nature of the project we have it organized in several repositories. Follows a summary on the repository organization:

nf-interpreter: this repo contains the .NET nanoFramework CLR, interpreter, target boards configuration and the respective build system. This is where everything required to build an image to be flashed into a device lives.
nf-Visual-Studio-extension: this repo contains the Visual Studio extension and all the associated tools required to compile and build a .NET nanoFramework managed application ready to deploy to a target device.
nf-debugger: this repo contains the debugger library (in several technologies) allowing reuse of the lower layer library by third party applications.
metadata-processor: this repo contains the Meta Data Processor that is used when building C# nanoFramework applications. Its main function it’s to parse the outputs from Roslyn and build lightweight PE files that are loaded into the target devices.
nanoFirmwareFlasher: this repo contains the nanoFramework Firmware Flasher that is used to update the firmware on nanoFramework target devices. Along with other flash utilities that are useful in production and on the daily use.
nf-tools: this repo contains various tools that are required for nanoFramework development, usage, or repository management.
Repositories for the Base Class Library (mscorlib) and the various Class Libraries.
nf-Community-Targets: this repo contains target boards that are contributed by community members.
nf-Community-Contributions: this repo contains contributions from community members. Drivers, extensions, utilities, feature demos, etc.
Samples: this repo contains sample applications illustrating nanoFramework APIs and common use cases.
nanoframework.github.io: this repo contains the sources and configuration files to generate the .NET nanoFramework documentation web site. Any static content, such as articles, guides, how-to's and similar is to be checked-in here.

The internal organization on each repo follows this basic principle: “develop” branch for the active ongoing work and where PRs are submitted against; “master” branch for stable releases; other branches for long running PRs, experimental features and such.

On the repos where that makes sense, we have a CD-CI in place using Azure Pipelines. Build, CLA, code style and code quality checks are performed.

The contribution process (and checks) are the same for the core team and external contributors.

At this time, we don’t anticipate that any changes are necessary as part of the process of joining the .NET Foundation. Of course, we are open to make them, if necessary.

Something worth considering as part of the onboarding process it's the move (or not) of the repositories to the dotnet GitHub organization. The project is comprised of a bunch of repositories that are, at several levels, interconnected. Moving them will negatively impact the consistency of the project and their interconnection. Not to mention that it will "get lost" and make it harder to find among all the ones already there. A "placeholder" repository pointing it to the project organization will probably be the best approach for this.

5. Eligibility Criteria

Please complete the following for your project

The project is built on the .NET platform and/or creates value within the .NET ecosystem.
[x] Yes
[ ] No
The project produces source code for distribution to the public at no charge.
[x] Yes
[ ] No
The project's code is easily discoverable and publicly accessible (preferably on GitHub).
[x] Yes
[ ] No
The project contains a build script that can produce deployable artifacts that are identical to the official deployable artifacts, with the exception of code signing (Exception may be granted for strong name keys, though strongly encouraged to be committed. Exception relies on OSS signing being in the build script for public builds).
[x] Yes
[ ] No
When applicable, project must use reproducible build settings in its toolchain.
[x] Yes
[ ] No
The project uses Source Link.
[x] Yes
[ ] No
The project uses either embedded PDBs or publish symbol packages to NuGet (if applicable).
[x] Yes
[ ] No
The project code signs their artifacts as appropriate.
[ ] Yes
[ ] No
Libraries that are mandatory dependencies of the project are offered under a standard, permissive open source license which has been approved by the .NET Foundation (exceptions include a dependency that is required by the target platform where no alternative open source dependency is available such as the .NET Framework or a hardware specific library).
[x] Yes
[ ] No
Committers are bound by a Contributor License Agreement (CLA) and/or are willing to embrace the .NET Foundation's CLA when the project becomes a Member.
[x] Yes
[ ] No
The copyright ownership of everything that the project produces is clearly defined and documented.
[x] Yes
[ ] No
The project has a public issue tracker where the status of any defect can be easily obtained.
[x] Yes
[ ] No
The project has a published Security Policy.
[x] Yes
[ ] No
The project has a home page which provides high level information about its status and purpose.
[x] Yes
[ ] No
The project has a public communication channel where community members can engage with maintainers.
[x] Yes
[ ] No
The project has a publicly available location where members can review and contribute to documentation.
[x] Yes
[ ] No

6. PR Plan

The plan is to shout out the milestone of joining the foundation and take advantage on the “noise” generated by the event. Posts on official blog, Twitter, Linked In, Hackster.IO along with press release to major electronic and embedded systems newsletters/publications. For this last part we see the foundation as a key part of bringing “weight” to the announcement in order to make more interesting/relevant to those channels.

The narrative should be along the lines of the project mission statement: “Making it easy to write C# code for embedded systems.” The .NET framework brings together several key aspects:

Use of the modern, powerful, easy to learn and use C# language.
The awesomeness of developer experience that Visual Studio provides, from coding to a true debugging on real hardware without requirement of expensive/complicated hardware.
The abstraction of the complexity of micro controllers and the lower layers of embedded systems, making it possible for a desktop .NET developer to easily find it’s way around the framework, with a smooth learning curve leading to achieving a productive stage on a very short time.
An open source platform suitable for many types of projects like IoT sensors, wearables, academic proof of concept, robotics, hobbyist/makers creations and complex industrial equipment.

Because of all the above this framework, with the right promotion and industry/community adoption, can easily become the next Arduino.

7. Infrastructure Requirements

We are currently relying on Azure Pipelines for all our build needs, which is perfectly satisfactory for the current needs of the project. For artifacts distribution we are using a mix of NuGet.org, Bintray and Azure Pipelines feeds.