XPF Indie License - Request for feedback

[MikeCodesDotNET]

We are exploring the possibility of introducing a new tier for Avalonia XPF that is specifically tailored to the needs of independent developers.

We are enlisting your valuable input to gauge the optimal pricing for this potential offering.

Key features of the proposed indie tier include:

• Per-App License: Each subscription would be linked to a single application.
• All-Platform Inclusion: Licenses would include support for all current and future supported platforms—currently, Windows, macOS and Linux. We expect iOS, Android and WASM to be ready for testing later this year.
• Community Support: We plan to provide access to a dedicated community forum for community assistance and knowledge sharing.
• Yearly Subscription Model: The tier would operate on an annual subscription basis. Applications developed under this subscription would continue to function indefinitely. However, ongoing app development and updates would require an active subscription.
• Hybrid XPF: The same price would adopted for our indie tier of Hybrid XPF, enabling developers to consume WPF components in their Avalonia applications.

We are still in the exploratory phase and have yet to finalise this tier's launch date or specific details. It is primarily designed for individual developers rather than companies.

Your feedback is critical! Considering its features and limitations, please share your thoughts on an acceptable price range for this tier. Your input will directly impact our decision-making process and help us better cater to the needs of indie developers.

For some additional context. The Indie version of Xamarin was $400 per platform, per year. For all three platforms (iOS, Android and macOS), developers paid $1200 a year. This came with the limitation of being unable to use Visual Studio.

We highly encourage you to take a moment to fill out our brief questionnaire.
As always, we'll do our best to be transparent about our thinking and answer any questions.

[DevJohnC]

if I allow a yearly subscription to lapse do I maintain access to any of the software I've been paying for up to the point or is it gone until I re-up the subscription?

[MikeCodesDotNET]

You would need an active subscription to continue to build your app with XPF. If your subscription has lapsed, you'll be unable to build or use any versions of XPF. We are following a model similar to Xamarin, which required an active subscription for building.

[xmaxrayx]

it doesn't even support Linux for indie so what's the point of it? id rather use Uno lmao

[thevortexcloud]

I like the general idea of this but it would be nice to not have to buy a new license every time for every app, that could get expensive fairly quickly, especially since I am guessing each license would have their own subscription too. Perhaps either allowing unlimited apps or allowing say: 5 apps per license would be more accessible?

[thevortexcloud]

Well this is meant to be an "indie" license. Which to me means it's targeted at individual developers, not businesses. Most people who fit into that category are probably not making much money/any from their apps in the first place. As such they likely can't afford to be paying for an expensive yearly subscription for all their apps. It makes sense for large businesses which likely can afford it though. This is also why Jetbrains has completely different pricing for their individual subscriptions compared to their business ones (Rider for example is more than double the price for a company). Despite it being the same product. But I guess it all hinges on how much you guys decide to charge for an individual XPF license.

[thevortexcloud]

The major obstacle that prevents us from embracing per-seat licensing is preventing the misuse of a single license by an entire team. Our experience shows that companies often underreport developer numbers to cut costs, a trend observed in our support agreements.

I agree that this is a problem. You also make valid points that enforcement is difficult. So I guess, my question is: Is the indie license targeted at businesses or individuals?

[MikeCodesDotNET]

I agree that this is a problem. You also make valid points that enforcement is difficult. So I guess, my question is: Is the indie license targeted at businesses or individuals?

The indie license, although aimed at individual developers, often attracts interest from companies. This is a pattern I've noticed from my experience at Xamarin, where developers from large companies would use the indie tier, not realising it was intended for smaller developers. Those companies were happy to force their developers to use Xamarin Studio and have no support to save just $600 per developer.

For those unable to afford XPF, I'd suggest using Avalonia, which is free.

Regarding pricing and generosity, once our revenue surpasses $100 million, we'll consider emulating JetBrains' approach to their offerings.

[robloo]

Note: I accidently put this in the wrong thread and can move it if needed.

There seems to be a significant gap between Avalonia's needs and the community's willingness to support us.

Given the current sentiment, it's becoming increasingly likely that we will not pursue Pro Dev Tools or make XPF accessible to indie developers.

It's clear that there's resistance to paying. Our goal is to secure Avalonia's future, ensuring the core team can continue their work in the coming years, not pursue extravagant luxuries.

