Seeking Feedback: Licensing Plan for New Avalonia VS Extension

[MikeCodesDotNET]

Over the past year, our team has poured considerable effort into Avalonia Accelerate, and part of this work has been to create a new Visual Studio extension packed with new features. You can read about these in our blog post).

The challenge

We face a challenging question. How can we release the new extension while balancing our desire for broad community adoption with financial sustainability?

Building and maintaining advanced IDE tooling requires substantial investment. The new extension's features are built on technology we developed as part of Accelerate. This work represents well over a year of engineering by senior engineers. We ideally need to recoup this cost, but most importantly, we need to fund the ongoing development required to keep delivering improvements.

We're considering a few different release/licensing strategies for the new extension. None of these options are set in stone, and each comes with pros and cons.

We're creating this discussion to gather feedback on which approach feels most fair, or if there are other ideas we haven't considered.

Option 1: Accelerate Subscribers Only

The new VS extension would be available exclusively to Avalonia Accelerate customers. The existing free/open-source extension would go into maintenance mode with no new features (only critical fixes as needed).

The upside of this option is that funding for the extension scales directly with its adoption. The more subscribers using the extension, the greater our ability to reinvest in its development. This creates a clear alignment between user demand and our capacity to enhance and maintain the tooling.

We've always prided ourselves on Avalonia being freely accessible, so this route, while financially sound, doesn't sit right with many on the team.

Option 2: Delayed Community Release

With this approach, everyone gets the new extension eventually, but Accelerate subscribers get it first.

We might release Avalonia VS 12.0 to Business/Enterprise Accelerate customers now, and then a year later release Avalonia VS 12.0 (Community Edition) for all users for free.

This staggered release would mean paying customers always get the latest and greatest tooling, while the broader community still benefits from those enhancements but after a delay. The legacy extension would be phased out once the community edition becomes available, so we wouldn't need to worry about fixing any issues in the old extension.

The idea is to strike a balance and provide an incentive to subscribe without permanently locking out free users. The challenge is deciding on a reasonable delay. It would need to be long enough to encourage subscriptions, but not so long that the community feels left behind.

Option 3: Community vs. Enterprise Tier Split

This approach has had the most internal debate. It's a tiered licensing model based on the Visual Studio approach (Community, Professional and Enterprise).

The idea is that individual hobbyists, open-source developers, and small startups (anyone eligible to use VS Community Edition) wouldn't have to pay for the new Avalonia extension. They'd get the full experience for free from day one.

