Call for maintainers: Legacy TreeDataGrid & Visual Studio Extension

[MikeCodesDotNET]

As we prepare to release the next phase of Avalonia Accelerate, we want to start the discussion around what happens to the legacy offerings that we’re replacing.

In particular, this concerns:

• AvaloniaVS (Visual Studio Extension)
• Avalonia.Controls.TreeDataGrid

Our focus will be on the new Accelerate editions going forward. Accelerate includes a redesigned Visual Studio extension (which will also be available under a Community License) as well as a more capable tree data grid control. At the same time, we know there are developers who would prefer to continue using the existing open-source editions rather than moving to the new replacements.

To ensure there’s still a path for those who want to keep these projects alive, we’re considering transferring the repositories out of the AvaloniaUI org. One option is the Avalonia Community org, which could provide a neutral, community-driven home.

We’d like to use this thread to hear the community’s thoughts and to identify anyone interested in stepping up as maintainers. If there’s appetite to continue development, we’ll support a smooth handover.

The goal is to provide a clear future for those who wish to maintain and use the legacy projects.

[Numpsy]

Should this be mentioned over in the TreeDataGrid repository? Tne pinned issue over there is still talking about license changes in the existing version.

[djeikyb]

Sorry this is a bit off-topic but:

• Is it possible for the AVLIC0001 build error to indicate the library name? In this case, "Avalonia.Controls.TreeDataGrid"?
• Rider's nuget browser doesn't show the requirements section. There's a nice message about licensing on the nuget page, but it's not visible where I actually manage dependencies.

I started a new csproj from a custom template and updated all stale dependencies in bulk and was lost for like five minutes with this build error (my fault, for doing it in bulk). I'm excited to see this control rolled into active dev under Accelerate!

[kekekeks]

Is it possible for the AVLIC0001 build error to indicate the library name? In this case, "Avalonia.Controls.TreeDataGrid"?

This should be addressed in TreeDataGrid 11.2.1

[jomarcenter-mjm]

OK I am completely was not aware what going on with this especially the visual studio extension. No heads up about this critical news on any platform at all. 2 people only commented this and this was super quick no one would Sound the alarm that this is going on with the Avalonia source codes.

dont screw around with the Visual studio extension. Avalonia already have the accessibility advantage especially Qt with better feature exist.

Warning this comment is being monitored.

[MikeCodesDotNET]

This was published weeks ago and was pinned to the discussions.

We then later published a blog post about the changes. This was shared on Twitter, Bluesky, Mastodon, LinkedIn and Reddit.

We warned about the DataGrid change more than a year in advanced and the VS extension change has been discussed since at least Q1 this year.

Where else should we be publishing to make sure everyone see's it?

[robloo]

The issue appears to be because no new visual studio extension was registered. This means the new Accelerate version of the extension replaces the old one automatically when it's updated. That then forces the banner and login prompts. For existing users I can see how this is unexpected and a concern.

That said, I can see the reason the Avalonia team did this as well. There is a community version of the new VS extension. The previously open source extension didn't have maintainers per this discussion. So leave users with an unmaintained extension or automatically update them to the new one?

So there were going to be issues either way. The easiest solution I think is to tone down the marketing on the new visual studio extension so it's a transparent change to those that have been using the old extension all along. Marketing decisions are hard too though -- you need revenue but you also don't want to bother your users. So just take this as a data point that maybe the marketing is a bit too loud.

[stevemonaco]

I think bumping the existing Avalonia.Controls.TreeDataGrid and the VS extension with some notification of deprecation would have went more smoothly. The Accelerate products would start from a fresh root (new NuGet package, new VS extension name) so the rollover isn't automatic. Picking new names is hard though.

[daniel-lerch]

@MikeCodesDotNET in AvaloniaUI/Avalonia.Controls.TreeDataGrid#307 you wrote that TreeDataGrid will be dual-licensed APGL-3.0 and a commercial license by late 2024. Now the repository has been archived and I am wondering, whether an AGPL-3.0 version is available somewhere or at least planned?

[robloo]

The fact that no maintainers have stepped up validates the decisions by the Avalonia team here I think. Very few are willing (or have time) to put significant work in on these areas of the framework. Those that were are now working full time as part of the company. That said, no maintainer is going to step up until it's required for some reason. So we could wait some time for someone to come along and decide they need to resurrect the code -- if they come along at all.

[lextm]

Thanks for the thoughtful comments, @robloo. I’d like to echo some of your points, though my perspective relates more to AvaloniaVS than TreeDataGrid.

Why No One Stepped Up

