On Wednesday, January 30, 2013 4:11:41 AM UTC+1, Andy wrote: > > Thanks Thomas. Another great discussion, but I'm really surprised by all > of the enterprise software hate. > > Obviously, the core issue is that too many people don't get the Web, but >> that's another debate. >> Of those people, who came complaining in the forum, some said they >> couldn't even recompile their app with the workaround (i.e. we're not even >> talking about updating to GWT 2.5 here, which would imply going through >> non-regression tests, etc. just applying a small workaround, recompiling >> and redeploying). > > > As I said, we sell software that is compiled by GWT and deployed behind > firewalls within organizations. We can recompile and post patches, but it's > up to them to redeploy. They might not see that code for 6-12 months in > some cases depending on their policies. To give you a sense of the > challenge, many of them are still using IE7 as their primary browser, but > of course those people weren't affected. > > You might argue everything web should be SAAS, but many of our customers > aren't going there and have good reasons. >
That's not what I'm saying. In your case, you're an editor so you have the responsibility of testing your app with beta/dev versions of browsers before they reach your customers, and if you find an incompatibility then you tell your customers to update their installs of your app with the version that contains the fix/workaround. It is then the responsibility of your customers, if they'll be affected by the issue, to deploy the new version or prevent their browsers from updating: they chose to install/use a webapp, they should be prepared to deploy such "patched versions". As you said, "it's up to them", and they then have no reason to whine if they're not up-to-date: you gave them a fix in due time (possibly even before they'd notice the issue). What I'm angry about is a bit different though: our customers ask us to develop a webapp (we're not an editor, it's their app, they own it and are responsible for its maintenance). Once deployed in production, they only care about the server being up and running; they update their browsers but don't plan for (preventive) maintenance of their apps (it holds for any app, not only webapps, but webapps exacerbate the problem). Far too many people don't even monitor their apps for security breaches: only a handful of our customers ask us the list of 3rd-party products/tools/libs we've used to build their app, and even less monitor them for vulnerabilities. It's no different from your customers not installing updates, except that they probably pay you a license or other commercial support that includes providing updates; in my case, once we deliver the app nobody does the preventive maintenance. During the warranty period we fix those issues (we might update vulnerable dependencies too, but it's not even part of the deal), but once it's over it becomes our customer's responsibility, and nobody does it (unless it's a LoB app, maybe). We have support contracts in some cases, but it's only about fixing bugs (and sometimes adding features); preventive maintenance is not part of the deal. You just can't let a piece of software live its own life, particularly when it's a distributed app, even more if it's a webapp (because you have even less control over the “client runtime environment”, i.e. the browser) -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
