[Application] Fastdotnet - Enterprise Modular Framework with True Plugin Hot-Swapping #525

Project Name

Fastdotnet

License

MIT

Contributor

ChengGui Yang

Existing OSS Project?

Yes

Source Code URL

https://github.com/CN-GodHei/fastdotnet

Project Homepage URL

No response

Project Transfer Signatories

GodHei [email protected]

Description

Enterprise modular framework with true plugin hot-swapping, micro-frontend integration, and marketplace ecosystem for rapid SaaS development.

What are you hoping from the foundation

We hope to gain credibility and visibility within the global .NET community, access to foundation resources for project governance and best practices, collaboration opportunities with other .NET projects, and support for long-term sustainability. Joining will help us establish Fastdotnet as a trusted enterprise framework and accelerate ecosystem growth through community engagement and technical guidance from the foundation.

Name

ChengGui Yang

Email

[email protected]

GitHub Profile URL

https://github.com/CN-GodHei

Committers

Currently, there is only one committer:

• GitHub ID: CN-GodHei
• Name: ChengGui Yang
• Employer: Independent contributor / Self-employed
• Role: Project Founder and Lead Maintainer

As the sole maintainer, I have full commit/write access to all repositories. We plan to expand the committer team as the project grows and more contributors join the community.

Discord Ids

Committers

Currently, Fastdotnet has one committer with full write access:

GitHub ID	Discord ID	Name	Employer	Role
CN-GodHei	godhei_96747	ChengGuiYang	Independent contributor	Project Founder and Lead Maintainer

Responsibilities:

• Core architecture design and development
• Plugin system implementation
• Code review and quality assurance
• Release management
• Community engagement and support
• Documentation maintenance

Future Plans:
As the sole maintainer, I hold full commit/write access to all Fastdotnet repositories. The project welcomes contributions from the community, and we plan to establish a formal committer team with clear governance policies as the project matures and more active contributors emerge.

Committer expansion will follow transparent criteria based on contribution quality, consistency, and alignment with project goals.

Governance Model

Current Governance Model (Single Maintainer)

As Fastdotnet is currently maintained by a single founder (CN-GodHei), the governance process is streamlined:

1. Proposal: Code changes are proposed via GitHub Issues or Pull Requests (PRs). Community members and users are encouraged to report bugs, suggest features, or submit PRs directly.
2. Review: The lead maintainer personally reviews all incoming PRs for code quality, architectural alignment, and security. Automated CI/CD pipelines run unit tests and build checks to ensure stability.
3. Decision: The lead maintainer makes the final decision to merge or reject changes based on technical merit and project roadmap alignment. All decisions are documented in PR comments.

Future Governance & Committer Appointment

As the project grows, we plan to transition to a more decentralized governance model:

1. Committer Criteria: Active contributors who consistently submit high-quality PRs, engage in community support, and demonstrate a deep understanding of the plugin architecture will be identified.
2. Appointment Process:
   • Existing maintainers will nominate candidates.
   • A consensus-based discussion among current maintainers will take place.
   • Upon approval, new committers will be granted write access and added to the official maintainer list.
3. Conflict Resolution: In case of disagreements, technical decisions will be guided by the project's core design principles (modularity, isolation, and performance). Major architectural changes will require community discussion via GitHub Discussions before implementation.

We are committed to transparency and will document these processes in a GOVERNANCE.md file as the community expands.

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?

Currently, Fastdotnet does not have a formal Contribution License Agreement (CLA) in place, nor is there an automated system to check for signatures.

Contributions are accepted under the project's MIT License. By submitting a Pull Request, contributors implicitly agree that their contributions are licensed under the same terms. As the sole maintainer, I manually review all contributions to ensure they align with the project's goals and licensing requirements.

However, if joining the .NET Foundation requires a standardized CLA process (such as using EasyCLA or a Developer Certificate of Origin - DCO), we are fully prepared to implement the recommended verification mechanism. We understand the importance of IP clarity for foundation projects and will adopt the foundation's preferred tooling for tracking contributor agreements.

CLA Notification Alias

[email protected]

Select the Project Transfer Agreement model

Contribution

Repository Layout

As part of joining the .NET Foundation, we plan to refine our repository layout to align with foundation best practices:

1. Standardize Root Structure:

   • Ensure the presence of standard files: README.md, LICENSE, CODE_OF_CONDUCT.md, CONTRIBUTING.md, and GOVERNANCE.md.
   • Add a SECURITY.md for vulnerability reporting procedures.

2. Clarify Directory Organization:

   • Maintain a clear separation between the core framework (backend/) and frontend applications (Web/).
   • Consider moving plugin examples to a dedicated samples/ or examples/ directory to distinguish them from core source code.

