I get that, and I also understand how hard it is to balance the needs of the company with the needs of the community, but some of these features feel like they are going to result in splitting the user base/making a lot of people mad if they are not made available in some form for free. People are likely not going to expect to have to pay to debug what is wrong with their code.

I appreciate your concern about the potential for upset within the community. It's crucial to clarify that we're not removing any existing functionalities; instead, we're introducing new, optional paid features to sustain and grow Avalonia.

It's also important to recognise that sustainable development requires resources. We've provided a lot of value for free, but we need a more balanced approach to continue. We value all our users, but the sustainability of our project is paramount. Those who have not contributed financially and are voicing discontent must understand that the entire community could lose out without this shift. We're committed to our user base but must ensure Avalonia's longevity.

The messaging has changed slightly here if I recall correctly. Avalonia XPF for the foreseeable future seems to be taking off. It seemed from comments some time ago Avalonia XPF would help sustain the team so a portion of the time could remain on Avalonia. It seems now you have siloed business units so to speak so Avalonia XPF and Avalonia itself must be independently self-sustaining. That has increased the difficulty of the original plan as I understood it. Of course for the long-term perhaps that's the only way to manage the financial aspect here -- its just different than some earlier comments.

Hey Rob, it's always lovely to hear from you!

Let me clarify a few points to address your concerns. Firstly, our stance towards Avalonia XPF as a revenue driver remains unchanged. We continue to see it as an integral contributor to funding the development of Avalonia.

Regarding the structure of our operations, we don't operate siloed business units. Our team is compact, and we operate in an integrated manner. The idea that each project must be self-sustaining is not our approach. In fact, we view Avalonia as a foundational element that, while not directly profit-generating, is crucial to our overall ecosystem. It's more of a strategic investment than a standalone business unit.

We shared some information about our financials in a previous blog post. That information is now slightly outdated as we closed some additional deals before the EOY.

Last year, our revenue grew by 8.17%, primarily driven by Avalonia XPF. However, we also saw a significant increase in staff costs, which grew by more than 100%. This increase reflects our commitment to investing in Avalonia's future, but you can likely see why we're exploring other avenues for revenue generation. While we have grown our team, we still need more team members to help manage the community's needs effectively.

Our strategy and commitment to Avalonia and its ecosystem remain firm. The challenge we face is balancing our growth and investment in the platform with the need to generate sustainable revenue. This balance is critical to ensuring the long-term success and development of Avalonia.

instead, we're introducing new, optional paid features to sustain and grow Avalonia.

I don't have a problem with that. People should be able to be reasonably compensated for the work they do, and this is a struggle many FOSS projects run into when they try to scale. However it's fairly important what gets locked behind the pay wall to ensure the core product (which is free) also remains viable (not just from the point of view of having people commit code). Many other projects have tried doing stuff like this before, and in some cases the company went too far which resulted in the entire project being forked and the fork becoming arguably more popular than the original.

I would prefer Avalonia not shoot itself in the foot here by pay walling features some people would consider essential. That said, I am personally fine with some sort of paid advanced control library, kind of like Telerik's,

I don't have a problem with that. People should be able to be reasonably compensated for the work they do, and this is a struggle many FOSS projects run into when they try to scale. However it's fairly important what gets locked behind the pay wall to ensure the core product (which is free) also remains viable (not just from the point of view of having people commit code). Many other projects have tried doing stuff like this before, and in some cases the company went too far which resulted in the entire project being forked and the fork becoming arguably more popular than the original.

We are not placing core features behind a paywall. The existing DevTools will remain as they are; we're developing an enhanced version for those who want additional features and want to help support Avalonia. It's a valuable addition but entirely optional.

We don't see the introduction of optional paid tools as detrimental. On the contrary, it's a strategic step to sustain the project. Our decision to focus on Dev Tools is based on its universal utility, yet it is optional for building Avalonia apps.

I would prefer Avalonia not shoot itself in the foot here by pay walling features some people would consider essential. That said, I am personally fine with some sort of paid advanced control library, kind of like Telerik's,

Competing with third-party control vendors isn't our goal. We encourage and support other vendors like Actipro in enriching the Avalonia ecosystem. Our focus remains on improving Avalonia and offering valuable tools, ensuring a healthy and diverse ecosystem.

@MikeCodesDotNET Thanks for keeping us updated! I agree every viable revenue stream should be investigated and this is a great step. I'm glad you aren't siloing various products and services more. My usage of that term was probably too strong in this case.

There is this one, no idea if it works or not.

https://github.com/wieslawsoltes/Dock

There is two, the one mentioned above and: https://github.com/npolyak/NP.Ava.UniDock

Visual Studio already includes a tool like the F12 dev tools for free in the community version for WPF apps.

Visual Studio already includes a tool like the F12 dev tools for free in the community version for WPF apps.

