Realistically, what could Xojo do to make you stay?

The Lisa was the project inspired by the PARC visit. Jobs was involved enough to name it after his daughter and be kicked off the project when it started sucking up revenue from the Apple II. He then appropriated the Macintosh project and turned it into a mini Lisa. Macintosh sales were almost as dreadful as the Lisa and Jobs unwillingness to compromise with Scully caused the board to push him out. Next Step suffered similar poor sales performance and the only person who can be blamed for that is Jobs.

The point is Jobs appeared to be so obsessed with the details of his products he failed to identify who might want to buy those products. It is an apocryphal tale of vision and passion and potential not being enough for a product to succeed. Understanding who is going to buy the product is perhaps more important, and that is where I believe Xojo Inc has struggled.

Not even that. On what we are working now? On a successor of Next. Jobs had a clear vision which Apple did not wanted that way to go. As far as I can remember Jobs brought exactly that to Apple. And as you can see: Jobs had a great Vision who should buy the products but he had not the financial power to do it.

It was an older and wiser Jobs who returned to Apple, and probably bruised by the lacklustre business performance of Next. The Lisa, the Macintosh and Next proved his vision of who he believed was going to buy those products didn’t want them enough. With the iMac G3 there is a lowering of expectations and finally some understanding of ‘who’ the market might be.

Not to forget: all of that: graphical OS, Mouse and much more they - Steve Jobs and also Bull Gates - saw before at Xerox Parc. Tat was the carrier of the Idea behind that what was later Lisa and today our Computer Systems. So it isn’t Jobs which had the initial Idea to do it. Apple did not invented graphical OS-environments and did not invent the computer Mouse. It was Jobs which recognized the chances behind.
Mellebrein invented firt computer Mouse in the early 60th. patent paintings here:

After that in the 70th Xerox Parc developed the first Computer with GUI and Mouse you can see here:

The Xerox Alto, developed 1973 was the first Computer with GUI and…last but not least…a mouse. Ten years later Apple came with Lisa. The first personal computer with GUI and Mouse.

What do I want to say with that: it was never Jobs which had the Idea for it. He had the vision how to sell it on the market. Not all times he had a lucky hand with it. With Lisa and also with Next it was not a lucky Hand. Next was to far away from the rest of the world. When Next was not in a good condition Apple bought it and Jobs was back.

Even the combination of a Palmtop with a mobile phone and a camera was not Jobs Idea first. But also here he had the lucky Hand and the vision how to sell that. While Next had developed stuffs and Apple could use it within MacOS(x) it started to become a real nice game. Apple had the best Phone, the best Computer OS and so on. They had Success and where growing fast. But that wasn’t Jobs only. It was the combination of a Vision and LUCK. Tons of LUCK.

Absolutely agree with this

While he had great vision I believe you will find that even he said upon his return to Apple that he had to go away to learn how to be a better CEO

And Apple is where it is now in part for both versions of Steve

EDIT : Perhaps Xojo needs Geoff to go away to learn to be the saviour that Steve returned to Apple as ?
As you noted vision is but one element needed for success

Jobs idea, the technical innovation, was attempting to lever the GUI concept into a desktop personal computer. The Lisa failed because it ended up competing in the workstation market. Jobs tried again with the Macintosh but failed to derail the IBM PC. By the time he gets to Next he’s missed the boat, takes aim at higher education and fails to capture significant sales there either. Each one of these products raised a similar observation from commentators, “Nice product but who will want to buy it?” The lack of sales success was so widely predicted it’s not poor luck - It’s a behaviour pattern.

The luck was Jobs getting a second bite of the Apple and it took Next to be in decline and Apple a critical condition. The iMac G3 was technically mundane but the aesthetics provide a clear picture of who the customer is - Someone who is not a computer geek and is not obsessing over specification and price. The Jobs that emerges is much more confident leading Apple in packaging complex technology in a way that is acceptable and accessible to ‘normal’ people - That is what Apple does (or did) best. A skill or vision that is hugely underrated by experts in the field.

