Issue: New .NET Foundation Project Application

Project Name

Microsoft 365 Advanced Analytics

License

MIT

Contributor

Sam Betts, Jesus Fernandez Saez

Existing OSS Project?

Yes

Source Code URL

https://github.com/pnp/Microsoft365-Analytics-Insights

Project Homepage URL

No response

Project Transfer Signatories

Sam Betts sambetts@microsoft.com
Jesus Fernandez Saez jesusfer@microsoft.com

Description

Open-source .NET engine that collects enhanced Microsoft 365 usage data into a SQL database you own, with Power BI adoption reporting.

What are you hoping from the foundation

Primarily code-signing infrastructure (we self-manage a cert today) plus the visibility, neutral governance, and CLA/licensing support to grow contributions and collaboration.

Name

Sam Betts

Email

sambetts@microsoft.com

GitHub Profile URL

https://github.com/sambetts

Committers

Active maintainers with commit/write access (listed in CODEOWNERS), who handle day-to-day commits on behalf of the project:

• Sam Betts — GitHub: sambetts — Microsoft
• Jesus Fernandez — GitHub: jesusfer — [employer]

Because the repository sits under the pnp organization, the PnP organization owners also inherit admin rights on it (not active committers on this project):

• GitHub: erwinvanhunen
• GitHub: waldekmastykarz
• GitHub: patrick-rodgers
• GitHub: pkbullock
• GitHub: Laskewitz
• GitHub: Adam-it
• GitHub: alexc-MSFT
• GitHub: PopWarner
• GitHub: shivvad

Discord Ids

No response

Governance Model

Proposing changes
All changes are proposed as GitHub pull requests. Contributors fork the repository or create a feature branch and open a PR against the "dev" branch, following CONTRIBUTING.md. For anything beyond a trivial fix, contributors are asked to open
or comment on a GitHub issue first (using our Bug report / Feature request templates) so the approach can be agreed before work starts. Security issues are reported privately via our Security Policy (GitHub private vulnerability reporting), not as public PRs.

Review
Every pull request targets "dev" and is automatically validated by our GitHub Actions workflows (build and unit tests run on each PR). The repository has a CODEOWNERS file, so the project maintainers (currently @sambetts and @jesusfer) are automatically requested as reviewers. Maintainers review each change for correctness, scope, security, performance (the solution is expected to run at large tenant scale) and consistency with the project's coding conventions, and may request changes before it can be merged.

Accepting changes
A change is accepted once CI is green (build + tests pass) and it has approval from a project maintainer / code owner. Maintainers merge approved PRs into "dev" using a merge commit. Changes then flow from "dev" to "main", where the GitHub
Actions release pipeline produces the signed, deployable artifacts published as GitHub Releases. Significant design decisions or disagreements are discussed on the issue/PR and resolved by the maintainers, in consultation with PnP
organization leadership where needed.

Appointing new committers
The project is part of the Microsoft 365 & Power Platform Community (PnP) organization. New committers are identified by a track record of sustained, high-quality contributions and constructive participation in issues and reviews.
When a contributor has demonstrated this, the existing maintainers — together with PnP organization leadership — invite them to become a maintainer, grant write access, and add them to CODEOWNERS as appropriate. Write/admin access is managed
through the pnp GitHub organization.

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?

No response

CLA Notification Alias

No response

Select the Project Transfer Agreement model

Contribution

Repository Layout

Current state
The public GitHub repo (pnp/Microsoft365-Analytics-Insights) is already the single upstream / "master" for the project - there is no separate internal source of truth. The core development team uses the same process as external contributors: feature branch or fork -> pull request against the "dev" branch -> CI (build + unit tests) -> CODEOWNERS review -> merge. We will keep this model after joining.

Already in place

• Root README.md, MIT LICENSE, .gitignore
• CONTRIBUTING.md, CODE_OF_CONDUCT.md (adopting the .NET Foundation Code of
  Conduct), SECURITY.md
• Issue templates (bug / feature), pull request template, CODEOWNERS
• Source under /src (AnalyticsEngine + SPO), Power BI assets under /reports,
  tests under src/AnalyticsEngine/Tests.*

Changes we would make as part of joining

1. LICENSE / copyright: update the copyright statement at the top of LICENSE to "Copyright (c) .NET Foundation and Contributors. All Rights Reserved" (keeping the MIT terms), per the Project Assignment Agreement and copyright guidance. (Currently it reads "Copyright (c) 2024 Microsoft 365 & Power Platform Community".)
2. File headers: add the standard .NET Foundation source-file header ("// Licensed to the .NET Foundation under one or more agreements. ...") to our source files, which currently have none.
3. CLA: enable the .NET Foundation CLA bot and update CONTRIBUTING.md to cover signing the CLA on a first pull request.
4. Add a .gitattributes for line-ending normalization (not present today).
5. Add NOTICE.md / ThirdPartyNotices.txt surfacing the third-party components we bundle/depend on and their licenses.
6. (Optional) Make documentation PR-reviewable by mirroring our GitHub wiki into a "Documentation/" folder or docs repo, per the guidance's preference for a docs folder over a wiki. We currently maintain docs in the GitHub wiki.

