Paying for government technical debt relief

There has been a lot of silly talk lately about “technical debt” - the alleged cost of rewriting obsolete systems, and the continuing use Web1. I have mortgaged my house to fund a largely Web1-based service, so I have plenty of skin in this game which I don’t regret. Because I must say the recent criticisms leveled at Xojo Inc. are largely unjustified, and I have not been in any way contacted to write this:

Let’s look at a worst case: Suppose I built an app called “StarPos” to calculate the position of any celestial body in the night sky – in history, and into the future, from any earthly location. As such, StarPos would be the hypothetical maximum collector of technical debt possible from a dev tool perspective, because the business process never changes to make the app obsolete by itself. Let us also assume the maximum technical debt possible by building StarPos first as a desktop app, then migrating it to Web 1 and now we are at the beginning of Web2, at least according to Xojo Inc. Let us also suppose StarPos is highly graphical for a Web app, and also uses containers and grids for data in a complex way so as to very tightly bind StarPos to Web 1’s UX. So how are we going with technical debt for me as the hypothetical developer of StarPos?

Some historical perspective will help us answer: The migration from desktop to web would have been expensive but that technical debt was due to an industry-wide shake-up – mass migration from desktop APIs to HTML5. Indeed, there was nothing compelling me to make this change to StarPos from a technical standpoint, being driven by user expectations / device market growth not desktop obsolescence. In that case, Xojo decreased my ‘debt’ as there would have arguably been more commonality between desktop and web versions than with any other dev tool: For example, had I hypothetically gone with another BASIC variant, say Active Server Pages, I would have been further indebtedby the subsequent move to say VB.NET along the way.

Xojo on the other hand, updated its Web dev tool much much later to Web1 API 2.0, thus delaying the debt; and the technical debt accrued was also much much less, since Web1’s architecture didn’t change and the language was mostly unchanged. So far, so good. Now we arrive at Web 2. On the one hand, Xojo Web1 to Web2 seems much easier by comparison than a move from say VB.NET (now being depreciated) to a Java variant for example. But on the other hand, it’s unlikely the UX of StarPos can be moved from Web1 to Web2. So where are we now in relation to the alleged worst-case technical debt for me as the hypothetical developer of StarPos?

Apart from memory leaks in Web1 which I will come back to, the alleged technical debt caused by Web1 is not real at all. That’s because StarPos can be compiled for Linux or Windows which isn’t as bound to hardware updates as Apple’s offerings. This means the main contingency is that browser Web standards will be discontinued sometime in the future. How likely is that with HTML5 without plenty of notice? But let’s say HTML5 one day gets the axe. This would mainly affect the UX aspect of StarPos, not the business logic, which could be migrated to Web2 and accessed by Web1 as a web service. So there is no actual technical debt with StarPos posed by external factors yet, only a remote contingency which may or may not materialise in the future. After all, HTML 1.1 from the 1990’s still works fine today, and HTML5 is as entrenched today as 1.1 was back then. So I regard the contingent technical debt of HTML5 as negligible, as I regard the risk that the Linux APIs which Web1 runs on suddenly going away as negligible too.

There is however, technical debt of another kind, created by user expectations outside of Web1 itself, such as there was with the move from desktop to the Web. I’m speaking of the regulatory environment of some countries that has changed since Web1 was created:

As I pointed out in another post, the United States fosters innovation with a caveat emptor (let the buyer beware) approach. Software can be licenced ‘AS IS’ for example. My non-lawyer reading of Xojo’s licence, when taken together with statements made at inducing me to buy it for over a decade, is that it’s much more than an ‘AS IS’ licence. On my reading, we have a right to one year of future releases too for example.

However, the user expectation coming out of the German regulatory environment is very extreme. This is said to have the effect on some users, of advancing technical indebtedness by making remotely contingent liabilities, such as the abandonment of Web standards, manifest immediately by operation of law. So according to our German friends, if Web1 is not actively supported into the future, some offerings based on Web1 must soon be axed for some end users in Germany to achieve regulatory compliance. But how realistic is such an expectation of eternal life for older releases for as little as $299/year or $699/year, while still being entitled to newer developments too? Must the world stop for Germany?

Regardless, let us now unreasonably apply an apparently strict German law to StarPos as the worst of all worst cases, and compare this with another BASIC language variant. Sadly, the UX must be redone in something else, probably Java, since the law apparently requires compliance within a relatively short time. So regrettably, we must act now. Yet all is not lost, since the business logic will be relatively cheaply migrated to Web 2. Yes the affected devs will have to invest big in unit testing, but they would have to do this and probably more besides, if forced to migrate entirely to Java – plus train more staff to learn to use another tool too. For if we accept this externally imposed technical debt will inevitably apply also to VB.NET devs, Xojo devs are far better off IMHO, with the business logic ported to Web2 on Linux. I say realistically, Xojo still comes out on top even in tough segments of the German market. In fact, looking over the hypothetical lifetime of StarPos from the 1990’s, we are way way ahead in terms of technical debt having developed with RB/Xojo.