Developers in professional settings who use Visual Studio Professional or Visual Studio Enterprise would need to purchase an Accelerate subscription to use the extension (though we'd offer a generous no hassle free trial). This option would mean the extension remains free for the majority of our users (~60% if we go by last weeks numbers).

This approach could be a reasonable compromise as it aligns with the principle that cost shouldn't be a barrier for individuals, open-source contributors or small teams. Yet, it requires companies that benefit from Avalonia to contribute to its future.

License Abuse Risk

There’s a genuine risk of licensing abuse. Past experiences have shown that some developers deliberately circumvent licensing requirements, misrepresenting their work or employers to gain access to products and services they’re not entitled to. While some may assume larger enterprises wouldn’t allow such breaches, the reality we’ve observed is different. Individual developers within these organisations occasionally choose to bypass licensing restrictions, counting on minimal internal oversight and external enforcement.

Although circumventing licensing restrictions might seem harmless at an individual level, widespread abuse would significantly undermine our sustainability. If that were to happen, we’d have no choice but to adopt stricter licensing strategies to safeguard Avalonia’s long-term viability. Such an approach could introduce friction for users, which we’re keen to avoid.

Option 4: Feature Gating

In this option, every Avalonia developer could install the new VS extension and immediately benefit from a basic set of improvements. However, some features would be gated behind an Avalonia Accelerate subscription. The appeal of this option is that it encourages maximum adoption, with no one being excluded from using the new extension.

The biggest challenge would be the need to decide which features are to be free, versus which are important enough to justify gating behind a subscription. We would need to balance this very carefully to avoid fragmenting the user experience too much.

We Want Your Feedback 🙏

We haven't made any decisions, and the feedback we get will significantly affect what we do next. Each option has pros and cons, and we don't see any 'easy' answers. So we'd like to hear from you.

Specifically, we'd like to learn:

• Which options do you feel are the fairest or most workable, and why? (e.g. which best aligns with your sense of what's fair for the community and sustainable for the project?)
• What concerns or potential issues do you see with any of these models? (We want to know any pitfalls we should consider – whether technical, ethical, or practical.)
• Aside from the four listed, are there alternative ideas we should explore to fund IDE tooling development? (We're open to suggestions, as long as they're realistic. If you believe "all tooling should be free," we'd especially welcome thoughts on financially supporting a full-time development team to keep improving that free tooling.)

We want to find a path that keeps Avalonia thriving for everyone's benefit. We're spending a lot of time trying to balance being fair to the community and ensuring we can continue improving the platform.

Please share what you think. We're listening. 🙂

Note

Accelerate customers will be getting preview versions before anyone else, regardless of which option we ultimately move forward with.

[Dynesshely]

In my opinion, it's better to combine Option 2 and Option 4.
That's to say, Avalonia provides 3 options for users to select:

1. For personal use, select delayed community functions
2. For person or individual developer but who wish to pay for latest new functions, select feature gating, in another word, "pay for subscription"
3. For business use, buy business license

[Dynesshely]

Furthermore, I think that offering a lower-priced subscription will be a sustainable option.

In particular, such prices should be optimized for regions. Many well-known software in the world are directly converted at exchange rates rather than at parity purchasing power levels, which makes it difficult to roll out in many markets.

A typical example, my Chinese friend told me that the official website price of LINQPad8 is $125, which requires 900 CNY to convert directly using the exchange rate. In China, the salary of programmers is generally around 7,000 CNY, and a large part of it is paid for rent, water, electricity and other living expenses. The remaining money makes Chinese people think twice about anything over 1,000 CNY, which directly reduces the market share of LINQPad8 in China.

So I suggest that you should adopt a lower-priced subscription system, which can be monthly, quarterly or annual, and then provide a higher-priced long-term or lifetime license, which will help people get started. For example, 12 CNY per month is enough to attract Chinese developers to try to pay to experience the function, and once they start using it, there is the potential to convert it into long-term use.

In addition, I have channels to legally sell software products or subscriptions in the Chinese market. If you need it, you can contact me via cronyet@gmail.com.

[hez2010]

As for option 3, Visual Studio Community allows individual and open-source use for free, but there are still some features missing compared to Visual Studio Professional and Enterprise. So it's actually a combination of option 3 and 4.

[thevortexcloud]

I will note that most of the features missing are things people almost never use/are nice to have. EG continuous testing. So there is not a huge incentive for most people to even buy the more expensive versions.

[thevortexcloud]

Option 1:

This is the worst option in my opinion if your goal is to ensure community adoption. But from a business point of view, I can understand the desire to do this. Even if I think it's the worst option presented.

Option 2:

My main concern with a delayed release is that it will be out of sync with Avalonia itself. Meaning if Avalonia decides to adopt large scale breaking changes (which has happened in the past, EG .10 to v11), the extension will be functionally useless and lock people into older versions of Avalonia. Which is obviously going to upset/frustrate a lot of people and cause them a lot of pain later when they can finally upgrade. This could be addressed by selectively backporting things, but it's a lot more work on your end.

If this issue can't be solved then I can't see high adoption of the free version of the extension (especially by individuals, who often move faster than companies). But otherwise I think this is a great option.

Option 3:

I think a community version for individuals/small companies is reasonable. While I think the concern of license abuse is legitimate, it's not something that can be easily prevented beyond giving people a strong incentive to buy the product/giving them a legitimate free option. People misusing the license is going to happen no matter what you do. I would also prefer Avalonia to not go down the invasive DRM route to try to mitigate it.

If you believe "all tooling should be free," we'd especially welcome thoughts on financially supporting a full-time development team to keep improving that free tooling.

I would love for the core to be open sourced. Which is what Jetbrains does with their IDEs. Most of the language specific stuff in their IDEs is really just implemented as paid extensions that can be installed in any of their IDEs. This would more closely align with option 4, where all the free features can have their source code available and the paid ones be offered separately. This also sets you up to support third party extensions for your extension, and therefore facilitate greater community involvement. How many people will actually do that though, remains to be seen. I know Resharper for example though, does have a decent extension community.

So to summarise:

Ideally you would do a combination of 2, 3 and 4 and open source parts of it.

• Eventually old versions get released for fully free so people who want to use the full features can without worrying about licenses (which makes businesses happy)
• People can also always use the latest feature gated version to make sure they have a version that works with the latest version of Avalonia
• People can pay for specific features they need which are not available in the free version yet

[MikeCodesDotNET]

Ideally you would do a combination of 2, 3 and 4 and open source parts of it.

Happy to discuss combination of approaches, but I want to be transparent that none of the code for the new extension will be made open-source. No other .NET UI framework makes their tooling code OSS, and that code represents some of the most complex and valuable parts of our tooling.

[HMO-SOUL]

I don't use avalonia for business but to be honest the 4th option is the best for all, our friends at MS use a similar strategy

We don't need all the features, with VS2022 community you can build an entire app without paying anything to MS, but the pro and enterprise editions offers better support from MS and faster development experience

It's better to make an advanced intelisense feature and mvvm templates or features paid while the rest should be free
This is my opinion, avalonia ui should do what is better for it sustainability, but please don't alienate the community since they stood by your side back when avalonia was small and unknown

[somedeveloper00]

Microsoft Visual Studio is big enough to be able to put some good features behind paywall while still having more than decent offers for the free users. I wonder if Avalonia, a much smaller project than Visual Studio, can run the same business model sustainably

[TETYYS]

i chose option 2 because there is zero chance my workplace will build with avalonia, but in my free time I don't have deadlines

[PerfectlyFineCode]

Both option 2 and 3 is fine for me since you should also get an incentive to keep working on it.

Also if option 3, would community edition be available to be used commercially or strictly non-commercial?

[MikeCodesDotNET]

We would follow the same rules as Microsoft for Visual Studio Community edition use.

You can use VS community for commercial development, but your organisation can't have more than 5 developers, 250 PCs or >$1m in revenue.

[stevecwilkinson]

I voted 4 as I think that is the only really workable option. As you note, option 1 doesn't sit well with your team; option 2 seems like a tricky to manage in terms of release schedule etc as noted in @thevortexcloud's comments; option 3 won't work because everyone will claim to be 'community edition' (as you noted).

Get the basic for free but get several extra valuable features if you subscribe seems to me the only viable model.

[stevemonaco]

If feature gating is used, I think it's reasonable to gate any features beyond:

1. What AvaloniaVS currently does.
2. Fixing the creation of event handlers in code-behind from XAML
3. Correct renaming of view files (XAML + code-behind together) in-IDE.
4. Making previewer optional if it remains as part of the VS extension. You can hide this, but it's truly never gone. We have views that automatically play sounds and yes, they play sounds while the previewer is not visible. We could write conditional previewer code for this, but ehh.
5. Showing proper type information and XML docs when browsing autocomplete in XAML.

This would leave some feature categories: resource management, perf/memory metrics, refactors, etc available for paid customers. Some features like hover XAML element/property for IntelliSense could also be paid. Showing default values for dependency properties would also be very handy.

I would prefer option 2 myself as long as the delayed version continues to work with the current Avalonia version. However, the pro VS extension will eventually obsolete itself as a paid product in 2-3 years. You need to ship enough enticing features to drive payment every year. Eventually the base product will become "good enough" and that year's paid features will become very niche or bloat. At some point, subscriptions won't cover that year's maintenance costs.

[BreyerW]

Eventually the base product will become "good enough" and that year's paid features will become very niche or bloat. At some point, subscriptions won't cover that year's maintenance costs.

This is largely (but not fully) mitigated by license: you cant use VS Community Edition if u have >1m $ revenue OR >5 developers OR 250 PCs

So even if Pro becomes superfluous or bloat you are still 'forced' to pay for it if you ever become big enough to no longer apply for free version

[bclehmann]

As someone who develops packages for Avalonia (and technically is also a contributor to Avalonia, but that's one commit from years ago), there's lots of work that's being given back by people who would be unlikely or unable to pay. I think having that ecosystem benefits y'all, including financially.

I think however it happens, it would be good for both sides of this if open-source contributors can have better tooling and then go on to make better packages for the rest of your users. Whether that means a dedicated open-source tier like Jetbrains has (which avoids license abuse, at the cost of manual validation of license requests) or just wrapping us into a community tier. You are after all getting something for free, which isn't a problem, it's free software in both senses of the word. But it is something that other platforms have paid their own employees to do.

And to be clear, aside from my desire to get shiny toys for free, I personally see good dev tooling as table stakes, so putting that behind a paywall is very concerning if it doesn't have a robust free version. Whether it's cut down, delayed, or only for certain uses, those restrictions still need to be reasonable and give good tooling (if not the same tooling) to everyone. A world where only paying customers and specially selected groups have access doesn't sit right with me, even if I benefit. You have a good and well-earned reputation as a long-lived open-source project, but that reputation is more fragile now that several .NET libraries have gone proprietary recently. That isn't your fault, but it is the reality unfortunately.

[jonashertzman]

As a very senior software engineer/architect, doing both professional consulting projects and personal open source hobby projects, here are my five cents why I choose option 3.

- If you want adoption, it must be possible to try out the entire development experience without any licensing hassle.
A very common use case, (and this is exactly how I found Avalonia and actually choose Avalonia for a customer project 2 years ago!), is something like this:

1. I google and/or ask in my community, "What cross platform GUI should I use?" and get an answer saying "try Avalonia".
2. I go to the homepage and read the first sentence "Avalonia is an open source UI framework for building beautiful, cross-platform applications from a single .NET codebase." Seems OK, I'll try this, so I go to the getting started page, follow the instructions, create my first project and click play.
3. From here on, I will not read anything on your web page ever again, I will only base my evaluation on my current development experience in Visual Studio, doing some mock up GUI similar to what the customer wants to see if this suits the needs for this project. If you hide any feature form me now, I will not even know they exist.

- The next thing you should take into account, do not fragment the learning process.

1. You do not want tutorial videos that are only applicable if you are on one license or the other.
2. Same goes for all forums like Stack Overflow, if the first answer you find is something like "If you have the paid extension, you can do like this, otherwise I don't know", This is such a punch in the face for someone still trying to evaluate if Avalonia is the right way to go, many people will just say "Well f**k you too! I'm gonna try Electron instead!"

- For open source development to work, there cannot be any way the code differs depending on what license is used.

1. There cannot be any requirement to be on either license to develop and contribute to a project.
2. Even if the code works fine, nothing in the GUI editor can look weird because it was made using "the other designer".
3. Even smaller nitpicks could be a problem, like preferred code styles, you do not want a scenario where all developers with the paid extension prefers "style a", while everyone on the free license prefers "style b".

[thevortexcloud]

"Well f**k you to! I'm gonna try Electron instead!"

To be fair, some people will say that anyway...

[Axivolt]

Personally, I prefer Option 4.
I believe that the base features should be available to everyone, while only those who subscribe should have access to the richer, more advanced features.

Regarding Option 3, I am not very favorable towards it.
Although it is a relatively rare use case, if someone is developing a non-commercial application using Visual Studio Professional or Visual Studio Enterprise (for example, creating personal tools), they would lose access to the XAML previewer that they have been able to use until now.

[alexander-miglis]

I don't like any of it while I understand you need to get funded somehow. If you have a project like this you want people to use it and not get hit by a wall of doubts.

I like this proposal more
https://opensourcemaintenancefee.org/

Regardless, keep up the awsome work you guys are doing

[llfab]

As a business user I would be very much ok with option 1. This may bring more of the other business users to an Accelerate license because a greate VS extension saves time and therefore the licenses cost value ratio is a no-brainer.

However, option 1 would need maintenance also of the "old" VS extension and that may take time and resource. Therefore, I consider Option 4 as the most viable solution. I agree with @stevemonaco that the feature gate should be exaclty where the old VS extension is. The previewer already saves a lot of time if you handle your design data well. A new incarnation of this will most likely solve the existing issues and instabilities with the VS extension, hence, license-less devs would already be better off. Everything on top of that I would put behind the gate. 100 / 150 EUR are really not that much to ask for more. Also, if more and more licenses are sold the VS extension and other tooling will improve much faster.

With Option 2 I would fear that it will obsolete itself very soon. Option 3 invites misuse.

[xmaxrayx]

option 3, there is why ppl like using unity3d , unreal engine.

90-150$ is still expansive for others epically when you don't get back the money, ppl who use it for work have on rich country have no issue the price need to be localized like on steam even need special price for student/not employed, Clip studio paint cost like 13 dollar lifetime, Affinity whole suits cost like >150$ universal lifetime on black Fridaay,

Personally, I don't care about the plugin if the old one works the issue the amount of crash and need to re-load every 10-seconds on rider/vs-studio while coding custom control is boring while in WPF you can adjust/add the grid well be more welcome for new users epically when you don't care on multi-platform.

idk how you balanced/get money thought, blender3D and other Foss projects have low donation, so you know most ppl dont donate to open-source.

[KG-droid]

Just to clarify I'm assuming this is related purely to the new extension, and that the current extension and Avalonia will remain free for all?

I'd say feature gating makes the most sense, and tailer said features to things that businesses in particular will want to take advantage of on a cost vs labour perspective, so as to not discourage the open source community. As if you can develop features that enable devs to make apps faster, and to a high quality, then if your fee is lower than the wages saved from devs not having to work as long, because those pay for features enable faster/better development, then its a no brainer to pay for it as a business.
You could add services as part of it as well, like getting a code review from a security perspective, Avalonia AI dev tool, etc.
Its much more enticing when your getting a continual service, rather than paying every month/year for features that were developed years ago.

[JaykeBird]

Personally, I'm down for a delayed community release (option 2). Giving your paying Accelerate users this year's coolest stuff, while giving the public last year's coolest stuff sounds like a decent way to go about it to me, without needing to worry about licensing issues or trying to decide what stuff to keep for Accelerate customers only or what-not. Of course, there's the issue that years later, when you have decent tooling and not as much cool new stuff for "this year" for your paying subscribers, that could be a problem... but there's also the fact that this extension is just one part of Accelerate, and ideally people would be subscribing/paying for more than just the extension.

I do think Option 3 would also be a good way to go about it, but I understand the concerns about license abuse. Maybe as a mitigating factor, you could combine it with Option 2, with the community licensed version being a few months/half a year behind?

My concerns with Option 4 would be, looking at what's mentioned in the blog post you shared, I'm not sure what could be roped off without compromising on the value of the new extension too much for the public (maybe the Automatic XAML Namespace stuff?). But if there's any more features coming now or later beyond what's listed on that blog post (like XAML refactoring or more tools for generating and editing control themes/templates), I think a valid decision could be made about keeping that stuff for Accelerate customers if you wanted to go this route. I feel like everything listed in that blog post is kind of a solid baseline, and pretty much anything beyond what's in there would be more in the "nice to have" bucket.

Other question... the blog post and most other comments here don't make a mention about the design preview pane that is currently in the legacy extension. Is that feature, in any form, being carried over to the new extension? I would also consider this a baseline feature, but it can be just precisely as it is now - just a way to preview what you've typed out, no actual way to edit your code via it (save the designer stuff for Accelerate).

[robloo]

I would definitely go for a community version vs. full pro/enterprise version. But to protect from license misuse gate some of the advanced features as well (which I think will be clear once the new designer is in as well).

That will allow completely dropping support (and archiving code) for the legacy extension. It's not good to keep duplicate sets of code around and just slows things down in maintenance, issue tickets, etc..

Other thoughts:

• While it does cost a lot to develop, it also shares backend tooling with other Accelerate products. You are therefore paying for some portion through other products already. There is no additional income to Avalonia for those already purchasing Accelerate. How many would purchase Accelerate ONLY for the VS extension is an open question -- but I guess it's a smaller number. There are other must-have features driving Accelerate adoption anyway.
• This is a prime contender for a loss-leading product. You may want to intentionally loose money on it to make it a breeze to develop Avalonia and grow market share -- eventually selling more Accelerate anyway. Competitive dev tooling with the wider ecosystem is paramount as well. Welcoming people in with a great initial dev experience is important.
• The sooner the old extension goes away the better. Nobody wants to maintain two similar products as mentioned above. That does mean the community edition license should accommodate basically all use cases -- just with a subset of features.

[dexcompiler]

I'm an indie developer and I plan to buy the Accelerate Buiness License because of the tremendous value it provides. I'm not representative of indie devs but I think the Avalonia team needs to take this into consideration because similarly, a few indie devs also go out of their way to purchase JetBrains Rider subscriptions [and indeed other tools]. I think folks generally underestimate how far folks will go to get superior tools required for their work. Won't be surprised to find that more than 80% of "indie" devs have an OpenAI/Anthropic/Gemini subscription [sometimes multiple combos].

JetBrains charged for their Rider software from day zero even in the presence of Visual Studio Community Edition and has been a very successful company since. They only recently started a Rider community edition for non-commercial dev after a few years. I think it's only fair that incentives are correctly aligned when it comes to developing very valuable tools. The core part of AvaloniaUI which is open source and the existing extension are already very valuable resources for whoever is interested in building software today.

I lean toward some mix of Option 1 and 3 which probably translates to having indie/non-commercial devs to commit a small fee [considerably lower than the lowest Accelerate subscription plan] to using the new Avalonia VS extension - in other words they don't have to be Accelerate subscribers, while the rest who want to can remain on Accelerate and have the benefits by default.

[HelgeKeck]

there is only option 3 for me. It avoids fragmentation, every user uses the same code base, delivers a much bigger dataset for you guys to improve and fix bugs.

[Move2win]

Unlimited and free for non-commercial use(hobby, learning, etc.), only need Accelerate subscription for commercial use (could divide into personal/indie tier and company/large team tier), everyone get the same updates/functionality.

For the non-commercial licence issuing method, you can check the PVS-Studio approach: Ways to Get a Free PVS-Studio License

IMO, this approach is far better than setting up barriers and roadblocks for non-commercial users.

• First, it promotes your extension through other developers' code, letting people know this is a thing.
• Second, it provides unlimited learning opportunities for all, so no "learning/getting used to new functions" after purchasing the commercial license. What you're used to is what you'll be using.
• Third, by attracting more developers to try it, more companies will purchase the commercial license as their employees request. Setting up barriers WILL only make it LESS attractive!

It's like the Microsoft approach, they look away when individuals/small businesses use the cracked version of Windows or Office to get ppl used to their products and then targeting big company batch purchases, that's where your money comes from.

[anewton]

The VS extension provides a path to onboard future AvaloniaUI developers that is easier than a paid for model.

I use AvaloniaUI for hobby projects exclusively at home. Using VS Community Edition. Option 3 has my vote.

I write desktop apps for my astronomy hobby. Such as a horizon editor, a Stellarium integration utility for object bookmarks (stars and such), and for a quick GPS integration to get lat/long from a USB device and quickly open up Stellarium. I also have projects I'm actively working on to track my family genealogy, a personal planning calendar that functions just like the old version of the newer Outlook calendar, and other odd desktop applications I feel like working on. Also for a remote controlled rover and a live video viewer from various Raspberry Pi devices. I write most apps using approaches found in enterprise architectures as well.

I would be interested one day in bringing one or two to a marketplace. But have no roadmap for that at all now. I would also like to see more employment opportunities that use AvaloniaUI. So for those reasons, I would like to see the new extension available for free in the VS Community Edition (and VS Code). While organizations or hobbyists that are selling their software must use the paid for version.

I think that nobody in my geographic area of the PNW even knows about how wonderful this desktop framework is. As a cross platform desktop application platform.

Here is the current list from your Avalonia VS Extension repo readme file. I see the following features listed. With a new Avalonia VS Extension, the assumption is that this list and more features would be available. I would like to see rendering in the XAML previewer that doesn't require a complete rebuild of my solution in VS Community Edition. I would also like to see a broader range of item templates to choose from. Perhaps a Styled Property, an AttachedProperty, and a DirectProperty set of code snippets that are included in the Avalonia VS Extension.

• XAML code completion.
• XAML previewer.
• It bundles Avalonia templates in your Visual Studio.
• Icons for axaml files.

That's my vote. I hope the risks associated with that model can be mitigated.

[thevortexcloud]

Also out of curiosity, how does this work if you have Resharper and the extension installed at the same time? There is a lot of overlap (and conflicts) in their features.

[bukowa]

If you make a lot of money using Avalonia you should contribute that money to the project...

[giard-alexandre]

Out of curiosity: what differences are there between the new improved VS extension and the Rider one? I feel like most (if not all) of the features in the new VS extension are already present in the Rider one?
Also, how would this affect the Rider extension? I assume that if the VS extension gets paid support for it, at some point that one would be significantly better than the Rider extension? 😦

[Tape-Worm]

My use case is that I integrate Avalonia with my rendering API so it can be used in Avalonia based applications. I also plan on redoing my tooling application that comes with my API to use Avalonia exclusively (it's in Winforms for now). My API is open source, and free to anyone who wants it and I make absolutely no money off of this, I do this for the sheer joy of sharing knowledge with others, to give back to the community I've learned so much from.

Naturally, I want to see you guys continue your work, and I am more than happy to facilitate that by buying a license. You'll note I said "buying", not "subscribing". I am subscribed to death, and I am absolutely done with being nickle and dimed by every little f*****g thing. So ideally, I'd like to buy a license, and if need be, buy upgrades for later versions on my own schedule.

A concern I have is cost. Again, I make no money off of my project, nor do I want to. And 150 Euros or whatever, is nearly $240 CAD depending on exchange (and this expense would be yearly on subscription!). Discounts for open source projects (with proof of ownership, naturally) would be nice, because, again, if I'm not making cash off of my own stuff, I can't justify spending that much on a single thing that's only a small part of my project every year.

Another concern I have is that since I am supporting an open source project, I want my users to be able to download and compile and use my APIs and tooling without requiring a license to Avalonia. I'm sure you folks are aware of this kind of thing, but I feel it needs mentioning. One of the reasons I don't use DevExpress or other control libraries for some of my tooling is because I can't open source my stuff without requiring the end user to have a license for the components. My only solution there would be to make my tooling closed source, while the rest of it remains open. That's just a lot of pain that I don't want. I hope this won't be the case with code built using Avalonia VS.

And my final concern is fragmentation in versioning. So, let's say I build up my stuff using Avalonia VS free. I keep my nuget packages up to date for security considerations and whatnot. Version 15 is released, yay. I update my nuget stuff to keep things clean, but oh no, my Avalonia VS is still on version 14 and now I can't work with my stuff. Now, I have to downgrade, and Visual Studio will bug me about the out of date components until everything reaches parity. This, of course, is an inconvenience and not insurmountable, but it is very very very annoying. Enough to make me not want to continue using/supporting Avalonia.

Again, I'm more than happy to pay a reasonable price for Avalonia VS. I'm just concerned that it'll either be too expensive, or be a major hassle for myself or my users.

As for which option I'd go for? Option 2 sounds good in theory, but version fragmentation becomes an issue. 3 has license abuse issues (not that you can ever really stomp that out). And 4 can have issues with version fragmentation as well.

Some combo of 2, 3, and/or 4 is probably the only way it makes sense.

P.S. Whatever you do, please, please, please, please do not do what ImageSharp has done and create some weird hybrid custom license, that stuff scares the crap out of me.