Add proposal for Dapr + .NET Aspire ownership.

[philliphoff]

Adds a proposal for the transfer of ownership of the Dapr + .NET Aspire integration to the Dapr .NET SDK.

[yaron2]

Thanks for this proposal. I have grave concerns about our ability to maintain the Aspire integration. Dapr for Dotnet alone has ~10x more downloads per major version than Aspire and only two active Dotnet maintainers. Briefly auditing the Aspire repository, it looks like a large chunk of Aspire users are also Dapr users. Asking our maintainers to take on this additional work could lead to a disservice to both our end users and maintainers. As a mitigation, the Aspire team could install a new maintainer in the Dapr Dotnet SDK to make sure there's adequate bandwidth to address the influx of new work.

[WhitWaldo]

@yaron2 - I sympathize with your concerns about maintaining the Aspire integration alongside our current workload. There certainly seem to be more feature asks than contributions in the Aspire repo today. I talked with @philliphoff about it today and agree that integrating this functionality into the Dapr repo might reduce some friction and encourage more community contributions since it may mitigate any trepidation about contributing to a large project like Aspire.

I'd certainly welcome any additional support from Microsoft or otherwise, but I also think that maintaining the status quo isn't beneficial to either project, as indicated by some of the chatter about improving the Aspire integration in Discord. Philip is spot on that having the same maintainers of the Aspire integration and the Dapr .NET SDK itself makes sense.

On balance, I think this integration could be a net (pun intended) positive for .NET Dapr developers despite the several outstanding logistical issues (license migration, versioning, documentation hosting and migration, etc.).

[WhitWaldo]

"automated" -> "automate"

[yaron2]

I talked with @philliphoff about it today and agree that integrating this functionality into the Dapr repo might reduce some friction and encourage more community contributions since it may mitigate any trepidation about contributing to a large project like Aspire

Actually, I think its the other way around. As a project, Dapr is much larger than Aspire and unlike Aspire, Dapr has two parts to any contribution - the SDK + the runtime which makes it more challenging to contribute from a developer perspective.

[WhitWaldo]

Actually, I think its the other way around. As a project, Dapr is much larger than Aspire and unlike Aspire, Dapr has two parts to any contribution - the SDK + the runtime which makes it more challenging to contribute from a developer perspective.

@yaron2 Taken as a whole, that's certainly true. I was approaching this from the perspective of .NET developers who primarily use the .NET SDK and might find Aspire, similarly written in .NET, more accessible for contributions. At least on the .NET side, this might lower that barrier for those developers and encourage more community involvement, even if not necessarily on the runtime side.

Considering this today, I've thought of two additional points to toss out there:

1) There's documentation for hosting both Python and Node apps on Aspire. If we take over Aspire.Hosting.Dapr, is there reason to anticipate demand for Aspire + Dapr integrations for other languages as well, e.g. Aspire.Hosting.Dapr.NodeJs or Aspire.Hosting.Dapr.Python? That would be a significant ask of the other language maintainers.

1. I read more into what's involved in the hosting and I don't believe these require any language divergence as they require VS projects with the Aspire markup and then utilize the AppHost .NET style to link everything together, so disregard that point. The following still stands as a versioning option though.

2. On the positive side, Aspire.Hosting.Dapr is for .NET usage. Taking over support could be an opportunity to align it with the Dapr release schedule by creating a new package: Aspire.Hosting.Dapr.Dotnet. The existing Aspire.Hosting.Dapr package could be either marked as deprecated or serve as a wrapper for the new package in the short term.