My own regulatory situation is different. My company is required by statute to guarantee merchantable quality, fitness for purpose and delivery within a reasonable time, as am I. There are no exceptions. Not only that, but whereas the the U.S. consumer laws regulate some aspects of a contract, our laws regulate a person’s entire business conduct! Fortunately, the law here is commercially equitable in what is regarded as merchantable quality, and our terms of service define what they are fit for. So although I would like Xojo Inc. to assume more of our technical debt caused by such national and state government-mandated user expectations, I’m under no illusion that they should or even could for no extra charge.

How much government-imposed technical debt should we ask Xojo Inc. to take on our behalf? This of course depends on how much we are prepared to pay. I am all for emergency fixes, such as in the unlikely event of an incompatible HTML5 standards modification, and for essential maintenance such as memory leaks. We can argue off topic if some fixes should be free of extra charge – that is not what the Xojo licence says. We can also argue off topic there should have been a transition of years from Web1 to Web2 if indeed a transition has to be made, again outside the licence. These are wonderful points I agree, but they don’t solve the problem, and are irrelevant – we test the version we paid for before we paid for it and there was no pressure to pay. Yet this arrangement is insufficient for some users, especially those in highly regulated markets who need more for the tool to be viable.

So I say there should be a budget coming from a new Web1 maintenance revenue stream for Xojo Inc. with votes for the most important fixes given through Xojo feedback. This would actually solve the problem, whereas all the winging I’ve read can only achieve nothing. In the end, it all boils down to the balance of convenience and cost, as all product features do. I believe one thing that sways the balance for Xojo Inc. to be more involved is the comparative ease of making hot-fixes for Web1, compared with the comparative difficulty for devs required to rapidly refactor customer code as is otherwise mandated by law in some markets. Or reboot servers to refresh leaky memory. There is also the financial contribution these higher-regulation markets have made to Xojo Inc.’s revenues over the years, and the need to meet their aspirations for this to continue.

Of course a maintenance scheme for Web1 would also mean people like me all over the world wouldn’t have to explain all this to potential investors. However, an investor who can’t understand it probably shouldn’t invest in software at all, since un-knowledgeable investors often hurt their investments when the going gets tough. I trust we are not so silly as to do that.

While I skimmed through this post, I take it that this applies the the EU?

I’m in the USA but still like to know what is going on around the globe in the tech field

No I’m in Australia. The EU have their own regs, very tight in some cases. I’ll make a terrible generalisation not always true by saying Australian law tends to prohibit misconduct, whereas EU law tends to mandate perceived correct conduct.

Fair enough,
I will revisit this post and read in full this evening when I have time

Might add my reference to Active Server Pages predates Xojo Web so it’s not applicable. On the other hand, any transition from VB to a Java variant would involve a total rewrite, whereas the language of Web1 and Web2 is more or less the same.

1 Like

If you talk about other technologies, you cant really compare them based on an arbitrary hipotetical date, to replace them, compare them with real tiframes after the last release. Lets take a real example, VB, 1,2,3,4,5 and the last release, VB6 in 1998, it was announced that it will be the last one and it will be a new technology, .Net

Ok, now compare Apples to Apples, The IDE, the Runtimes, the tools, those got updates and bugfixes FOR A DECADE even when .Net was already on the market.

ASP? sure, the last release was released in November 2000, support for windows 7 was droped LAST YEAR, windows 8, 10 and server still had support for them…

Xojo in 2020: Gues what, Web 1.0 is dead, no more bug fixes. By the way web 1.0 is totally different so star rewriting…

THAT is the actuall “silly talk” technical debt: NOT about “government-imposed” but using a tool that in a Whim can deprecate a whole target with ZERO extended support for it and a replacement that needs a rewrite.

.Net 5+ is as little as FREE and those have at least 18 months of support, bug fixes, patches, etc., upgrading to the new version don’t require a complete rewrite…


There were no updates of any note to VB after 1998 that I recall and it was my main tool back then.
VB > VB.NET was a complete rewrite because VB was a windows API wrapper while VB.NET was a CLI/.NET framwwork language. There was almost no possibility of porting only refactoring. In fact I would say VB.NET has more in common with C# than VB.
Web1 and Web2 for non UX code is only a port, tedious and not very difficult. And like VB6, there are no incompatibilities that have broken Web1 that would force such a port for technical reasons.
I agree with you there should be more support for Web1, which was my point after all.
VB1 was more of a proof of concept IMHO so Devs really only had 5.5 good years with the tool before development was canned with nowhere for their code to go. .NET wasn’t free because in the main, people were effectively bound to Windows licences, and their customers too. Xojo’s value proposition is the opposite, so the price is really worth it if you take advantage of its capabilities.
You are right about the invalidity of picking dates though. VB6 development stopped in 1998 and VB.NET 1.0 shipped in 2004. So to cover all those lost years analogies will have to do.


How could you work with VB and not install the updates. Microsoft released updates for 10 years, included bug fixes, security fixes and a few little extended features, like new connectors for databases. Even after 2008, Microsoft published various security patches.

