Issue: New .NET Foundation Project Application

[Molth]

Project Name

NativeCollections

License

MIT

Contributor

Molth

Existing OSS Project?

Yes

Source Code URL

https://github.com/Molth/NativeCollections

Project Homepage URL

No response

Project Transfer Signatories

• Molth Nevin molth_nevin@163.com

Description

A high-performance, GC-free collection library built on unmanaged memory, designed for game engines and other performance-critical .NET applications that require low overhead and full control over memory behavior — with zero external dependencies.

What are you hoping from the foundation

I hope to leverage the .NET Foundation's marketing and community platforms to increase the visibility of NativeCollections and connect with a broader audience of .NET developers. As a library focused on high‑performance, GC‑free collections built on unmanaged memory, my target users are often those working on game engines, real‑time systems, or other performance‑critical applications – a relatively vertical niche. The Foundation’s ecosystem, including its blog, social channels, and official project listing, can help me reach developers who are actively seeking such specialized tools. I believe that greater exposure will not only grow my user base but also attract more contributors, enabling the project to evolve faster and become a more robust solution for the .NET community.

Name

Molth Nevin

Email

molth_nevin@163.com

GitHub Profile URL

https://github.com/Molth

Committers

• Molth Nevin molth_nevin@163.com

Discord Ids

• Molth Nevin molth_nevin@163.com

Governance Model

NativeCollections follows a lightweight governance model centered around a single maintainer (Molth Nevin), with an open contribution process for community involvement.

Code Change Process

1. Proposal: All code changes are proposed via GitHub Issues. Bug fixes, performance improvements, and new features are discussed openly in the issue tracker before implementation begins.

2. Implementation: Contributors fork the repository, create a feature branch, and submit a Pull Request (PR) referencing the relevant Issue.

3. Review: Each PR is reviewed by the maintainer. The review focuses on:

   • Correctness and thread-safety of unsafe/unmanaged operations
   • Performance implications (no unnecessary allocations, minimal overhead)
   • API consistency with existing collection types
   • Test coverage and documentation

4. Decision: The maintainer makes the final decision to accept, request changes, or reject a PR. Decisions are communicated clearly in the PR comments.

New Committer Appointment

As the project currently has a single maintainer, new committers will be identified based on their sustained contribution quality and engagement with the project. Candidates who demonstrate:

• Consistent delivery of high-quality, well-tested PRs
• Active participation in issue discussions and code reviews
• Deep understanding of the library's architecture and unmanaged memory safety

will be invited to become committers. This process ensures that commit access is granted only to individuals who have earned trust through demonstrated technical competence and community involvement. The decision to appoint a new committer is made by the existing maintainer, with consideration of the candidate's contribution history.

CLA

• If already an OSS project, was a Contribution License Agreement in place for contributions accepted?

How does the project check who has signed one?

• Automated check on every PR

CLA Notification Alias

molth_nevin@163.com

Select the Project Transfer Agreement model

Assignment

Repository Layout

No response

Eligibility Criteria

• The project is built on the .NET platform and/or creates value within the .NET ecosystem.
• The project produces source code for distribution to the public at no charge.
• The project's code is easily discoverable and publicly accessible (preferably on GitHub).
• 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).
• When applicable, project must use reproducible build settings in its toolchain.
• The project uses Source Link.
• The project uses either embedded PDBs or publish symbol packages to NuGet (if applicable).
• The project code signs their artifacts as appropriate.
• The project organization has 2FA enabled. Requiring 2FA must be done as part of onboarding if not already enabled.
• 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).
• 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.
• The copyright ownership of everything that the project produces is clearly defined and documented.
• The project has a public issue tracker where the status of any defect can be easily obtained.
• The project has a published Security Policy.
• The project has a home page which provides high level information about its status and purpose.
• The project has a public communication channel where community members can engage with maintainers.
• The project has a publicly available location where members can review and contribute to documentation.

Describe why you are applying for Project Membership.

I am applying for Project Membership in the .NET Foundation to gain access to the resources, support, and community that will help NativeCollections grow into a widely adopted and professionally managed open source project.