We do not anticipate restructuring the source tree itself; it already follows /src + /reports with tests alongside the solution.

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 to give the project a neutral, long-term home with the Foundation's governance and credibility, and to gain code-signing infrastructure, CLA/licensing support, and the visibility to grow our contributor community - in line with the Foundation's mission to strengthen the .NET ecosystem through openly developed software.

Infrastructure Requirements Summary

Build servers
All CI/CD runs on GitHub Actions using GitHub-hosted runners - windows-latest for the .NET / MSBuild builds and installer signing, and ubuntu-latest for the TypeScript SharePoint "AI Tracker" build and the release step. Builds trigger on
push to main/dev and publish versioned artifacts as GitHub Releases. We do not need any dedicated or self-hosted build servers; the existing GitHub Actions setup is sufficient.

Web / service hosting
The product itself is not a hosted service - each customer deploys it into their own Azure subscription (App Service web jobs + an admin web app, Azure SQL, Redis, and optional Service Bus / Cognitive Services / Automation). So there is no
central application hosting the Foundation needs to provide. The public surfaces are the GitHub repository, the GitHub wiki (documentation), and GitHub Releases (artifact distribution).

We do operate two small ancillary endpoints today, in a maintainer-controlled Azure subscription:

• An Azure Blob Storage container that hosts the installer's downloadable
  software payloads (referenced by the installer at runtime).
• An optional, anonymous usage-telemetry/stats Web API (the src/TelemetryService
  component) that importer jobs can post aggregate stats to; it is skipped
  entirely if an operator leaves it unconfigured.
  These are modest and can remain maintainer-operated. We're open to discussing whether the Foundation would prefer them hosted/funded differently.

SSL / Authenticode code signing
Code signing is our main infrastructure ask. The Windows installer (AnalyticsInstaller.exe) is Authenticode-signed during the GitHub Actions release build, currently using a self-managed PFX certificate stored as GitHub secrets and timestamped via DigiCert. We would like to move to the Foundation's code-signing service so releases are signed under a Foundation-backed certificate and we no longer manage/renew the certificate or store its secret ourselves.

We do not require any SSL/TLS certificates from the Foundation: there is no project-run public website, and customer deployments use their own Azure TLS certificates. (The two ancillary endpoints above already terminate TLS in our
existing Azure setup.)

Additional Notes

General notes
This project is maintained as part of the Microsoft 365 & Power Platform Community (PnP) and developed in the open on GitHub (pnp/Microsoft365-Analytics-Insights), which is the single source of truth; releases are published as signed GitHub Releases. Ahead of this application we added a Code of Conduct (the .NET Foundation CoC), SECURITY.md and CONTRIBUTING.md, enabled GitHub Discussions and private vulnerability reporting, and set the repo home page to the wiki.

Similar projects and how we differ
The closest alternatives are Microsoft's own offerings — the built-in Microsoft 365 usage reports / admin center, the Power BI "Microsoft 365 usage analytics" content pack, Viva Insights (formerly Workplace Analytics), and Microsoft Graph Data Connect (MGDC) — plus commercial third-party M365/SharePoint analytics products (e.g. CardioLog, Rencore, AvePoint). We differ in a few key ways:

• Open source and self-hosted: it runs entirely inside the customer's own Azure tenant and writes to a SQL database the customer owns — no SaaS, no per-seat fee, and data never leaves their compliance boundary.
• Ownable, long-term history: queryable detail instead of the rolling 7–180 day, pre-aggregated, often de-identified built-in reports.
• One joined schema across workloads (SharePoint, Teams/calls, Outlook, OneDrive, Viva Engage, Copilot, Power Platform) at page/click/session, call, message and Copilot-interaction granularity, with users enriched by department, manager, title and licensed SKU.
• Turnkey: a deployable engine + installer + ready-made Power BI reports, rather than a raw data-export pipeline (like MGDC) that requires the customer to build their own data engineering.

Areas where we may need early help / things to discuss

1. Code signing: guidance on moving our GitHub Actions release pipeline from a self-managed Authenticode PFX to the Foundation's code-signing service, for a classic .NET Framework WinForms installer.
2. Copyright / CLA and Microsoft employees: several maintainers are Microsoft employees contributing as part of PnP. We'd welcome guidance on the Project Assignment Agreement, applying Foundation copyright + file headers across the existing codebase, and how the .NET Foundation CLA interacts with Microsoft's corporate CLA coverage.
3. Trademark / naming: the project and repo names reference "Microsoft 365" (a Microsoft trademark). As a Microsoft-sponsored community (PnP) project we believe this is supported, but we'd like to confirm naming/branding guidance.
4. Ancillary services: a small Azure Blob download container and an optional telemetry/stats API currently run in a maintainer-controlled Azure subscription; we'd like to agree how these are owned/funded going forward.
5. Documentation: our docs live in the GitHub wiki; if the Foundation prefers a PR-reviewable docs folder/repo, we'd welcome help planning that migration.
6. Maintainer base / bus factor: there are currently two active code owners; growing the contributor and maintainer base is one of our goals in joining.