1 Like

That’s no question. But his Vision wasn’t a technical Vision. His Visions with Success where exactly this market Visions for products and the needed technology for getting that market covered. And yes, Apple does it still best.

This is true. Always be careful what you wish for. But as much as I preferred the old IDE, don’t forget how often RB and RS used to crash - Xojo very rarely does now.

I barely recall how it was then (although I’m using the product since around 2002). Was it so long as to get one new IDE per year?
I frankly would have preferred more rare releases that are a pleasure to use (like RB 5 used to) than encountering all these bugs/inconsistencies in everyday use.

Perhaps a matter of experience. I don’t remember having so many crashes in earlier releases, although I agree it’s rare with Xojo. On the other hand, I’m fairly sure RB didn’t used so much RAM and slowdowns.

Don’t forget that RB had a proprietary compiler. Now the Compiler is the LLVM Compiler which needs Xojo code to be generated as intermediate code for LLVM. That there are differences in the Code size may be. but also is that the price for having these cross platform abilities.

1 Like

I do. Especially starting the debugger. Or stopping the debugger. Or stepping into a line of code in the debugger. I used to resort to printf debugging to help keep my blood pressure down given all the lost productivity when having to use the debugger. Things are certainly better in that regard, in my experience.

The debugger still crashes on things that go out of scope while stepping through code

I see that one all the time - still

I think its fixed in some future version I haven’t seen yet

Through all this I came up with this as the “list” they could do
Some are technical - things they can attack readily since “its just code” :stuck_out_tongue:
Some are process related
And some organizational (headcount etc)

Technical
• Fix the horrible Windows framework / graphics implementation.
• Bug fix only releases
• Fix web2
• More up to date technologies in their frameworks (HTTP/2 WebSocket etc)
• updated / fixed IDE

Process
• Fewer deployment targets and do the smaller set “better”
• Under promise over deliver
• Focus on quality - not quantity ( test driven development ? )
• More focus on professional software developers

Organizational
• Increase headcount (presumably to do more bug fixes?)
• Remove geoff

For my “in-house” apps, I’m glad I can make apps in various targets using Xojo. For instance, I’ve one desktop app which I can control remotely with an iOS app (on my iPad) and which sends data to a web app. When Android support comes, I’ll be happy to have the iOS app ported to my phone so I don’t have to bring the iPad with me.
I know many targets have bugs, and I deal with them, but if I had to learn one language per target and make them communicating together, I simply wouldn’t have time or resource. And I’m not sure each language would seamlessly make compatible apps.

It is neat to have one Language and deliver to all targets as I am doing with Java. Well, Xojo try to do it but they even have no Android what means: one target missed. That and the fact that there are to many bugs where leading me to the decision not to use Xojo again. As I was crashing with one App in deprecation of Xojo 2019 and no chance for building in Xojo 2020 and it’s successors I am happy today that I had not to walk through the process of all the framework changes.

Still, the concept behind Xojo is great and could be a really market beating Tool. Could, If there would be Android. If there would be a Release cycle which allows to bring Reliability instead of selling BETA Versions as production. Nobody knows when something is ready. And when changes in Frameworks stop.

Hello,

Having worked with WinDev for quite a few years. All I can say is that most of the development tools practice this.

WinDev comes out with 100+ features every year! But around 25% of them are in unusable state and very buggy. Around 40% are bug fixed version of old features which are relisted as new features! Rest 35% are new features or enhancement to existing features.

That same thing applies to Delphi also. In fact the IDE of every new version of Delphi is unstable and gets stabilized in due course. At times I feel Delphi is using its Users as beta testes who pay large amount of money just to beta test and report problems!

So don’t take it to heart. Most of the dev tools follow this practice.

When working on a project, how much of your total project time goes into coding of the deliverable and how much into discovering bugs and creating workarounds for bugs of the dev platform/stack?

