Xojo is technical dept

Off-Topic
1

Hi,

this is the first time I write, cause we usually have a company account without personal informations. However, this time I write because it may be interesting for you guys to.

We are a Hamburg based IT company/ software startup with about 20 developers. A part of our internal tools are build in Xojo, cause a former consultant of us used it to fulfill our contracts. We were never super happy with it. First of all, because no one wanted to go back to the VB days which are gone and what we think is okay. I know, an unpopular opinion here.

While we don’t start new projects in Xojo, we always kept the software which was developed in Xojo maintained. And also, some of us began to like it somehow.

Now we are negotiating with bigger investors to collect a 5M+ funding. We now had three technical due diligence (tdd) and that is story I wanted to tell you.

First response:
One tdd-contractor didn’t know Xojo at all, which is not a good sign, since they are extremely experienced and they do hundrets tdds each year all over the globe. They never had a touchpoint with Xojo. The outcome was, that they like the approach, but they made also some research, talked to Xojo-Users here on the forum (I read the chats).
→ In the end they told the potential investor to implement a second CTO here since it looked like we tend to make bad IT decisions. They said, that the licence, the release modell, the small team of Xojo, the closed source, the bugs and the tiny community is a huge risk and we should redevelop all systems which are currently in Xojo asap.

Second response
The second Investor made the tdd by them self. As they saw that we have internal tools built in Xojo here, they couldn’t hide a smile (honestly). They told us, that they have a list of technologies, which they don’t want to have in their company-portfilio. Xojo was on that list next to Perl, Elm, AppGuyver, Ninox, B4J and such, Smalltalk, Livecode and Filemaker. Reason was the same: Licencing, lack of support, lack of open source and community and dependence from one small company.

Third response
This was the only one, which didn’t told us to instantly rewrite the system, but to plan it’s rewrite within the next 3-5 years.

In every three reports of their technical due diligence, the Xojo system was listed as “technical dept”.

Not because of the language it self or the technology behind. Some of them were even impressed, that Xojo can perform so well in some cases. The reasons were always, that Xojo is to small to be the backbone of companies with the plan to grow to 50+ employees, that the community is to small, that the dependancy is way to high and that the open bugs (I think they get that from the forum here), were to risky.

What do we do now?
We rewrite a working piece of software, because we fear, that it could break our business some day. But not only out of this reason, also because we find no developers using it or even want to use it. And when I search through the forum here, this wouldn’t be the fist case, doesn’t it?

No bad feelings here, Xojo is alright, some of like it very well, but I leave that here, as I think it is interesting for some?

8 Likes
2

An interesting read. Things like this come up from time-to-time here on the forums and elsewhere. Questions as to the longevity of Xojo, the team size, etc.

Longevity
Xojo’s been around practically forever (in terms of modern computing) so I always view the longevity claims as unfounded.

Closed Source
The same evaluations will recommend closed source solutions with far less history, smaller teams and a roughly equal reliance factor. The logic applied just doesn’t impress me. Also consider that Web 2.0 (if that’s what you’re working with) uses a lot of Open Source in the framework.

Team Size
Again, I’m always unimpressed by this factor. Small teams can sometimes behave in a much more dynamic manner due to their size. I always think of it in terms of boating. It’s easier to turn a small boat than a large one.

Again, thank you for sharing.

9 Likes
3

The bug issue is the main problem. Then add the discontinuations. Then add the buggy replacements.

I used to think closed source / small team weren’t actual issues, but now we see the result in real-time.

6 Likes
4

Isn’t that by definition that a start-up uses tools to quickly build something?
As the company grows the prototypes and quickly hacked together solutions get upgraded to systems to last longer. But that should not necessarily involve kicking out Xojo.

If you have a tool that works, you should be happy to use it.
But if it fails and needs to replaced, you can pick another development tool if needed.
I don’t see a reason why you would rewrite it now, while you could build other stuff that you may need more urgent.

And FileMaker in the list is interesting.
Because that is a company with 300-400 people and >100 Million $ revenue. Not small in my opinion.

3 Likes
5

