This is a big reason for VB.Net loosing users. The problem is not the language itself, but the lack of support by MIcrosoft, leaving VB.Net alone.
1 Like
Yes. Thatās also a big reason for FoxProās demise. That and Not Invented Here syndrome. They picked its bones clean, taking its best asset (the DB query optimizer, which was called Rushmore) and incorporated that technology into Sql Server. They did not value nor respect the remarkable loyalty and enthusiasm of the user community nor their stated commitments to it.
Iām kind of surprised that this mercenary business approach applied equally to VB.NET though. The Not Invented Here (NIH) aspect very much didnāt apply as it was the ultimate expression of the technology that actually launched the whole company. Youād think thereād be some pride of ownership and heritage there. But the bean counters always win in modern corporations, and intangibles always lose. The decisions made are almost invariably soulless and fraught with hidden costs and downsides that those decision makers will never be held accountable for, nor indeed even connect the dots.
So it goes. I suppose one can argue that VB.NETās very existence was an expression of this pride I speak of, and they might argue that it wasnāt the future even back in 2002. But it isnāt just the timing of them cutting it loose, but the way in which it was done. I saw zero community input and no attempt to soften the blow. And as you point out, part of what makes a technology viable is the makerās commitment to it and promotion of it. So the proximal cause of VB.NETās demise is that somewhere between about .NET 2 and .NET 4, focus on and commitment to VB.NET was lost, and after that it was just a self-fulfilling prophecy and a matter of time. VB could still be an industry force and a nice alternative to C# but oh well!
As I recall, they also more or less incorporated that into MS Access and I think they saw FoxPro and Access as too much overlap and FoxPro had the NIH stigma. But then Access languished too. So even big companies with lots of resources canāt be everything to everyone.
Part of the reason for acquiring Fox Software was that it provided MSFT with a ādesktop databaseā product while they re-engineered after the Access 1.0 debacle. You would THINK they would have taken a look at the technology theyād acquired and gone WOW and just dropped Access, but again ā NIH syndrome. I can imagine the psychological barriers ā it was using the Watcom C compiler and not Microsoftās. It was targeting Xenix and Mac and I suspect they probably had started working internally on a Unix target. It was contrary to everything the Ballmer-led version of MSFT was still in denial about.
Iām going through something similar now. The company I have been captive to since 2008 was acquired in 2020 and I had a significant role in building a superior technology platform. But the motivation for acquiring us was to buy a temporary position in a sub-market but with the assumption that nothing we had was of any value and that all our business could be absorbed into their own incomplete understanding of that market. There is no way our technology will survive in the long haul. It will either be explicitly killed or allowed to wither organically over a longer period but it WILL die. Not because it is the rational or best decision either for clients or the new host company. But because the company is making money overall, it is one of 3 dominant players in this market, and clients will be forced to take what they can get.
This is the problem with monopolies.
1 Like
Opinion:
Eventually, the original developers who created and invested in a product, leave.
New guys join and bring ānew ideasā, and new ways of working, new frameworks, (and more levels of encapsulation)
The old stuff is boring to them.
Nobody likes to fix bugs and do maintenance when there are shiny new things to be created.
If they are forced to work on it, they try to make it into their favorite āother thingā, or allow it to rust until it simply goes away.
1 Like
You arenāt wrong, Jeff.
I never understood it though. Iāve always been equally happy to support / maintain as I am to create. I find both satisfying. I feel you have to take all the scope of responsibility; you canāt make it your personal playground.
That is what disturbs me about Xojoās comment that the developers donāt like to work on bugs all the time, like itās a pesky fly that just has to be swatted once in awhile. If I had the appropriate skillset to work on the product and I were assigned to work through the bug list and never build new features, I would not consider that a consignment to Siberia. It is just a particular aspect of what I do, and I get as much of a sense of purpose from diagnosis and repair as I do from architecture and implementation. Considering some of these confirmed bugs are years old I would get even MORE of a sense of accomplishment from finally resolving them. In some ways I would be contributing more to the success of the company than the guys working on the next version. Sorry but you canāt deprecate or ignore maintenance. It is absolutely as crucial as anything else.
Hi Jeff and Bob!
I think both are right.
Man, by his nature, always seeks to create new things. Without this, we could not see the modern world as we experience it.
In business, few managers learn in school that things that WORK donāt necessarily throw away. My Father said well, many believe that they have reinvented the wheel. When itās not true, it takes time with us.
On the one hand, recent graduates of computer-related careers want to change the world without thinking about the experience.
On the other hand, entrepreneurs do not value the mission and vision of a company. They only look at the accounting records.
Both are wrong paths that only look at the tree and donāt want to see the forest.
Unfortunately, most people take one path or the other. And not considering that you can take the all-set.
1 Like
Totally agree. I love me some bug hunting. Give me a list of bugs and Iāll start whittling them down - even ones not assigned to me for the next release. In my current position Iāve closed a lot of bugs this year (wonder if I can query Jira to see how many?). Started with the low hanging fruit and then when I became for familiar with an area of the product I tackled the harder ones.
2 Likes
Canāt stress this enough.
1 Like
Then they know what they can do.
I have spent a career using (at various times) COBOL, Pascal, C, C++,C#, Basic , VBA, VB4/5/6/.Net and Xojo
Nothing easier to make a GUI app with (especially on a Mac) than Xojo
5 Likes
Anecdotal as Iām not a full time consultant developer but whenever Iāve been asked / commissioned to make an app, the client couldnāt give two hoots what itās written in. They just want the end product.
3 Likes
In my experience, this is very uncommon. Most companies care about the tech stack of their contractors (also they should).
When I was freelancing (between 2013 an 2018) I never used Xojo for client projects.
I am pleased now I didnāt, because I wouldnāt be able hand over the maintenance to another freelancer in my region. I would be tied to those old clients, and they to me.
3 Likes
We donāt know. But if it would be an impressive number, then Xojo Inc. would advertise itā¦ 
2 Likes
A while ago, they said around 2,000,000.
I missed that. If I look at the number of people who registered my software over the last 20 years (after I added registration), it would run into the high 6 figures. But some bought twice, some registered twice, and I am sure many do not currently use the product.
Potato, Tomatoā¦
Nearly 100% of my consulting work was because clients wanted to use Xojo. They found the product and then found me to do the work (normally after they tried themselves to learn). I was a Xojo consultant for 20 years. In 2019 that work dried up and by early 2020 I had found full time employment.
My experience is similar. At first, my biggest customer balked when I told them Xojo was the platform I would use. Now mind you, it WASNāT the end users of the application who cared, it was their IT department. Granted, I had the unique leverage that I had developed a proprietary algorithm and business model that was a hand-and-glove fit for their needs. Reluctantly (because they really had little choice), they went with it. It was a huge success. That was six years ago ā¦ now, about a dozen projects later, when I ask upfront if there are any issues needing discussed, I get ācricketsā in response. Moral of the story - Success goes a long way towards validation! The difficult part is always getting beyond the initial naysayers and receiving that āfirst approvalā.
3 Likes
It depends. A small company with no in-house technical sophistication would not know to ask, and Iāve experienced this indifference. But most corporations of any size develop a disordered focus on shareholders at the expense of other stakeholders, including their customers / clients ā and this tends to lead to a culture that way over-values risk avoidance, especially if it takes the form of sticking your neck out to defend a choice. The expression of that in IT is to use technology stacks and toolchains that most others use ā or at least that a LOT of others use, such that it is difficult to be faulted or blamed for the choice, and relatively easy to find expertise.