In contrast with Visual Studio, which releases its Community Edition under specific restrictions, we have always offered the entirety of Avalonia completely free to our community. Our objective is to generate sufficient revenue, enabling us to invest robustly in Avalonia's future.

In contrast with Visual Studio, which releases its Community Edition under specific restrictions, w

Indeed, I was just pointing out that it is possible to get similar functionality for free. Although from an individual's point of view there is not much difference between the paid versions and free versions of Visual Studio. Most of the restrictions really only apply to businesses with many employees/lots of revenue and the missing features tend to be fairly advanced/rarely used anyway.

@thevortexcloud Go ahead and try it without a google account and report back. I suspect there is an option for this though and it was just checked as required for some reason.

I just tried it (I did not submit it) and it opens fine. I know some countries have mandated that google require accounts for some things. So it might be a regional thing.

Interesting, you might be right about it being a regional thing. I tried it again on a different browser with no cached page data and it requires a login:

Actually, I also just tried it again on a different browser and also saw it. So I must have just been blocking the popup.

As far as the Pro Tools feature list: is this only for a stand-alone tools app or does this include Avalonia features as well?

It's a stand-alone, totally optional tool.

What does this mean? Is it new controls for Avalonia or allow better UI management of dev tools?

No. It just means a better UI for Dev Tools, to make debugging the visuals of an app easier.

Again, is this only a localized dev tools? Or do you mean accessibility features of Avalonia itself will be behind "pro tools"? If the second, that doesn't sound like a great idea. Localization is a core feature not a nice-to-have tool that those with a budget with be willing to pay for to improve workflows.

It'd just be for debugging localisation and accessibility. We won't be removing features from Avalonia.

Fixed. Try again :)

That worked, thank you!

Probably a one-time payment with major upgrades requiring an upgrade.

Totally agree: with already great F12 tools, who will buy the pro dev tools?
It seems to be a rather very small number of developers, and the higher the price the less sales (a very difficult race).
Maybe people expect the previewer to be free... but the F12 tools would be a perfect addition to be licensed, if enhanced even more.

Regarding increasing the support my suggestion is to change the license of the product to dual license. A gpl or lgpl for free and commercial usages. The big companies try to avoid gpl licenses so they will buy and pay for the commercial one with support. Other companies like Qt are sucessfully using this approach and it works.

I like that this time I am not the only one bringing it up (again). It potentially is about the right timing. Do not prevent too many users from taking on Avalonia but charge the ones that really profit from Avalonia's existence. Everyone profits because it will become better more quickly. And: give people within an enterprise a clear justification for a purchase request. If paying is optional, justifying purchase requests is harder.

@Indomitable, @ilfab - I appreciate your thoughts on licensing. However, a license change is a significant shift and not something we have an appetite for. We must explore all other options before seriously contemplating such a radical change.

Our continued success hinges on a broad, diverse community and ecosystem. If our .NET competitors maintain permissive licenses and we don't, it's reasonable to assume users will gravitate towards inferior technologies. Observations from @JimBobSquarePants indicate that even a license change won't resolve the challenges, as businesses appear to be using ImageSharp against the license terms.

Other companies like Qt are sucessfully using this approach and it works.

Regarding Qt's business model, I'm hazy on the details as it was a long time ago. Still, I recall having a paid license to use Visual Studio before their license alterations. Xamarin followed a similar path, but this isn't a viable option for Avalonia. While we could consider a premium Visual Studio extension, as @ilfab rightly points out, making payment optional complicates justifying purchase requests within enterprises.

We've leaned towards an 'open-core' strategy when exploring our business model. This means Avalonia remains freely accessible and open-source while we develop additional, paid features for those interested. The challenge lies in identifying the right value-adds to focus on initially. Several factors influence this decision, including the resources needed for development, market demand, and the impact on the broader ecosystem. Take 'pro' controls as an example: Leaving room for third-party developers in this area is crucial. Creating our own pro controls risks competing with third-party vendors, with whom we've been working hard to nurture relationships with.

Finally, the role of AvaloniaUI OÜ (the company) is pivotal in the future of Avalonia. As the principal backer, we invested over half a million euros in its development last year. Success will require transitioning to prioritising enterprise usage and understanding our role as an enterprise software vendor. This evolution means prioritising enterprise customers who can afford our products and services. This strategy will enable us to continue substantial investment in the open-source development of Avalonia.

I truly value your insights on these matters. Hearing perspectives that challenge the community's standard views is invaluable. Continue sharing them; we consider each one in our internal discussions.

Great insights, Mike! It also came to my mind that licenses may drive users to the next worse choice. Also, the comparisson with Qt is not 100% right:

• had significant more time and investment from Nokia et al before moving to license
• is relevant beyond UI, hence, is somewhat larger and is one of the few options to make C++ usable
• did have and even stronger USP at the time

