Begging for another Release System

Markus, dev tool marketing is very different from OS marketing. The OS marketer must entice devs to the platform to write apps, because app support is what sells OSes. And so as a user you don’t care so much about new features because your apps are already there. Likewise as a Xojo user you may not care as much about new features because your source is already there.

However long term viability of a dev tool company depends on attracting new devs. This is because dev tool selection is a lot more fluid than OS selection. There’s more switching of dev tools then there is between say Mac and Linux OSes. This means to remain viable, a dev tool company must innovate, it’s offerings must not become stale. If it does not, it will not be around to provide ongoing support for its existing customers.

Thus a balance between new features and ongoing support must be struck. The question is where. I and others say Web 1 is still part of the Xojo ecosystem because most Web apps must stay there for a while. That is the reality. My company does not presume to understand what new features should be when because we are not privy to Xojo Inc’s marketing information. What we do know is 2019r3.x is not dead, and still needs and deserves support. That is our argument. The rest is just details.

Not according to Tim Apple. Apple created the platform, API and provided a service for developers to make money, which is why on iOS you MUST pay Apple 30% of your proceeds.

… and rightly so :stuck_out_tongue:

:wink:

1 Like

Who are you quoting?

2020r1 has 161 bug fixes.

But a release with just bug fixes or a release with a lot of bug fixes isn’t necessarily what anyone wants. What they want is a release that fixes the bugs that are currently causing them grief or will in the future.

A user might not have any bugs that are a problem or they might have only one. If that bug is fixed, they are happy and if not, it doesn’t matter how many other bugs are fixed because those are having no impact on them.

As for bugs that might affect them in the future, of course it’s very difficult to know that in advance.

@Geoff_Perlman Re:

2020r1 has 161 bug fixes.

Whilst I’ve got no issue with the number there was something drastically different with the release - IOW, all other things were not equal. Put simply, the only way to take advantage of those fixes was/is to adopt Web 2.0 and if we conceptualize the new framework as things we must ‘fix’ in our code - I am left with the option of living with 19R2x introduced breaks or a decent amount of work / change to take advantage of their remedy. This does, therefore leave broken items in pre Web 2.0 (as in the the response I provided to you (at your request) above re localisation to which I am still awaiting a reply).

Steve

Yes, I realize that there will be things in the Web 1.0 framework now that will never be fixed.

Other than that time involved in updating your project, are there any technical issues that would stop you from moving your project to 2020r1?

AFAIK there are no technical issues that would prevent this move (with the caveat I have not spent any significant time assessing).

Steve

Yes Geoff the Status of 2020r1 as not ready. That’s what you are ignoring.

1 Like

Doing a release every 2 month for MBS Plugins works very well.
And sometimes a new feature sits on the shelf for a year until it’s polished and ready to release. And I have delayed some items for a version before.

Now we hope Xojo Inc. continues and delivers later this year a 2020r2 with a lot of improvements to Web 2 target.

You are conflating an e-commerce hardware/software/communications platform with an OS. By way of analogy, if Xojo Cloud charged end-users not devs and paid devs then you would have a fairer comparison. In reality Xojo’s value proposition is x-platform and ease-of-use development. This debate is about whether Web 2 delivers on that sufficiently to depreciate Web 1, to which we say “not yet”.

Based on Xojos past and present behaviour regarding fixing bugs, what should let long time users believe that with Web 2.0 that situation will change?

4 Likes

It wont change.

But you are then at least able again to use the current version.

It is so sad…

4 Likes

Sure, but the IDE lies at the heart of Xojo’s x-platform/ease-of-use value proposition. It deserves back ports since realistically, Web 1 isn’t going away soon. I would argue the cost to Xojo Inc. of back-porting API 2 fixes would also be very low. However it’s the IDE back-ports that are critical because they support developer productivity fundamental to customer satisfaction.

1 Like

There is a lot more than technical issues. These have been discussed.
But you must not neglect that not all of us are hobbyists, and not every web app created with Xojo is just the size of Eddie’s. So, after having charged our paying customers for API 2.0 upgrade which does not bring much direct benefit to them except for being blessed with future improvements, we are charging them again for Web 2.0 upgrade which, for complex web apps, may easily consume days or even weeks. That gives us an uncertain stance to justify Xojo’s use.

Posted this somewhere else already. No, I don’t say you have the same attitude as Google. As far as cutting backward compatibility, the pain feels the same. https://medium.com/@steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc

5 Likes

