Could it be Saved?

So here’s the killer question - we all know some serious mistakes were made.
Could Xojo be saved at this point, and how?
What if anything would make you think “OK… they’re trying…”

If it were me, I’d circle the wagons, and

  • ditch API2 ,
  • ditch Android,
  • freeze raspberry PI,
  • do a bug bash,
  • embrace BASIC in the marketing,
  • and discount annual renewals.

(But it’s probably too late to ditch API2 - damned if they do, damned if they don’t… and that more than anything else is a ball and chain for them)

What would YOU do?

Personally, I don’t think so. It will limp on for a while, losing more to other languages and IDEs over time.

Ditching API2 would not be option then you just have the other half enraging that actually did the conversion to API2, leaving them stranded with their Apps.

Freeze raspberry PI would make no sense, that one is little effort and brings them a lot of good will.

Embrace BASIC marketing in 2023 a guarantied suicide. The old basic users from 1980 or just getting that “OLD”, you need new customers not to scrape the very old that are just getting fewer and fewer.

On the question if it could be saved then I would say yes in a way, but I have felt that door has been somewhat closing.

2 Likes

Well, you don’t agree , which is totally fine.
But what would you do?

‘brings them a lot of good will’ - haven’t seen much.
'Embrace BASIC marketing ’ - but it is BASIC… no point pretending otherwise, thats why Im there, for sure.

I would like to add that your customers might just be the ones that are correct. I would say stop all development then Zoom-up all your paying customers even the estranged customers and spend 15-30 minutes with them on a call or even on a group call. Listen to what they tell you. If you missed it really listen to what they tell you. I mean seriously listen to what they tell you! Make notes get your key-points jotted down. Put the serious key-points on whiteboard and start focussing on getting your dev-customers happy. We are XOJO’s customers but actually that ain’t the reality. Our customers are XOJO’s customers. If you brush me off you have no respect for my clients that I work very hard to obtain and onboard on to XOJO or rather onboarded onto using XOJO. You see we as the developers are just the middle-men and middle-women. The users of our hard work are the important people that are screwed over. So XOJO, go to the DOJO and get you bloody MOJO together - pun intended.

4 Likes

In some fairy-tale world where I had $50M burning a hole in my pocked AFTER I purchased the company I would:

  1. Meet with existing dev team to ascertain where they feel the pain points and technical debt are
  2. Have a series of zoom calls with key customers (past AND present) to determine their needs and priorities
  3. Consider open-sourcing some or all of the product, either immediately or down the road
  4. Begin recruiting to expand the dev and support teams … first hire would likely be a compiler specialist and someone to address the documentation issues

I would not necessarily have an all-hands-on-deck bug bash until all bugs are gone because I’m pretty sure many of the bugs reflect poor design decisions and technical debt and that may have to be addressed before or along with many of the bugs. Fix it once and fix it right. This implies months or even a year or two before the product really improves, sadly.

In situations like this one often finds that large swaths of the product have to be rewritten or even reimagined based on a root cause analysis. And inherently you will never discover all of this before you buy the company, which is why only someone with way more money than sense would probably even embark on such an enterprise. If I really had that kind of money I would probably just bootstrap a new product and let Xojo die a natural death.