However, there could be some learning. For licensing they also needed iterative enforcements to make companies buy licenses which may consume quite some effort from Qt company. They have created a decent ecosystem with KDAB at al to allow other business models like teaching and consulting which drove success.

So, I see good points to keep an open-core strategy. Minimizing unpaid tool support may be feasable. While a basic previewer is crucial for open-core a smart suite of advanced previewer, F12 tools, profiling..., just everything that makes it less risk could be a thing. Problem is see: you could very well live without that's why licenses would still need to be a no-brainer. Example: I use VS 2022 Enterprise by default but have Rider as the tool to try out stuff on Linux. Expensing the ~300 EUR per year is under the radar. Same for my beloved SmartGit. 100 EUR per year for just the best Git client in the world is a no-brainer...

Question is, would that be the case for others as well and would that lead to enough develpers to sign up for such licenses.

@grokys makes a valid point: hot-reload, a resource-intensive feature, is either a premium offering or unlikely to materialise. Our commitment to transparency means confronting these difficult realities openly.

Implementing hot-reload demands substantial effort – an estimated man-year of development. Given our team's limited size, allocating resources for a year on a feature that doesn't directly enhance revenue is impractical.

Our priority is ensuring Avalonia's ongoing development, necessitating tough choices. The persistent interest in hot-reload and calls for it to be free reinforces our decision to include it as part of a paid offering. This approach aligns with our need to generate revenue while acknowledging the feature's value to our users.

@MikeCodesDotNET One this I'd like to add to this is that a feature that starts as a paid offering does not need to remain there indefinitely. Something I have seen work well with Visual Studio is how they move features from the premium and enterprise versions down into the community edition over time.
There is nothing wrong with building hot-reload, and charging those willing to pay for it now until you have made back the costs, plus some, of developing the feature.
Given that now days this is expected as part of the base package, once the costs have been re-cooped, move it into the base package.
This approach encourages faster development of the feature for those willing to pay for it, and ultimately those not willing to pay for it may still get it at some point, likely sooner than they would have if it was never going to be a paid feature.

@RusselRillema, your suggestion merits consideration, but I'm inclined to keep certain features as paid, while continuously adding more value to our paid users.

Our situation is distinct from Visual Studio, which enjoys a revenue of about $20 million per month. I assure you, if we ever approach such figures, we'll shift towards making features free by default, reflecting our success and commitment to the community.

Don't forget that if Vue has 30x more sponsor, it's mainly because it's easily 30x more popular than Avalonia right now, not the contrary.

That's hard to judge but currently vue.js has 42.5k GitHub stars and Avalonia has 22.6k GitHub stars - so by this metric vue.js is only 2x more popular.

Of course the web ecosystem is much larger than the .NET ecosystem so this probably doesn't reflect reality, but I also suspect that part of the issue is that the web ecosystem is more used to funding OSS projects than the .NET ecosystem who expect everything to be provided for free by a multi-billion dollar corporation.

I dont know but I find this hot reload thing here much overrated. Yes, it can help in certain aspects but very often you still need to change ViewModel or similar. Given the effort for such a thing and given the provided alternatives like powerful previewer I would not invest into that. Personally I believe its not a relevant benefit having it at all.

To avoid converters, we can extend Bindings syntax, allowing chaining method calls there. As it was done in UWP x:Bind. For example.

Ok. Have not used that. I guess where it gets on your nerves is when you want Visible = (myEnum == MyEnum.MyValue) or so. So, really short ones. If there was a way to do that in XAML, great. For more complex things the converter "workaround" is not a deal breaker and then after some time, you typically have your set of converters implemented, right?

f there was a way to do that in XAML

You sort of can? You can do this https://docs.avaloniaui.net/docs/reference/styles/style-selector-syntax#by-property-match

Not sure if it works with enums though.

Ok. Styles would work. Not to have to use a Style but just setting the property sometimes would be less texty but seems good enough. Anyhow, as always kind of getting into details where we wanted to find "features" enterprise users would pay for :-)

c# markup has always seemed pointless to me, xaml is much easier to code with IMHO

We had ideas to share Avalonia dev tools with XPF, yes. It likely won't support WPF though.

But do you have an indication of how much you guys will ask for?

We are trying to estimate a good pricing rn. Please fill the waiting list form, it asks for the price you would think is okay for such package. The more feedback we get, the better we can estimate a good price level.

#14097 (reply in thread)

@florianwachs, discussing the .NET Foundation's effectiveness could fill a lengthy thread.

To put it succinctly, as it stands, the Foundation offers no real value to its member projects.

totally agree, it just seems to me that a dotnet "apache" foundation would be helpful. I really think your best bet is a paid pro devtool. i hope enough people sign up for the waitlist. I have no current avalonia projects but I would definitely get a license. We need a flutter competitor in the dotnet world, especially when running in the WASM world.

I would also get licenses for each UI devolper in our group