I just read this full thread and the above caught me by surprise. It's too early to throw in the towel. The comment seems out of place and prematurely shuts down discussion before reaching any possible compromises. This post is two days old.

Throwing out numbers like 100 million in revenue also seems excessive considering there are technical solutions (registration/authorization) that can resolve your major concerns with Rider's licensing model. It's more work to setup for sure but every company will need this sort of system at some point anyway.

Other main points to consider:

1. Any sale you would not otherwise make is a good sale. It's clear XPF isn't quite hitting the sweet spot with small devs and it seems there is opportunity for further conversation and compromise (hence this discussion).
2. As mentioned, indie licenses are not really a major revenue stream. They are, however, a vanguard for a few very important things:
   • Generating marketing, name and wider community recognition. If individuals can play around with the software, write blogs and generate articles you are getting more value than you realize. XPF is NOT widely known.
   • Most companies don't have R&D budgets in time/expense. They will go only with proven technology. You need individuals to prove technology on their own time to sell it internally to their management.
   • You are avoiding some criticism (negative brand sentiment) by allowing a way for those that want to use XPF to do so when they otherwise couldn't afford it
3. No one will ever be fully supportive of anything. Don't let one or two saying no cancel a product -- that said, I don't see all the survey data. But it's a small community and not many likely even know about the surveys yet.
4. There are proven models that already work in this case. I wouldn't dismiss them so easily (Rider).
5. If companies abusing an indie license is a major concern an authentication system is needed like most other paid software has these days. I've commented more elsewhere on this.
6. The primary goal right now should just be to grow safely. If done correctly you aren't loosing any money from an indie license. The types of people that would go for this license are NOT the same market that will pay thousands for the other licenses. As you said it needs to be enforced. I think that can be done with registration/authorization.
7. There are also good reasons most companies choose to do business only with other companies (listed in bullets below). That said, I think if Avalonia wants to grow at maximum speed you can leave nothing on the table. Dropping Pro Dev Tools and XPF for individuals without first testing the waters seems like a strategic mistake. Companies will pick dev tools up too.
   • Other companies are accustomed to pay for services and have a budget to do so. They can better realize the need as they are selling things themselves.
   • Companies generally have more tempered expectations and are easier to work with
   • Companies are less vocal in criticism
   • Focusing resources on a few big partners rather than many small partners is simply easier to manage
8. The comparisons to other companies don't necessarily apply here 1-to-1 as they took a different road at this point in their life. Most received outside investment and just focused on maximum growth. This point may be in your favor.

The Avalonia team sees way more data than I do. However, I can give some outside perspective.

[xmaxrayx]

The major obstacle that prevents us from embracing per-seat licensing is preventing the misuse of a single license by an entire team. Our experience shows that companies often underreport developer numbers to cut costs, a trend observed in our support agreements.

I agree that this is a problem. You also make valid points that enforcement is difficult. So I guess, my question is: Is the indie license targeted at businesses or individuals?

Ritch induvial people

[cirrusone]

I don't have Gmail account so cannot complete questionnaire.

Most control libraries have perpetual product licenses which are locked to the specific versions (these often are limited to certain versions of .NET also), I would expect to be able to build on same version after subscription ended. If I can't then no purchase. Pricing, I wouldn't pay more than £500 assuming I'm not locked out after 1 year and applies to same licence terms as control library (perpetual and multiple apps).

If you produced some Avalonia controls I would pay you £1000-£1500 per annum if you had the following controls

i/ cross platform browser
ii/ performant grid with Excel-like filtering
iii/ multi viewport docking
iv/ property grid control
v/ theme designer
vi/ data filter control

[marcosgerene]

Given the current sentiment, it's becoming increasingly likely that we will not pursue Pro Dev Tools or make XPF accessible to indie developers.

Pro Dev Tools and XPF are completely different products in this discussion. Without those tools, I would be able to keep my project maintenance (harder, but possible). Without XPF it is not possible. The argument above about being a "hostage" does not apply to Pro Dev Tools.

Going deeper, Pro Dev Tools is a way to make my Avalonia project more productive.
XPF is a way to not use Avalonia but still on WPF (I see it as a "WPF+").

It's clear that there's resistance to paying. Our goal is to secure Avalonia's future, ensuring the core team can continue their work in the coming years, not pursue extravagant luxuries.