I am working with Java, C and C++, sometimes also Python. I can’t say that it has no bugs at all but I can say that I had never that kind of experience with a development tool. Maybe there is a fundamental reason why the most industrial users are working with this languages? I guess yes. And there is also a reason why the other ones are nearly dead: while all the features are not working. It is a difference between finding a Bug in a very special situation which will catch one of 10k programmers or if the entire system is so full of bugs that Avery programmer reaches the show stopping point one day and a big amount reaches a show stopping point with no chance for workaround. That isn’t so with the professional languages like C, C++ and Java.

3 Likes

I place project development into categories.

Type	       C/C++/Python	Xojo
Coding	               40 %	 10 %
Documentation	       59 %	 40 %
Bugs/Workarounds	    1 %	 50 %
Total Percent	      100 %  100 % 
Total Hours           100    200

Although it takes less time to actually code in Xojo, I find that most of my time is spent with Bugs/Workarounds. This makes the overall project take much more time. Most of my work in on Windows with a moderate amount of projects on Linux. Mac projects almost don’t exist for my work. Most of my work deals heavily with graphics (OpenGL, Vulkan, DirectX), some database work, and heavily relies on math (simulation, AI, machine learning), some website work (php, CSS, Javascript), and also projects heavily in electronics (motors, actuators, sensors, control systems, etc).

C/C++ and Python are extremely stable languages where I have stable projects running for years. Xojo projects are usually for fun or create a skunkworks project to determine what a client wants - so that not much time is spent on a plan - usually 2 hours maximum.

I my humble opinion, Xojo should remove bugs (this is a tall order) to keep the current programmers and create an open-and-honest relationship with their forum members. Xojo-Windows and Xojo-Linux programs need some severe bug-fixing, as I have to create plugins/declares for every Windows/Linux project to workaround bugs.

I have many books that are partially-written that have show stopping bugs, so they stay on my computer and wait until these bugs are fixed. Some books are being rewritten to API2, but show-stopping bugs are preventing their release - so the book publication time is delayed. The oldest book that has been delayed is 12 years old, and a publishing date for this book is looking rather dim.

My personal emails for Xojo-solutions have increased significantly since the forum-toxicity has increased due to censorship, and people don’t want their names shown on the forum. There is only so much time in a day, and I can only fix (and charge) for so many Xojo-fixes/workarounds.

Creating a new language has crossed my mind a few times, and this has a large time requirement.

In summary, here are some humble points to suggest to the Xojo corporation for helping themselves become better:

  • Remove bugs
  • Have better documentation
  • Promote camaraderie
  • Better support for Windows and Linux
  • Remove the many graphics constrictions
  • Become multicore
  • Slow the marketing hype, try to under promise and over deliver. The current focus seems to sell, sell, sell.
  • Try and buy some plugins from Christian and Bjorn and implement them in Xojo, as they have good-and-stable solutions
  • Update the creation of plugins, as the current method still uses REALbasic naming and has many bugs
  • Allow controls to be truly native

There are many more items, and this post is getting too long… :slight_smile:

4 Likes

Welcome in my World Eugene, I would say: also in my development world it is exactly so. Development with Xojo costs more time cause of documentation leaks, Workarounds, Bug fixing for not working parts cause of misleading docs and because of not working parts or not like expected working parts and so on. In their world Xojo is the best product ever but: the total count of time with Java or C++ and C is half. I can’s say for C# while I never tested really deep enough to be able to say. In some parts Java is even faster (Desktop GUI Applications are much faster than writing with C++ or C but when using a framework like QT or wxwidgets it may come to the same speed while you do not have to write all the parts by self.
It makes me sad that it is so while that is not connected to the language itself or the IDE. Or let me say the Idea of the IDE.But many factors are making me faster. Handling of variables and Classes, methods and so on.
And Xojo? They would have to change their release model to concentrate first to a lots Support to get rid of the bigger Bugs and an incubator Version with the newly developed features. But even then: with so small team nearly impossible to do.

1 Like