An active fork can be created at any time, before or after this call for maintainers.
However, this announcement doesn’t make clear what benefits or responsibilities new maintainers would actually have.
The mention of repo ownership or an “Avalonia Community” umbrella feels optional, and what’s missing is a clear explanation of what kind of future development remains meaningful for these components and who makes those decisions.

A concrete example: my team maintains a fork of the Avalonia VS Code extension, which depends on a fork of AvaloniaVS we also maintain (since our pull request to AvaloniaVS was declined).
We’re happy to continue maintaining the parts required for the VS Code extension, but the Visual Studio integration itself is currently irrelevant to our clients, who fund the work.

About the AvaloniaVS Situation

It’s understood that AvaloniaVS on GitHub will remain open source, but the new Accelerate build has already become a commercial fork with new and exclusive features.
That fork is being promoted through Accelerate’s commercial and community tiers, where the latter comes with feature and revenue limits.

From a contributor’s perspective, that creates uncertainty.
If the commercial fork is the actively maintained one, it’s unclear what direction community maintainers are expected to take, or how their work would align with the official product, and whether that means complementing or competing with it.

As you mentioned earlier, a full fork of AvaloniaVS would be a significant undertaking.
We’re a small team deeply familiar with the VS Code ecosystem, but Visual Studio’s closed-source nature makes extension maintenance far more complex.

Why This Matters

Our team’s involvement began because VS Code support was largely neglected during the Accelerate rollout.
We stepped in to ensure our clients (and other developers in similar situations) could still have a modern, working experience there.

Another group may eventually revive or extend AvaloniaVS once there’s a stronger business case for it.
But at present, the balance of effort and incentive isn’t clear for potential maintainers.

For now, we’ll keep focusing on the VS Code tooling.
Of course, if the Avalonia team reveals their VS Code roadmap or announces a commercial build of AvaloniaVSCode in the near future, we won’t be surprised and will adjust our course accordingly.

[MikeCodesDotNET]

I want to address your points.

On maintainer uncertainty, you're right that we haven’t defined a roadmap for community maintainers, and that’s intentional. These repositories are no longer actively developed. Our engineering efforts are now directed toward Avalonia Accelerate versions. We explored transferring the repositories to community ownership, but there was no interest. They remain FOSS, but we won’t spend time coordinating community forks, as they’re not our responsibility.

On the commercial/community relationship: Avalonia Accelerate is where our tooling and component development now happen. Accelerate provides actively maintained, commercially supported tooling, which is free for most of our community. If community maintainers want to fork the old tooling, that’s entirely up to them. They can choose whether to complement or compete with Accelerate.

It’s also worth clarifying that your first engagement with us came after you had already forked and republished the VS Code extension using our trademarks. When contacted about that, you proposed a co-branded partnership in which your company would maintain the extension, with Avalonia funding the work and licensing our brand. That’s not the kind of community collaboration we can support, which is why we declined.

On VS Code “neglect”: The VS Code extension took significant investment to develop. We spent mid-five figures building it and initially made it available only to GitHub sponsors to offset costs. That approach proved impractical, as 81% of access requests came from non-sponsors, so we made it open source. The extension has been maintained throughout, though not at the pace some might prefer. Community contributions have been limited regardless.

On forking and trademarks: This, at least for me, is the really important bit. We support forking and see it as a core strength of open source. What’s not fine is using our trademarks without permission. The MIT licence covers code, not brand identity. You’re welcome to maintain forks, but they need to be clearly differentiated from official Avalonia projects. If you wish to fork our Visual Studio or VS Code extensions, you’re free to do so, but you cannot use the Avalonia name or branding.

Regarding the future of the VS Code extension: our focus is on delivering supported, actively developed tooling through Avalonia Accelerate. The legacy repositories remain available, and anyone is free to fork them, but we won’t be coordinating competing forks or providing roadmaps for them.

[thevortexcloud]

If the commercial fork is the actively maintained one, it’s unclear what direction community maintainers are expected to take, or how their work would align with the official product, and whether that means complementing or competing with it.

Generally in FOSS, you either ignore the commercial product, implement the features directly (EG see things like OpenMW which is a complete FOSS recreation of a proprietary closed source game engine capable of loading the original game assets and code), or go in a completely different direction. Once a fork is made, there is no real direction for the project to move in beyond what the developers want it to move in. That said I have seen a number of FOSS products that try to 1:1 copy a closed source piece of software to the extent they can without breaking the law. Sometimes they end up replacing the proprietary thing they sought to copy because it's just simply better.

[NeverMorewd]

I'd like to suggest adding a new identifier for the legacy TDG and VSEx, rather than using version numbers to tell them apart.