You asked for feedback on XPF to indie devs. Community (till now, it can change, of course) does not see it as a good idea.

[DevJohnC]

There seems to be a significant gap between Avalonia's needs and the community's willingness to support us.

Given the current sentiment, it's becoming increasingly likely that we will not pursue Pro Dev Tools or make XPF accessible to indie developers.

It's clear that there's resistance to paying. Our goal is to secure Avalonia's future, ensuring the core team can continue their work in the coming years, not pursue extravagant luxuries.

This seems disingenuous; developers are in here expressing real concerns with the proposed licensing model and it's not being addressed but instead you take this stance. A strange message to send to the people most engaged with your product, who are telling you what they would pay for.

[marcosgerene]

@DevJohnC I prefer to take this as a poor choice of words.

The idea behind this is to have full-time devs on Avalonia, which is a breakthrough in the project's future.

To the facts:
There is no such thing as a free lunch.
XPF once build is not allowed after subscription makes no sense to indie devs.

[thevortexcloud]

It's clear that there's resistance to paying.

Well that's just false. I have made it clear multiple times that I am not against paying for it. I am just against your current proposed monetisation model. You so far however have do not seem to be interested in pursing in any other model. Instead whenever I or anybody else propose literally anything else with some kind of example of some other successful company your response seems to be "we can consider that when we are making $x", which if I am being honest is a super weird way to run a company.

Making subscriptions optional and selling these products as perpetually licensed products (much like how you can still buy boxed retail copies of Windows) will make a lot more people happy.

That said, I have less of a problem with how the pro tools would work as that does effectively have a perpetual license.

[MikeCodesDotNET]

You so far however have do not seem to be interested in pursing in any other model.

Your observations on licensing models, which reference companies vastly larger than ours, highlight a significant disparity. These organisations operate with revenue 1,097 to 145,750,000 times greater than ours, making their strategies less applicable to our stage of growth. As a young (bootstrapped) startup, our needs and capabilities differ considerably from those of these established companies.

Making subscriptions optional

I want to emphasise a crucial point: subscriptions are indeed optional. You can purchase an XPF license today for €4,999, which includes a perpetual license without online checks. These perpetual licenses are platform-specific, contrasting with our proposed indie license encompassing all existing and future platforms. We believe this provides a balanced choice, allowing developers to select the license that best suits their needs and circumstances.

[timunie]

To anyone being afraid to lose ability to build their WPF source, that's not true. Even in the case XPF dies, you can build the WPF at any time. So XPF is only needed to get the Apps running on other devices than Windows. I just asked the team for confirmation about it as I haven't used it on my own.

[DevJohnC]

to be absolutely, 100% clear:

• are you saying projects using XPF will never lose the ability to build/compile?
• or are you saying the WPF, a framework/library maintained by Microsoft, is unaffected by whatever XPF does?

[timunie]

You have a WPF project which you develop. And this is the project you debug and build for Windows whatever tool you like. Then you can build it (the exact same project afaik) with XPF and run that App anywhere. But the WPF source stays untouched from it, so even if you cannot build it with XPF at some point, you can build it with VS for Windows again, but only for Windows as it was before.

[marcosgerene]

@timunie this change the game completely.

[robloo]

My 2 cents is an XPF Indie License should follow what Rider does. It's been mentioned several times and has been pretty successful especially here with Avalonia support.

My understanding of their model is you pay for yearly updates; HOWEVER, if you stop paying you can still use the last update you were allowed to download perpetually. This means you can always build old code but of course you can't use any of the new stuff. This model closely follows the old "retail box" software model while also tying in with subscriptions which more closely track software costs (developer salary never ends, constant income is needed).

So my initial thinking is this is a technical problem -- one that can be solved. Avalonia XPF somehow needs a daemon that can authorize dlls usage on a dev computer. It will authorize up to a certain version of the dlls itself so you can't add a newer version of the dll from somewhere else or guess a new version from the private nuget feed. Such an authorization should be required at first start and then persist for say 1 week allowing for usage without an internet connection before it must be re-authorized.

Now that said, the elephant in the room I haven't seen discussed in the comments above is upstream WPF development is pretty slow. This means devs building an app can buy 1 version and basically never update because there is never any new features or reasons to update.... this isn't quite fair to the Avalonia team which needs to recover upfront costs and a steady stream of income to achieve maximum success. So my current thinking is improving the pricing model is possible -- if upstream WPF development picks up.

