Quantcast
Channel: Recent Threads — Xamarin Community Forums
Viewing all articles
Browse latest Browse all 204402

Xamarin backtracking on license terms - a business risk

$
0
0

I have read the forums and it appears that was an abrupt change in licensing terms made around Nov 2013 where Xamarin blocked distribution of applications for all licensees unless the licensee would continue to pay the full original price every year in perpetuity. Due to the outrage that this caused, the Xamarin team later backtracked on this decision, but only partially. The current policy, as of writing, is economically speaking a rent model and Xamarin reserves the right to change the terms, i.e. what this rent would be, unilaterally, without recourse for the user, apart from abandoning the platform, which could entail. Apparently old users were grandfathered into the new model with their older more permissive terms, but new users do not get these better terms. So evidently the licensing terms have worsened.

Now let's look at how the mobile world works. New operating systems and API:s are released with breakneck speed. iOS gets major updates at least once per year and Android major versions also come out from time to time. As a developer, staying in business practically requires being up to date with the latest API:s as a given. Security vulnerabilities have been found and fixed on both iOS and Android. If a developer decided to not renew the Xamarin license, they would thus be taking on a business risk: "I take the risk that there will be no major update or bug found, or security vulnerability, requiring me to pay the annual Xamarin fee to have it fixed". However, the situation is asymmetric, as the developer may have liabilities for software it has already published, whereas Xamarin has no liabilities for developer's software issues, even though the Xamarin platform is part of the published software. Software in the wild cannot simply be withdrawn. There may be legal liabilities for the publisher of the software. If the publisher cannot patch the software correctly without using the latest binaries, there could be legal risks for the publisher. Often, acting quickly is key to avoid legal issues. It could have to do with privacy issues, i.e. leaking of user data and many other things. It may not even be Xamarin's "fault". So, clearly, if the Xamarin user does not constantly upgrade, they are taking a legal risk, particularly if they face economic difficulties down the road, which is a risk they face anyway. Publishing an application is practically a one-way street. If an application is published, it could be used for years, even if withdrawn from app stores. So simply withdrawing an application would not per definition eliminate this liability. This risk would grow as the number of users and diversity of target platform grows. Consider the possibility that there could be hundreds of unpatched Xamarin apps in the wild for which developers decided not to renew the license, and hence do not have the tooling and rights to patch them. The problem would only be amplified in the future. Hence, the security model does not scale. The platform will thus transform to a honey pot for attacks and become more attractive to hackers and governments over time who have plenty of resources at their disposal to reverse engineer and identify vulnerabilities. This could happen years after an application was released and a developer went out of business. This is a well known fact and a basic dynamic of security, or the lack of it. Many warn that this may happen to Windows XP after support has ended. The reason that Microsoft kept patching XP for years for free is a testament to how important this is. In effect, the current model puts both Xamarin developers and Xamarin-based application end users at risk, and they should be made aware of that, which they are not. This by itself is also a reputation risk.

The middle ground would be to attempt to compromise, say, renewing every second year. This would bring the running cost down by 50%. However, there is a risk that security updates coming in later during the year would be missed due to this, so the business would be exposed to a risk in this case.

Let's now look at the flipside. Xamarin may on its sole discretion change licensing fees. For example, they just started offering a discount to MSDN members for licenses. This is part of the way that business is run, discounts come and go. However, the issue for the developer is that they would still have to renew these licenses to get fixes and features. As the developer gradually increase their code base that targets Xamarin public API:s, they are raising the stake and are more vulnerable to renewal price sticker shocks. Hence, for a developer, the price risk keeps increasing as the code base grows. A developer may hedge the risk by putting the back end on the server, or look at other cross platform frameworks, but server side logic can not solve all challenges and if the core is written in C#, the fallback route of moving to Objective C and Java is blocked unless starting over. This strengthens Xamarin's bargaining position, weakening the developer's position again, amplifying their risk.

Third, there is a management risk, as demonstrated by the previous backtracking. If the Xamarin management/ownership structure remains unchanged, this risk is probably still there. The change itself is the risk, not the outcome. There could be other plans in the works which have not been announced.

My concern is that there is no way to get around the business risks with the platform due to the licensing model. We either have: 1) Legal risks of published unpatched software in the wild - if not renewing 2) License renewal price increase risk - if renewing 3) Managerial risk of changing terms - in both cases

The only way I could see to reduce or eliminate these business risk for Xamarin users would be to consider:

  1. Charge all costs upfront and make the license truly perpetual, including all significant upgrades, notably all hotfixes and security patches that would put developers at legal risk (but not necessarily new features). Xamarin users would have to pay for new features, which is reasonable as it requires new investment. Whatever the fee is, it should be well known and fixed, no change, contractually binding, ever. If it requires doubling the price, it should be made clear. This appears to be by far the best model of all and is more line with other software packages and tooling.

  2. Charge a small symbolic maintenance fee for minor upgrades (not major) that also adds some nice new features which would be a small amount to feel better about paying, considering that the bug fixes were actually defects, that the customer did not know about and they were discovered later on. Charging a fee for just fixing bugs looks bad. Every experienced developer knows that rapidly developing software will have bugs. The cost for the user to download the patch is already a price paid by the user as this takes valuable time away from development, including the risk of going unpatched, even if patching is free and patching is cheap for the user. A platform is by nature open, it can be extended indefinitely, hence, the scope cannot and should not be constrained, hence this issue will not cease to exist, ever. There is also information asymmetry here, if there is a lack of trust it is easy to perceive these bugs as a conspiracy just to force users paying them to be fixed.

  3. If an annual license fee should be charged after purchase for everything just to have the right to use the tool chain, it should be in line with what other key parts of the tool chain cost, such as annual fees for Apple Developer Program which is 99 USD. Charging 99 USD annually would thus be sensible.

  4. To reduce the appearance of rentier model, charge smaller fees for upgrades, e.g. to add iOS version 8, pay 25% of price, not the entire sticker again.

Basically my main concern is not really the price. It is the risk to the business that cannot be avoided and the desire to avoid introducing another business risk to worry about on a daily basis. The lack of ownership of the license is really the most concerning part because it amounts to building a business based on a rentier model for a core dependency. I have seen the justification in the forum made that users wanted more support after purchase. But this is not true for all users. Many users would accept a community model, and users who demand more extensive support can pay for this separately which is a very common model. Further, the need for support should fall over time. What happens now is that the less demanding and paying users who do not need for support are subsidizing the users who need support. Particularly, users renewing for many years who rarely or never use support services would be heavily subsidizing new users. The problem is not evident but will grow as the platform matures and asymptotically approaches feature complete and users start to ask why they still keep paying. There is no guarantee that any new features will be delivered that adds any new significant value. Hence, the NPV, or expected value of the future investment decision/renewal fee cost cannot be reliably determined. This is a business risk and makes little economic sense for the self-supporting users. The probability of an unknown entirely new mobile platform displacing Android or iOS as a major player, for which there is no C# tooling, at this point is rather low.

Once again, the point of this post is not to complain about the price, it is about the business risks imposed by the current pricing structure by perpetual annual variable charges. Regardless of the price, unless there is a perpetual license with free fixes, the platform will add business risk to the developer. Features do not have to be free and the original sticker price can be higher, as long as the risks are reduced.

If there are any other ways to reduce/hedge these risks, or any parts of the Xamarin terms are interpreted incorrectly in this post, please comment.

Thank you.


Viewing all articles
Browse latest Browse all 204402

Trending Articles