Exactly that’s the peoblem: a hobbyist user is using xojo as a gamepad and learns how to program something. We are programmers and HAVE to get alive with this Result. For me, if there is no turn I will leave and that’s it because I can not release from a deprecated Version of Xojo.

@Geoff_Perlman you should never forget that the professional users are the fundamental base. We are not buying yearly for new functionality. We are buying for updates and Bugfixes.

Web 2.0 is nice. Yes. But it is extremely unready and not aduld. It should be aduld for our uses. But it is not. We have no chance than working out the status. For us it is no question if there is a Web 2.0. For us it is a question when it will be ready. If you are willing to help y<our pro developers, than do what we want: change the release system so that 2019r32 will be still in maintenance and the bugs will fixed. I don’t know where all of you studied Software business but I know that it is not a question of Business for Developers. It is always a question of maintained Versions.

I have an example. Over years we used Wiringpi as Library. It is officially deprecated. In my Audit-Report of regulatory Body (VDE) I got the message that I have no working software live-cycle because it is deprecated. The same message I will get from FDA and from TÜV. That’s the end of using it for developers under authority control. And all developers with connectioons to Hardware will have exactly the same problem. Cause the regulatory Bodies will not do any discussion about it. No Paper no way.

Exactly this is not in your view and it seams you do not want it there. It may not help.

The Point of rewriting is, that I can reuse 20% of the code now. The rest I have to invent new. That is not an update to a programming language, it became a new language. And this comes up with new problems. Ar first I have to say there is no way of simply rewriting. I have to do documentation to the regulatory body and within this I have no, really no chance to simply change my language. That means because of the way you where going, in case of working under authority of regulatory bodies we have to do a completely new control of conformity for the entire product. This costs tons of money.

If there would not be the stop of maintenance we would not have this problem. Thats it and if this is not reaching to your focus I have to say yes, than you reached the point of a hobbyist system. They have no regulatory issues.

1 Like

Maybe another sight:

Xojo Inc. says, two web “frameworks” cannot easily coexists in the same version. As we know now, thats not really true, cause Xojo could use Namespaces and stuff. And as we all developers know, “not possible” in our field mostly means “not possible in a cost-to-usage ratio”. Which means to make a thing possible, it is just not worth the effort.

Since Xojo Inc. is a small company that is totally relatable. Every one of us had similar situations also, where customer begs for “feature xy” or “change yz” but they didn’t fit into your produc vision or were just to expensive to implement maybe. The only point where you might change your opinion about these requests is when it eventually becomes attractive for you to bring “feature xy”.

** Long story short: **
Until it doesn’t become more attractive for Xojo Ink. To help their professional long-term users instead of chasing the feature-rabbit, until then, nothing will change and they simply will sit out the rant.

** So how can we make it more attractive? **

  1. Just quitting our subscription won’t help, we’re too few. Thats the reason why nothing changed already.
  2. Making bad press wont help as well - is Xojo really a thing in developer magazines and such? I think not.
  3. Moving away completely? See 1).
  4. Pay them for a long-term support Web 1.0 subscription? -> maybe? @Geoff_Perlman?
  5. Make them clear, that the loss of their reputation, our faith in their product and in Xojo future will be eventually way more expensive then point 1-3 combined. -> perhaps, but doesn’t seem so.

** What I want to say: **
While Xojo Inc. sits out our complaints, while they leave us behind with an product, which is slow and full of bugs, while this, they’re destroying the faith of some of their customers.

And until this is not worth enough to fix this situation, until then nothing will change and we are still left behind.

** My bet what happens: **
From Xojo Inc .: nothing, it’s just not worth enough
From us few customers: Either we go and leave Xojo behind or we put tremendous work in the convertion to Web 2.0 when it’s ready in a year or so. In the meantime, we stick with bugs and a deprecated framework.

That is the reason why this discussion is over for me now. Xojo was cool, it is still, but not in professional environment anymore. No one can assure, that such a situation wont happen again in a couple of years. I am out.

6 Likes

While it would be technical doable to make a switch and either load Web 1 or 2 classes before calling compiler, Xojo Inc. decided it is not worth the effort. And they changed a lot in the IDE for the web page editor and didn’t want to have a lot of switches there to keep old stuff working while adding new thing. On the end it’s a small company.

The best possible may be to kindly ask for specific changes to be made to Xojo 2020rX and maybe pay them to back port some fixes to older 2019 branch for a bug fix release.

3 Likes

That is a good idea. Over to you Xojo Inc…

That needs some company being so desperate that they contact Geoff and ask for a quote.

1 Like

So we’re all very clear then - ask for a quote to fix bugs on the version against which they were raised.

Really ?

1 Like