Trying to find good Xojo developers is a challenge. Yes, you can train a developer to use Xojo but there is a learning curve associated with it and in that time they’ll have to learn to do it the Xojo way rather than whatever language they came from (seen this time and time again). The company I’m with has similar issues and we have roughly 9 Xojo developers with 5 of us having 15+ years of Xojo experience.

I was a Xojo consultant for 20 years and while it can do some magic, the small development team (that’s not grown in many years but yet serving more targets) is a concern and it is legitimate concern for a company that depends on the tool. I think you’ve hit the nail on the head with your investors. If no one has heard of Xojo it’s a niche product. It might be a very good product (I tend to think so) but the downsides do not make it attractive to business investors.

8 Likes
6

Closed source is always a killing argument, but then all those companies running SAP are on the wrong path ;-).

Licensing is a different pair of shoes for a growing company. Though I personally think that Xojo is fairly priced, it might easily come “expensive” if you grow. Normally you only grow if you will generate more revenue, but for investors the question is easily reduced to “hey, why throwing all that money into these licenses if we can get alternatives for free”. Especially in your case, where we are talking about internal tools “only”.

Finding good Xojo developers is really difficult as Bob mentioned, and finding cheap but good Xojo developers probably impossible, especially in the way investors are thinking and screening the market. I’m not even talking about fiverr.com, but if an investor is checking the market for off-shoring the Xojo development they will quickly realize how small (or in-existent) this market is.

7

“They said, that the licence, the release modell, the small team of Xojo, the closed source, the bugs and the tiny community is a huge risk and we should redevelop all systems which are currently in Xojo asap.”

What longevity claims? Anyway, being here forever but still beingTiny is not really a good sign.

But all the bugs and problems are in the NOT open source part of the software, so


Only SOME times, and based on the results, looks like this is not the case.

3 Likes
8

I’m not saying there aren’t problems or stumbling blocks. I’m not blind to the issues. I was providing my opinion. Feel free to disagree.

9

It might look like a technical debt. But wasn’t Xojo part of the technology that enabled
the funders to come and have a look at the system in the first place?
If the system wasnt developed there in the first place,
the funders wont even notice your organization.

Granted, maybe the system’s has outgrown its capabillity
at the moment (maybe). So if it needs to be redeveloped using
open source tools for some reasons, then by all means you should.

Every tools has its time , place and purpose.
Professional footbal player moves from club to club enhancing
their skills and value. Every club has its time, place & role.

We use Xojo , PHP (Laravel + Tailwind), C/C++/C# and
other tools according to applications requirement & scope.

You sure cant write the next Facebook using Xojo
but for agile specialized application ( with certain scope), its very difficult to beat Xojo.

Thank you for the insight though, always good to broaden your view.

3 Likes
10

What does “technical dept” mean?

11

I think it should be ‘technical debt’.

12

My assumption is that it is a misspelling of technical debt

13

He means technical debt


14

That still doesn’t make a great deal of sense. Is this supposed to mean that his company’s use of Xojo represents a deficit, a technical lack, in its capabilities?

Odd way of phrasing it.

15

Those evaluating did not consider Xojo appropriate for the long term so those apps would need to be rewritten

16

Humph. Well nothing is approriate for the long term. No machine architecture, no language, no storage technology will remain unreplaced. Punched cards, anyone?

4 Likes
17

That is why I linked to the Wikipedia description of technical debt so there would be more context on the term. It is but one of many definitions you can find online.

18

Sometimes, without a debt, you don’t have even anything to start with.

2 Likes
19

Exactly, especially the hunt of the next best tool can lead to a far bigger debt than starting to produce something, even though someone who want to invest into your company might one day tell you that you have a technical debt. It is like paying taxes. No one likes to pay taxes, but whenever I had to pay a lot of taxes, I earned more money than when I had to pay less taxes :wink:

1 Like
20

The bug issue is the main problem. Then add the discontinuations. Then add the buggy replacements.

You know, Ive been happily selling software made with Xojo for more than 15 years.
I get that it has bugs, but for business software, unless you are hitting what I consider the bleeding edge stuff, or maybe communications protocols, Ive never in all that time encountered a Xojo bug that prevented me releasing for the desktop.

Shame about the due diligence story

9 Likes