Specifically, I hope to benefit from:

• Project guidance and mentoring: The Foundation offers mentorship on how to best run an open source community. As a solo maintainer, I would greatly value guidance on community building, contribution workflows, and sustainable project governance.

• IP and legal support: Legal matters can be challenging for individual maintainers. The Foundation's assistance with IP assignments and Contributor License Agreement (CLA) management would streamline the contribution process as the project grows.

• Marketing and community exposure: The Foundation works with industry leaders to improve project visibility within the .NET community. As a library focused on a specialized niche (high-performance, GC‑free collections on unmanaged memory), reaching the right audience is critical. Foundation membership would help connect NativeCollections with developers actively seeking such tools.

• Technical services: Access to Authenticode code‑signing for NuGet packages, secure secret storage, and hosting resources would reduce administrative overhead and improve the project's professionalism and security.

• Influencing the .NET ecosystem: Membership provides a voice in shaping the Foundation's support for open source projects. I am passionate about the .NET platform and want to contribute to its growth beyond just my own project.

Infrastructure Requirements Summary

NativeCollections is a library project with minimal infrastructure requirements. Below is a summary of my needs:

Build Servers

I currently use GitHub Actions for continuous integration and build automation. This setup is sufficient for the project's needs, and I plan to continue using it after joining the Foundation. No additional build server infrastructure is required.

Web Hosting / Service Hosting

The project does not require any web hosting or service hosting. It is a pure library with no website, API, or online service components.

SSL Certificates

No SSL certificates are required, as the project has no web-facing services.

Authenticode Code Signing

Yes, this is a primary need. I would like to utilize the .NET Foundation's Automated Authenticode Code Signing service for NuGet package releases. This will:

• Allow users to install the package without SmartScreen warnings
• Provide assurance that the binary is the one produced by the build server
• Enhance the project's professionalism and security posture

Other Infrastructure Needs

• Secret Management: Access to the Foundation's secure vault for storing NuGet API keys and other credentials would be helpful
• CLA Automation: The Foundation's automated CLA system would streamline the contribution process

Summary

Beyond code signing and basic secret management, NativeCollections has no complex infrastructure requirements. The existing GitHub Actions-based build pipeline will remain the primary CI/CD system.

Additional Notes

Comparison with similar projects

• UnsafeCollections / XenoAtom.Collections: These libraries provide struct‑based collections backed by managed arrays (or fixed‑size buffers for stack allocation). While they reduce GC pressure, they still rely on managed memory and can incur GC overhead on resizing. NativeCollections uses unmanaged memory exclusively, providing complete control over memory lifetime and zero GC interaction.

• NullGC.Collections: This project also targets unmanaged memory and offers a similar feature set. However, it bundles a custom unmanaged memory allocator, LINQ provider, and source generator, making it a heavier dependency. NativeCollections focuses solely on collection types with no external dependencies, keeping the library lightweight and easy to integrate into any .NET project.

• ZeroAlloc.Collections: This library uses ArrayPool<T> and ref struct types to reduce allocations, but its collections are stack‑only (ref struct) and cannot be stored in fields or used across async boundaries. NativeCollections provides heap‑allocated containers (via Unsafe* types) that can be stored in fields, passed between methods, and used in long‑lived scenarios, while still maintaining zero GC pressure.

• Unity NativeCollections: Unity's NativeCollections is tightly coupled with the Unity ecosystem, requiring the Unity.Collections package and DOTS/Burst compatibility. NativeCollections is a pure .NET library with zero dependencies on Unity or any game engine, making it suitable for any .NET application — including server‑side, game development, and real‑time systems.

Potential issues early on

• Documentation: As a solo maintainer, creating comprehensive documentation and API reference is time‑consuming. Guidance on structuring documentation and generating API docs would be appreciated.

• Community building: Growing a contributor base from scratch is challenging. Mentorship on community engagement and contribution workflows would be valuable.

• Branding: The project name NativeCollections overlaps with Unity's NativeCollections and a few other NuGet packages. I may need guidance on rebranding or clarifying the distinction to avoid confusion.