I mostly left VB in 1999 and started to work with VBA over RDP since I didn’t trust ActiveX except on Intranets. I count plugging ActiveX as a Windows update really. Interestingly Java Applets proved to be perfect vectors for attacking VMs. Xojo Web on HTML turned out to be a superior architecture (controlling the UI from the server through AJAX as it then was) to all that and still is.

But if you want to compare apples with apples let’s not forget how VBXs were dumped
for OCXs to support Win9x. Broke lots of UIs if your plug-in vendor went broke during Windows95 delays.

However I think a major factor why they kept plugging the holes even to 2012 was because they had government and corporate accounts. Likewise Devs who have that with Xojo Web are the first to feel pain. Years of this meant the leakage of customers to Java over time was fairly horrendous.

Actually, VB.NET 1.0 shipped in 2002 after VB6 development was shuttered in 1998. That was a long time between drinks!

Eric, could you fix the typo in the title? It’s “relief” …

1 Like

I would be relieved to :slight_smile: but it seems there’s no way.

I have corrected the title for you.

1 Like


This is the part, which turns Xojo Web 1 into technical debt.

Let’s play a game: let us compare this to .NET:

  • Microsoft announces tomorrow, that .NET is discontinued.
  • The new Framework is out now.
  • The new Framework is not production ready, it is more a preview or an alpha release.
  • It will take a year to bring the new Framework to a stable state as .NET was yesterday.
  • There was no announcement about this abandonment of .NET in advance. Only, that there will be a new Framework someday and you will be kind of able to convert your old projects.
  • But you wont be able to convert old projects automatically. You can only rewrite it with a huge amount of work.
  • You won’t be able to develop in .NET in newer Visual Studio versions from now on.
  • The new Framework misses crucial features, such as events, controls or functionalities. They also won’t come back eventually.
  • Known bugs in .NET wont be fixed anymore.
  • If in .NET, which is still vastly used, new bugs are found, than they wont be fixed. Also no security issues.
  • Microsoft tells you: don’t use the new framework until it is stable, what will take a year.
  • Microsoft also tells you to still use .NET since it will “technically work for years to come”. It still will not be maintained anymore.

Now replace “Microsoft” with “Xojo” and “.NET” with “Web 1”.

Can you guys imagine how the world had react if Microsoft has done something like that?

THAT ist the issue.

1 Like

The “government thing” you mentioned is from my perspective not really a big thing. 80% of our customers are german authorities and they don’t care about the technical basement of the software as long it is stable and can stick around for the next 5-10 years.

We are not confident that Web 1 will be usable (to deploy and to develop with) for the next couple of years. This turns Xojo Web 1 into technical debt. And it scratches on the surface of Xojo itself to become technical debt, since what happens once for Web 1, can also happen to other parts of the Xojo language.

(completely ignoring the fact that you’ll still have to find developers which want to work with an discontinued tool).

1 Like

I get the bit about security and critical fixes which I think needs to be addressed by Xojo Inc. Not enough warning :warning: is also a legitimate complaint. Also your analogy is technically more accurate than mine in the sense that Web1 and Web2 are frameworks not languages. But therein lies the problem with what you are saying:

If a programming tool maker discontinues your language, as in the case of VB6 and VB.NET, what good is the framework to you (COM or CLI) which you accessed through your language? The switch to C# (which I regard as a Java variant in terms of syntax) from VB.NET, being a change in language, is non trivial, all pain, and zero gain. Because after all that expensive refactoring, there’s no new framework just the same old one. Not only that, but in the case of Xojo, only the UX would need refactoring IF Web2 isn’t suitable when it’s time to update an app, since business logic can be ported to a Web2 web service in that case or kept where it is on Web1.

So there have been two language discontinuations for BASIC programmers on Microsoft verses one mild update (API1>API2) on Xojo plus a framework has been frozen (for now). You’re still way ahead with Xojo under your analogy which I agree is valid. There’s just no comparison.

As for developers, I imagine there will be plenty of VB.NET developers willing to retrain on Xojo (an easy transition I can attest) for years to come!

:roll_eyes: Again in the case of VB6, it was discontinued BUT NOT ABANDONED. The tool itself had 6 Service packs in 10 years and and multiple security fixes after that. Also the runtimes are kept updated to work with the latest OS, to this day, 23 years later, vb6 apps are still running in the latest windows 10 and windows server.

what good? 23 years later Developpers still can run VB6 IDE, mantain old proyects, and have their apps running. THAT is good support and caring for their customers.

Yes Microsoft didn’t abandon VB6 Devs altogether and made sure it still worked as usual. I would like to see Xojo Inc. do likewise.

Yet discontinuing an application development language dialect not once but twice - with years waiting for the first replacement and ultimately no replacement? A devs career will probably recover but eventually having to completely rewrite and test business logic is hugely expensive for customers and risky too.

Xojo Inc. isn’t doing that. The German government is to some extent regarding some projects. That’s my point.

May I also point out that VB6 code is exclusive to Windows, so customers would not upgrade Windows if their applications didn’t work. So Microsoft was in a bit of a bind. The usual Linux long term support is only 5 years I think.