3. Documentation Centralization:

   • Continue using the docs/ directory for VitePress-based documentation.
   • Ensure all technical guides and API references are easily accessible from the root README.

4. CI/CD and Automation:

   • Standardize GitHub Actions workflows in .github/workflows/ for building, testing, and publishing NuGet packages.
   • Implement automated license header checks and dependency scanning.

5. Branch Strategy:

   • Adopt a clear branching model (e.g., main for stable releases, develop for ongoing work) to facilitate community contributions and release management.

We are open to further restructuring recommendations from the .NET Foundation's Technical Steering Group to ensure the project meets the highest standards of maintainability and transparency.

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.

We are applying for Project Membership to establish Fastdotnet as a recognized and trusted component of the global .NET ecosystem. Our primary reasons are:

1. Ecosystem Validation: We believe Fastdotnet's true plugin hot-swapping architecture and micro-frontend integration offer unique value to .NET developers, especially for SaaS and modular application scenarios. Joining the Foundation validates this technical innovation.

2. Long-term Sustainability: As an open-source project, we aim to ensure its longevity beyond individual maintenance. The Foundation provides the governance structure, legal backing, and community trust necessary for long-term stability.

3. Standardization & Best Practices: We want to align our development processes, security standards, and documentation with the high bar set by the .NET Foundation, ensuring Fastdotnet remains a professional and reliable choice for enterprise users.

4. Community Growth: We hope to leverage the Foundation's platform to attract more contributors, foster a healthier plugin marketplace ecosystem, and collaborate with other .NET projects to drive the entire community forward.

Infrastructure Requirements Summary

Current Infrastructure Setup

Fastdotnet currently relies on standard GitHub infrastructure:

1. Build & CI/CD:

   • We use GitHub Actions for automated building, testing, and packaging.
   • Build servers are operated by GitHub's hosted runners (ubuntu-latest/windows-latest).
   • No self-hosted build agents are currently required.

2. Package Hosting:

   • NuGet packages are published to NuGet.org.
   • Frontend assets are distributed via npm or bundled within the backend plugins.

3. Web Hosting:

   • The official website (fastdotnet.top) and documentation (docs.fastdotnet.top) are currently self-hosted or hosted on third-party VPS providers.
   • Demo environments are hosted on cloud servers (e.g., Alibaba Cloud/Azure) for public access.

Foundation Support Requirements

As we join the .NET Foundation, we may require assistance with:

1. Code Signing:

   • We would like to utilize the Foundation's Authenticode Code Signing service for our official NuGet releases to ensure artifact integrity and trust.

2. SSL Certificates:

   • If the Foundation provides SSL certificate management for project-related domains, we would appreciate support in securing our demo and documentation sites.

3. Infrastructure Migration (Optional):

   • We are open to migrating our CI/CD pipelines to foundation-supported infrastructure if recommended for better security or compliance.

Currently, the project does not have complex infrastructure dependencies and can operate smoothly within the existing GitHub ecosystem.

Additional Notes

Differentiation from Existing Projects

While there are established modular frameworks in the .NET ecosystem (such as ABP Framework or Orchard Core), Fastdotnet distinguishes itself through:

1. True Runtime Isolation: Unlike many frameworks that rely on shared application domains, Fastdotnet uses AssemblyLoadContext to provide true DLL isolation. This allows different plugins to use conflicting versions of the same library without crashes, a critical feature for large-scale SaaS platforms.
2. Integrated Micro-Frontends: We offer a seamless out-of-the-box integration with qiankun for micro-frontends. This bridges the gap between backend modularity and frontend dynamic loading, enabling truly independent full-stack plugin delivery.
3. Lightweight & Flexible: We avoid enforcing heavy architectural patterns (like strict DDD) on plugin developers. Instead, we provide a flexible base that allows teams to choose their own internal architecture while maintaining system-wide stability.
4. Plugin Marketplace Ecosystem: Our focus extends beyond code; we are building a commercial-friendly ecosystem where developers can monetize their plugins, fostering a sustainable cycle of innovation and quality.

Potential Challenges & Areas for Support

As we transition into the Foundation, we anticipate needing support in:

1. Internationalization (i18n): While we have bilingual documentation, expanding our community presence in English-speaking regions will require guidance on effective outreach and marketing within the global .NET community.
2. Governance Scaling: Moving from a single-maintainer model to a multi-committer governance structure is a significant step. We would value mentorship from experienced foundation members on establishing robust voting and decision-making processes.
3. Security Audits: As a framework handling authentication and payments, periodic security reviews or access to foundation-sponsored security tools would be invaluable to maintain user trust.

We are excited to bring this unique "hot-swappable" architecture to the .NET Foundation and look forward to contributing to the community's diversity and technical depth.