In THAT case I would have to ask myself what I could bring to the plate that other cross platform efforts already do not (desktop/mobile/web). If I could develop a real alternative then I would want it to be language-agnostic if possible. And while I have affection for Basic (I got my start there, 40 years ago) I would not necessarily have the vision that Basic was somehow a must-have language in the stable, either. The C language family (e.g., Java, C#, JavaScript) seem to dominate now. That is reality.

A viable product would either have to resonate with what devs are already familiar with or be appealing to a sizable minority despite being in some way opinionated or idiosyncratic / different.

Based on all the above if I had lottery winnings to go into the fray with I would probably just be a tool/control/library and/or services vendor for one of the existing platforms. Does the world even really NEED yet another development platform?

It’s hard to bring back developers that have already left the fold. Even with my 20+ years of involvement in the Xojo ecosystem I’d be hard pressed to come back.

With that said, I’ll play.

First, talk with as many customers, current and past, as possible to see what the pain points are. Get into the analytics on what people are actually using Xojo for. This sets up the next set of priorities.

I’d ditch all mobile (assuming it’s not a big attraction for customers). iOS is half baked and Android even less than that. This lets me focus on Desktop and Web.

Hire a compiler engineer and work on performance issues and other things that hopefully come out of talks with customers. Hire more developers and hire an evangelist and make that person be the ‘face’ of Xojo doing webinars, answering questions on the forums, being THE person that either has the answer or can find it.

Start rework on the IDE to make it less cumbersome. Hell, maybe ditch the IDE in favor of commonly used IDE’s to take advantage of their extensibility.

Build unit testing into the tool such that a right click in a class or module creates a unit testing companion.

Make the product as attractive to business users as possible. Enhancing reporting. Enhancing database connectivity and database ease of use. More controls that are common to business apps.

Start looking at Web and see if there are ways to load more into the browser and deal with more things on the browser side rather than server side.

Just a few thoughts. Been giving it some thought for a long time.

5 Likes

The answer to your first question is yes, the answer to the second is more complicated.

  1. Hire more developers. They need a developer per target, and someone to maintain the IDE and maybe someone for the compiler. With specialists instead of jack of all trades, not only would this reduce workload on each developer, it would allow them to be more effective in their area and to pay attention to the things that is needed to keep Xojo relevant.
  2. I think it is too late to ditch API 2.0. However making it easier to maintain API 1.0 projects and providing a LTS version of Web 1.0 would go a long way to reducing fallout.
  3. Listen to customers.
  4. Ditch the precompiled POS frameworks. Instead re-write everything in pure Xojo code. This I understand is a massive undertaking, but it would allow Xojo to be open sourced, without it all becoming open sourced.
  5. Everything they make for themselves should be available to their customers. Like the frigging sidebar, why make your customers spend hours trying to get expected functionality, when you’ve already done it, because you don’t care, that is why.
  6. Create an affiliates program, whereby the enthusiastic members can recommend Xojo and provide a link to which they’ll earn a percentage from.
  7. Support 3rd party add-ons in a big way. SwiftUI is really cool (with some quirks), I could make a XojoUI but I’d need help from Xojo. I know it’s a waste of time, because currently Xojo doesn’t care about 3rd party devs and when I needed them to add things for App Wrapper, they simply ignored me.
  8. MVPs shouldn’t be forum police at all.
  9. MVPs should be the captains of their fields. They’re needed to help keep Xojo on track with how their industries are developing, not to pat the CEO on the back.
  10. MVPs should be paid to support Xojo’s customers.

What would I do? Assuming access to adequate capital, developers etc of course

  1. Make a public announcement that Xojo (all platforms) is at its END OF LIFE, but that the status quo (including minor bug fixes) will be maintained. Basically FREEZE the current product AS-IS

  2. Begin a total 100% ground up redesign of a NEW Product, Identify all the bad design decisions from before, and don’t repeat them. This is the ONLY way to insure that all new modern technoligies are embraced.

  3. Ditch iOS and Android, they simply missed the train there, Apple is moving too fast to keep up, and the best tool for iOS is Swift (and its FREE)…

  4. Ditch Raspberry… the market is too smal compared to the technical effort to continue

  5. Concentrate the new design on macOS, Windows, Linux? and Web

Would this take a long time? yes
Would this take a large investment? yes
Would Geoff even consider such a course of action? NOT ON YOUR LIFE

But in my opinion, it is the only way

4 Likes

I will never ever be dependend on a sole company with its CEO. Even if our “stable genius” will revert some of his decisions today or do some of the points Dave mentioned, I wouldn’t come back.

IMHO the last chance is to set everything under a free license (GNU/ MIT) upload the sources on GitHub/ GitLab/ Codeberg or an own GitLab/ Gitea/ Forgejo Server and try to get back the trust of the (Pro) Community.

This will and must be a slow steady process.
Lost trust can only come back through actions.

2 Likes

There is no “Raspberry”, its simply ARM, there is nothing specific to Raspberry in it even if they thought it would be bright idea to market it as such. Other than that its just same as Linux (which they need for Web anyhow). And World is moving to arm even for Desktop. So makes little sense to ditch Arm.

3 Likes

it would encourage development of the product, but that doesn’t keep Xojo in business

1 Like
  1. change rapid release to a tock tock style (major release with new features, next release is JUST bug fixes, etc) that way there should be a “stable” product with fewer bugs than its predecessor at least twice a year
  2. discounts for renewals
  3. put out a 5 year plan and stick to it - right now the roadmap isnt a long term “vision”
  4. HIRE some developers
  5. hire a documentation specialist
  6. get the team to actually respond IN the forums nots always in private conversations where no one else can benefit from whatever transpires

I have 0 faith ANY of this will ever be done

2 Likes

Yes, but it’s a lot easier to guarantee support for just RPI hardware and compatible ARM boards than every ARM based SBC on the planet. Xojo does not include simple libs for GPIO, I2C, SPI…?

With same argument they would have to guaranty support for any Linux (on the x86 platform).

And no Xojo does not provide GPIO libraries of any kind so really the Raspberry or other board is not much relevant.

Ahh… I thought Xojo supported specific RPI hardware like camera. Can Xojo GUI programs work without X11?

They support no specific hardware.

And I have over 30 different boards and have never found board that does not work (as long as the board fits the CPU type requirement)

2 Likes

THIS ^

While I’m sure every developer of an app starts out with a grand vision people will use it in ways you never dreamt of

Guy Kawasaki’s principles apply

But you cant just pick a few (ie/ #2 and not do #3 )
And #6 applies
You might start with a fixed notion of how your product should be used
And who might use it
If you’re not flexible about those things the “curve” will pass you by
I do wonder if that isnt where Xojo finds itself
Or found itself so may years ago and starting trying anything they could to increases sales
I’ve been told by others that revenues jumped up early on & pretty much flat lined for the next 15+ years
And so we get Web !!!
iOS !!!
Android !!!
Web 2!!!
Android (and this time we mean it)!!!

Web 2 is here!!!
Android (again)!!!

1 Like

They could start out with getting this fixed for their remaining pro developers?

convert-to-api-2-causes-crash

The conversion experience seems to be less than stellar.

1 Like

Until, or unless, they come out & say “The entire IDE has been converted to API 2” I wouldn’t be in any rush to do this

Dog fooding it for the IDE will get a LOT of issues solved
Until then I’m not “converting” any client projects
I have no desire to be their guinea pig
Newer ≠ better

4 Likes