Thus changing its name to ExclusiveAI? No? Still the air of moral superiority?
"A rose by any other name would smell as sweet" - similarly: "Open[BLANK] by any other name would be just as much marketing bollocks".
"But what about ..." is irrelevant
Nothing to do with that.
Nor is this a case of whataboutism. I am not justifying one company's actions based on another unrelated company's poor business decisioins.
I am stating that given this deal with Microsoft, the "Open" in OpenAI's name is now meaningless and/or dishonest. I used the example of Progress/OpenEdge as another example of a company putting "open" right into their name but failing to live up to their name - implying that Progress' name-change (and also: OpenAI's initial name) was a cynical marketing ploy to make people believe they're the _good guys_ in all this, especially when the AI/ML field has many detractors from the altruistic camps, especially after Deep-Fakes, Palantir, Cambridge Analytica, and Facebook have all left a bad taste in everyone's' mouth.
I think we are mostly on the same page here.
Eventually it fell so far out of the norm it became difficult to sustain as a career choice but it doesn't warrant your dismissal I think.
Agree the name change was dubious, though an understandable attempt to get away from dated 4GL connotations.
I agree that their start in the late-1980s on IBM's AS/400 - Progress was a nice system to build on-top of. But only for those few years.
The main problem with Progress 4GL - just as with all other 4GL systems - is that they're vertical silos: 4GL vendors wanted devs to stay inside their own proprietary ecosystem and they made little-to-no-attempt at integrating with anything third-party. The fact it took until the late-1990s for Progress to add support to SQL to Progress (and require hours of sysadmin work of editing low-level configuration files just to get their "broker" system working) shows where they saw their money coming from: small-to-medium-sized business customers' business systems locked-in to their 4GL system's OLTP model.
I won't go into the major inherent problems in 4GL vertical silos - the fact they've all completely failed or fallen into irrelevance by now is evidence enough (Progress, Paradox, FoxPro, etc). Businesses now realize that interoperability and data portability are very important, which is why database vendors like Oracle, Postgres, and others saw success in offering only a database product - and aim to be the best database product with the best interoperability.
I have an axe to grind with Progress Inc over this very point: there's still a good number of business customers of Progress systems written decades ago that are looking for a way out. I was asked to build a simple data-connector to slurp data from an on-prem Progress database and that's where I ran into not only technical problems, but primarily licensing problems: Progress Inc (the company) made it very clear to me that the only way I'd be able to write a program to get data out of that on-prem database is by ponying up north of $3,000 USD just for an SDK for my own machine, in addition to extra "per-user" licenses for each on-prem site that would be using my software to liberate/exfiltrate their data (never mind that those on-prem sites already had Progress licenses - but they didn't have the right kind of user license). Compare that to the predominant database vendors around today that are either explicitly open-source or give-away developer-licenses to their Enterprise-SKUs away for free - and put effort into making solid client-libraries for rival platforms. Progress' sheer intransigence and their continued opposition to the past 25+ years of industry trends is just mind-boggling.
(I wryly note that only in the past couple of years or so has Progress started to admit their product isn't as great as... frankly, everyone else. So I see they've changed the company's direction away from their 4GL and onto buying-up component vendors like Telerik - unfortunately for them I feel this is coming too late because now even being a proprietary component-vendor feels outmoded given that modern UI platforms and frameworks are well-serviced by gratis and libre open-source offerings, especially first-party libraries like Google's Material Design and Microsoft's Metro/Modern/Fabric/Fluent/WhateverItsCalledThisYear.
----
Footnote:
You wrote:
> inline data manipulation features that long predated Linq etc
From what I gathered from their OLTP system built-in to their 4GL - it's only superficially similar to Linq. It isn't a true relational-calculus system (like Linq) - nor relational-algebra system (like SQL). Please correct me if I'm wrong - my experience with Progress is limited to versions prior to 11 and I understand they have added some modernizations to their platform - but it's still very long in the tooth.
Progress Inc's problem is that their software isn't very sexy, which means they'll have problems attracting the best and brightest in the industry - after all, if you're a hotshot kid from Stanford who solved the object-relational impedance mismatch problem - why would you want to work for Progress?
No idea where you are getting that from, SQL has always been supported, but no reason why it should have been a priority given the vastly superior 4GL for creating applications against Progress until the 2000s.
database vendors like Oracle, Postgres, and other saw success in offering only a database product
Different companies, different priorities; Microsoft an obvious counter to that claim.
Comments on Linq, SQL etc; no, my point was it was direct and inline access to data. It was a very successful but niche approach that eventually got traction as a concept and alternative to SQL when tools like Linq arrived. But Progress devs had had that ease of data access in their programs for years, under the cover of the unfashionable 4GL label.
I agree with you on it's general awkwardness wrt industry trends, and obscure pricing and marketing strategies.
My mistake. I did some research and I found [this page](http://www.oehive.org/VersionHistory.html) which says that SQL-89 support was added in 1988, but SQL-92 support wasn't added until 2000.
But even so, SQL-89 is very anemic and not very expressive compared to SQL-92 (I'm thinking primarily of the support for different types of JOIN expressions), and the fact it took them 8 years to add SQL-92 support is telling (consider that MS Access 97 supported most of SQL-92). I can't find any information suggesting that Progress/OpenEdge implements later standards like SQL-1999 and SQL-2003 which add features I use on an almost daily-basis (recursive CTEs and window functions respectively).
> my point was it was direct and inline access to data
Doesn't that place architecture-based restrictions on performance though - how well does concurrency and transactions work in their OLTP model?
The ABL language supported functionality like that in the language for ages.
> Doesn't that place architecture-based restrictions on performance though - how well does concurrency and transactions work in their OLTP model?
By what metric?