---

Edit: I may have a solution

Because XPF is cross-platform work will ALWAYS be required to keep it working on various versions of other OSes (regardless if WPF updates or not). And here might be the key to making this all work for everyone. Have an OS/platform version check within XPF itself that allows running up to N version of the OS/platform. After version N a newer version of XPF is required. This ensures devs will need to pay for updates to keep using it on newer devices. However, they can still use XPF apps as long as the host OS supports that version of the platform. Bottom line Android/iOS OS minimum version requirements for apps will be the synchronization mechanism ensuring the Avalonia team can benefit from paid updates. It also ensures that devs will ALWAYS be able to build old code for the same exact Android/iOS/macOS version (but potentially not a newer one).

[maxkatz6]

Because XPF is cross-platform work will ALWAYS be required to keep it working on various versions of other OSes

One side note to this: Avalonia work will always be required. XPF itself doesn't have much of the platform-specific code. The exception might be our compatibility layer between Win32 apis and Avalonia (i.e. allowing Win32 pinvokes on non-Win platforms), but this is rather a rare case for new OS versions.

Saying this, XPF still has to be updated to use newer Avalonia version that supports newer OS versions. Potentially applying newer OS/Avalonia features to work there as well.

[robloo]

Saying this, XPF still has to be updated to use newer Avalonia version that supports newer OS versions. Potentially applying newer OS/Avalonia features to work there as well.

Yes, I see a few options:

1. Hard-code a maximum OS/platform version in XPF itself (probably best to start)
2. Allow building with the OS/platform tooling up to version N. Then let the host OS decide if platform version N is allowed to run on the OS version
3. Let underlying Avalonia framework changes also drive the need for updates (less control and Avalonia will likely stabilize faster than OS versions)
4. Otherwise, maybe a combination of all

[thevortexcloud]

if you stop paying you can still use the last update you were allowed to download perpetually

Sort of. You gain a perpetual license to the version that you initially paid for. Your subscription lets you download subsequent versions until it expires. Once it expires you can either renew or roll back to the version that was out when you started your plan (the subscription rolls over every year and counts as the start of a new subscription). I can also say the fact that they let you do this is also a major reason I am subscribed Jetbrains customer. Their prices are fair for individuals (including giving discounts for subscribing for multiple years in a row), they add new value to the product, and they provide perpetual licenses.

Hard-code a maximum OS/platform version in XPF itself (probably best to start)

This sounds painful to maintain, especially for Linux. Some distros don't even have version numbers, it's just a perpetual stew of updates. I guess you could limit it to officially supported Avalonia distros but that seems rather limiting.

That said, this still sounds better than the current plan and feels like there is at least some extra value being added by being subscribed. Instead of just paying because you are forced to.

EDIT: Forgot to mention:

say 1 week allowing for usage without an internet connection before it must be re-authorized.

I have a problem with this too. Since it still has the problems of what happens when XPF's licensing servers are are no longer active. EG due to a network/server fault/Avalonia OU going out of business/something else.

[robloo]

I have a problem with this too. Since it still has the problems of what happens when XPF's licensing servers are are no longer active. EG due to a network/server fault/Avalonia OU going out of business/something else.

Unless you have a better idea it sounds like you are asking too much here. We have this requirement with the vast majority of software. However, perhaps its possible to authorize once and never again as long as you don't update XPF. If you update, re-authorize is needed.

[Noemata]

Based on feedback from my existing WPF enterprise customers, there are likely to be a few thousand WPF migration ops out in the wild where companies will pay a significant sum to make these apps cross platform. Beyond that, there is very little. I suggest XPF maximizes the ops that are out there while they last. Such ops are in their twilight years, so best to act fast. That potential 100 million dollar well will run dry before XPF gets to a third of its potential.

In three years or so, without new infusions from Microsoft, WPF will fade away quickly within enterprise. Even worse, the folks that might promote WPF will be retiring en masse starting right about now.

As for indie devs, why blow energy on yet another closed source solution when Avalonia can be extended and improved well beyond what WPF is today? The Avalonia XAML compiler could easily be made more WPF friendly for starters. Creating migration tooling that automates porting is also a viable option that gets you most of the way there. Enterprises are trapped by the WPF control libraries they bought into. That's the real reason they need XPF.