API stability and project philosophy question

Discuss anything related to product development
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

API stability and project philosophy question

Post by seasoned_geek »

All,

I apologize in advance as this will probably be long. I have been involved in many long rants on qt-interest mailing list about the lack of stability in the API and the continual Easter Egg hunt as each minor release seems to restructure at least a single header directory breaking builds wholesale. There has been a current discussion about the dropping of win 7 that has brought up many of these topics again.

https://lists.qt-project.org/pipermail/interest/ "Windows 7 support will be, dropped in Qt 6"

I believe that conversation started last month. Basically "the kids" (I'm old!) making the decisions seem to care not about the installed base when chasing features for a new phone. Yes, I'm on record stating repeatedly that the introduction of QML and JavaScript was a wretched idea. I'm kicking the tires on CopperSpice because I hope against hope that this will be the product for grown ups.

The big ticket world of medical devices and industrial controls needs API stability. What they really need is a 15+ year LTS but barring that, they can get by with being able to compile their 15+ year old code with the latest version of the libraries. That means:
  • header files don't change location.
  • methods don't disappear from classes
  • classes don't get renamed or removed
In the regulated medical device world you can get by with minor enhancements taking a much shorter (and less costly) approval path. As soon as you start changing big hunks of code just to support the latest release of a library you are looking at the lengthy (and very expensive) "shiny new device" approval path. It all depends on what the risk level is to a patient. A vital signs monitor is a much lower risk than a robot performing heart surgery.

Here is a "brief" snippet from one of my messages:
=====
It must have a stable API. Classes don't get renamed and methods don't
get dropped from those classes.

They must never allow the search for a header file to become an Easter
Egg hunt as it has with Qt release to release.

That's really the two requirements.

This ensures a program written today on some OS will be able to compile
against a release 30+ years from now even if it is a different OS the
program is running on. This is a cross platform library after all.

Have you been using Qt long enough to remember when multiple inheritance
got butchered because the powers that be wanted to lower the bar for
Java developers?

Code: Select all

/****************************************************************************
  * Originally created by Roland Hughes at Logikal Solutions.
  * Project is being released under GPL2 license.
  *
  * At some point in the future either Logikal Solutions or Roland Hughes
  * may elect to publish a book with this original source code in it.  If
  * the book is written it will be part of "The Minimum You Need to Know"
  * book series.
  ****************************************************************************/
#ifndef CATEGORIESDIALOG_H
#define CATEGORIESDIALOG_H


#include <QDialog>
#include <QtSql>
#include "ui_CategoryDialog.h"


class CategoryDialog : public QDialog, public Ui::categoryDialog
{
     Q_OBJECT

public:
     CategoryDialog( QWidget *parent, const QString &qtDbName);
     QString getEnteredCategory() { return m_category;};


private slots:
     void addCategory();


private:
     QString m_qtDbName;
     QSqlDatabase m_categoryDb;
     QString m_category;
};

#endif
That was how we did designer forms. Hundreds of thousands (perhaps
millions) of lines of code in the field and to make Java developers feel
warm and fuzzy that was just dropped. Kids today who started with 5.x or
later have no ability to function in that world. They have no frame of
reference to get a handle on it. If they can't see and use this:

Code: Select all

/****************************************************************************
  * Originally created by Roland Hughes at Logikal Solutions.
  * Project is being released under GPL2 license.
  *
  * At some point in the future either Logikal Solutions or Roland Hughes
  * may elect to publish a book with this original source code in it.  If
  * the book is written it will be part of "The Minimum You Need to Know"
  * book series.
  ****************************************************************************/
#ifndef CATEGORIESDIALOG_H
#define CATEGORIESDIALOG_H


#include <QDialog>
#include "ui_categorydialog.h"

QT_BEGIN_NAMESPACE
namespace Ui { class CategoryDialog; }
QT_END_NAMESPACE


class CategoryDialog : public QDialog
{
     Q_OBJECT

public:
     CategoryDialog(QWidget *parent, const QString &qtDbName);
     ~CategoryDialog();

     QString getEnteredCategory();


private slots:
     void addCategory();


private:
     Ui::CategoryDialog *ui=nullptr;
     QString qtDbName;
     QString category;
};

#endif

They simply cannot function. That may seem like minor little thing, but
when you have a device in production and a code base exceeding a million
lines in a regulated world, that change locked you. Bringing in the new
version of Qt (even if it ran on your OS) would require changing every
module when all you were trying to do was update the device to support
one shiny new thermometer or other device.

Once that barrier came down; the flood gates opened; scripting languages
washing in like a tidal flood and with them, an ocean of developers not
formally trained.

Had the barrier of multiple inheritance being a requirement not been
removed, we wouldn't have veered this far into the weeds.

I cannot, in good conscience, despite all my years of using it,
recommend Qt to any paying client. The licensing, royalties, and lack of
good direction make this a tool they should not spend money on. Medical
devices will be deployed in primary market countries for 10-18 years
then refurbished and redeployed to third and fourth world markets where
they will serve another 10-20 years and still need to be supported.

The market that pays long term support contracts (medical and industrial
devices mainly) needs a tool set guided by people who were formally
trained. That hasn't been happening with Qt. It's not an elitist
comment. Formally trained people remember the installed base is sacred.
You don't sacrifice it without a massively good reason. Adding Java and
scripting languages was not a massively good reason.

=====
Another conversation thread has also popped up and I'm actually not a participant in it.

https://lists.qt-project.org/pipermail/interest/ "Set manipulation in Qt 6"

-----
While I sympathize to some degree with the performance motivation behind this
kind of removal of convenience functionality this has to be put into perspective
of the price you charge:

We had to spent a significant amount of our time during the last year to
keep up with the deprecations within the last releases in the 5.x series.
This includes re-inventing parts of the abandoned qalgorithm as part of
our code base.

The toSet/toList changes alone involved touching 200+ locations in the code
base and I am not aware of even a single noticable performance improvement
as a result.

A back-of-the-envelope calculation with generous assumptions on user count and
usage frequency makes me believe that the accumulated win on saved computer
time does not even offset the amount of manual work that had to be spent
on these changes.
-----

Is the focus of the CopperSpice project going to be supporting the large medical device/industrial controls industry with such a stable API?

If you visit the interest archive and read some of the messages for the past two months you will get the sense a large chunk of the Qt community is about to kick it to the curb. One poor schmoe is trying to support a big ticket client running their applications on CentOS 5. There was some debate as to whether a C++17 compiler could be installed on that rev, but so far I don't think anyone has actually tried.

The problem isn't just keeping "old stuff." The problem is the farther the API moves the lower one's chances are of being able to hire a new API developer and have them function in the old environment. To save you the trouble of reading all those messages, one of the medical device companies I brought up seems to run contract postings every 18 months or so trying to get Qt3 under OS/2. Yes, there are still a few out there, but that company isn't willing to pay anywhere near the hundreds of dollars per hour they cost. Adding insult to injury, a very large segment of "Qt Developer" only know QML and JavaScript so they don't know Qt at all.

Given all of the recent licensing changes with Qt and the constant disregard for the installed base when making enhancements, the medical device and industrial controls segments or their customer base is looking for a new tool. The "just use the old versions" philosophy isn't a long term solution as the Qt3 OS/2 customer should make abundantly clear. They can't get new people unless they either let them spend hundreds of hours learning Qt3 from scratch or pay hundreds of dollars per hour. Given the age of those who actually ran OS/2 (myself included) the hundreds of dollars per hour solution won't be viable much longer either.

Thoughts?
barbara
Posts: 446
Joined: Sat Apr 04 2015 2:32 am
Contact:

Re: API stability and proje philosphy question

Post by barbara »

This is indeed a long post and we have some initial comments. I know others on the team may want to chime in as well. Thanks in advance for being patient as we start a dialogue.

I believe your most pronounced question is asking, do we intend to offer API stability between CS 1.6.x, CS 1.7.x, etc. Right now that has not been our focus since there are many areas which need lots of love. It would be a mistake to lock things down too quickly. There are legacy parts of the code base which simply have too much UB, are outdated, and will benefit greatly from improvements.

We are here to have an open conversation and figure this out as a community. This is the point of open source software. The question we need to ask is really, when is the right time to hold some part of the API still. As one of the co-founders of this project I do not believe that time is today.

On the flip side, we are willing to discuss and figure out the best way to provide long term support for those who need that service.

Barbara
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: API stability and proje philosphy question

Post by seasoned_geek »

It's not so much long term support as long term viability.

There is little point in jumping from Qt where API changes happen willy-nilly because someone saw something bright and shiny; to another framework where the same thing is happening.

Frameworks need to be sacred like COBOL. I can still compile COBOL-78 72-column card format code with today's compiler. Nothing was taken away. No required things moved to some Easter Egg hunt location.

Qt is busy chasing the phone market at the expense of all others. Many of us are hoping CopperSpice abandons the phone market so that medical devices and industrial controls can have a stable platform to use. These are long-haul products. Minimum seven year lifespan. Usually closer to 30 years. A "support" contract won't help whoever that client is Harman keeps putting contracts out for. The API has changed so drastically people who "learned" Qt 5 cannot really hope to function with Qt3. The talent pool available is about the size of a mud puddle.

The same thing is about to happen to medical devices using 4.8. So much of the API is changing in Qt6 that those companies won't be able to find people pretty soon unless they find a recent graduate and want to pay them for 6+ months of learning 4.8. Most of today's grads are "script kiddies." The don't know much about compiled languages and don't care to learn. At least that's what I see in my part of the world. We can find schools that still teach C++ and have a few kids take the course, but they have little interest in learning a one-off API. Qt4 is quickly becoming a one-off. I had to rewrite my xpnsqt OpenSource project because it would no longer compile with the newer releases. Systems in regulated environments don't have this option.

Thank you.
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: API stability and proje philosphy question

Post by seasoned_geek »

One further clarification.

What I mean by API stability is

The code I write and put into production in 2020 will compile against the current version in 2051. No classes or methods will have disappeared and the header files will have the same names in the same places.

Lots of things can be added, but nothing ever taken away. The high level API will remain constant. Under the hood it could be as different as a Pinto is to a Ferrari but the API remains the same.
ansel
Posts: 152
Joined: Fri Apr 10 2015 8:23 am

Re: API stability and proje philosphy question

Post by ansel »

seasoned_geek wrote: Tue Jun 23 2020 4:33 pm The code I write and put into production in 2020 will compile against the current version in 2051. No classes or methods will have disappeared and the header files will have the same names in the same places.

Lots of things can be added, but nothing ever taken away. The high level API will remain constant. Under the hood it could be as different as a Pinto is to a Ferrari but the API remains the same.
The level of backward compatibility you are asking for is not practical on a project which still has legacy code that needs to be brought forward to modern C++. On paper, the idea of never changing older code is attractive to some developers. But for a library, this means certain changes are impossible and over time the pace of development slows to a crawl. There are countless things we can do so the migration process is simple, which gives the best of both worlds.

We believe locking ourselves in to the same constraints that libraries like Boost have tried to adhere to, would be limiting and come at a great cost. On the other hand, arbitrarily renaming public header files because one person doesn't like the name is not a great idea. Our goal is to strike the best balance we can between maintaining stable APIs and developing CopperSpice into a library that keeps up with developments in C++.

One of the problems you mentioned makes sense to us. It is like companies who use C++17, but they need one of their developers to go back to C++98 for a certain project. Programmers get used to lambdas and constexpr, and they do not want to go back to a time where they did not have these features. CS 1.6 has full UTF8 string support. Moving back to an earlier version make string handling much more complex. So the fact that this is a hard problem to solve is not surprising.

Rather than restrict CopperSpice, our business model is to make any migration path forward as simple as possible with good documentation and tooling, and provide support for companies that need to stay on an older version.
Ansel Sermersheim
CopperSpice Cofounder
tim
Posts: 11
Joined: Tue Oct 15 2019 7:45 pm

Re: API stability and proje philosphy question

Post by tim »

I've been working on the CsNetwork code to update it to more modern standards and best practices. As a result of that we've started work on a cryptographic API to help us and our users use cryptography more easily.

While working on CsNetwork and our new CsCrypto library, I've found plenty of APIs that are in need of changing. The existing APIs don't protect users against (obvious) mistakes and this protection is something we find of value to pursue to make CopperSpice better. Leaving dangerous APIs in place for the sake of compatibility seems like a regression to me. Changing things for the sake of changing them or to make it more shiny is also not a good approach and one the CopperSpice team has no interest in following. An API should change when there is a good reason to do so, not arbitrarily.

In my view, permanently maintaining an API and only adding new things without removing anything is not sustainable over time. At some point you find that an API is the source of bugs and you would do well to change or remove it. That would be the responsible thing to do. As a user it would also be the right thing to then upgrade and start using the changed API. I believe that with automated tooling, good documentation and support this can work well for many customers.
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: API stability and proje philosphy question

Post by seasoned_geek »

tim wrote: Fri Jun 26 2020 8:34 pm In my view, permanently maintaining an API and only adding new things without removing anything is not sustainable over time. At some point you find that an API is the source of bugs and you would do well to change or remove it. That would be the responsible thing to do. As a user it would also be the right thing to then upgrade and start using the changed API. I believe that with automated tooling, good documentation and support this can work well for many customers.
Not the ones with deep pockets operating in regulated fields. They need roughly 30 years of stability. Every API change that requires them to make any kind of coding change costs tens of thousands of dollars to millions of dollars in clinical trials and re-certification.

I will make the grand assumption you have only ever worked on the x86 based hobby computers. I will make that assumption because you thought my statement was too broad or whatever. People who came from midrange and mainframe worlds know my statement was too narrow. They've been supporting a common API since the 1970s/1980s.

VMS started out on the 32-bit VAX platform. It moved to the 64-bit Itanium platform and maintained its API, just adding things for 64-bit support. It ported again to an incompatible Itanium chip and maintained its API. It's now being ported to x86_64 and so far appears to be maintaining its API.

The entire purpose of Application Program Interface is that the specification of the API never changes. Implementation under the hood can switch out an ASCII computer for an EBCDIC one and nobody cares. The API remains.

The medical device world will soon not care if an application framework provides networking/Bluetooth/other-than-disk-or-serial-I/O. Most of the big names are creating I/O appliances to be used in every device. The FDA, pre-COVID-19 wasn't far away from mandating them. The security issue of network communications has quite simply been architected away. It has one serial connection with whatever is used for voltage spike control so that someone plugging a 20+AMP cable into the network socket can't kill patient or device. Over that connection pass a limited set of fixed format messages where every field width is fixed.

No SQL injection techniques. No buffer overrun exploits. Any bit stream not matching one of that limited set gets routed to the bit bucket.

I suspect industrial controls where human/animal life is at risk will soon get the same mandate as well. A burnable/replaceable I/O appliance inside of the case commits Harry Kerry at the first sign of trouble. The device continues safely on and field service has to be called to replace the appliance so it can once again communicate with the outside world.

All of these devices go through an independent external QA company whose one and only job is the extreme QA required for regulatory certification. They have already tried every obscure entry value possible. These systems have to architect out failure. These aren't hack on the fly AGILE shops. This is real Software Engineering. Waterfall with a full SDLC. The independent QA company develops tests from the documentation and documentation alone. If you do something not in that documentation it is a failure, not a feature.

That's the market I'm talking about. The kind of companies that make patient monitors, surgical robots, and a host of other things used to save lives every day. We've already architected out every possible buffer overflow. We couldn't rely on a library to do it because that would never get through code review or internal QA.
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: API stability and proje philosphy question

Post by seasoned_geek »

Let me take this just a bit further to increase understanding.

https://www.welchallyn.com/content/dam/welchallyn/images/Product-Images/Patient-Monitoring/Vital-Signs-Devices/Connex%20Spot%20Monitor/CSM_front_screen.jpg

Hopefully that link gets through. If someone could point me to how one is supposed to "attach" an image to a reply in here that would be awesome. Pictures really help.

I was part of the team that developed the Connex Spot Monitor. The company was Welch Allyn then. After the device went to final QA my contract was over. Please pay attention tot hat block on the right containing the thermometer and the box of covers for it. Let me take you through a brief memory of a commercial for some medical television show.

Picture a man sitting on a table in hospital gown with an old glass thermometer in his mouth. Young nurse holding chart and looking at watch. Cut to old nurse standing behind young nurse.

"We segregate thermometers in this hospital nurse" says old nurse.
"Yes" responds young nurse.
"Blue - Oral. Red Rectal" states the old nurse.
Patient audibly spits out thermometer.

That entire unit on the right side can be swapped out at hospital discretion. I forget how many different models/brands we initially supported. A hospital will switch out the thermometer from one oral to another simply because they ran out of the thermometer covers for one brand/model. Most of the thermometer units will support and identify different corded thermometer ends as well.

Welch Allyn got purchased by Hillrom (sp?) long after my contract ended. I will wager an entire case if diet Mt. Dew that Hillrom said "Hey. Support these other brands/models we make."

If you have enough of your original developers who remember the original development library and environment you can simply add identity support to the driver and message support for the new thermometer. Such a thing can sail through "enhancement" testing with a light regression test to ensure you broke no existing functionality because patient risk is low. The hospitals have multiple thermometers for each device (Red/Blue) in case one fails or they run out of supplies for one.

If you also want to bring in a new version of the library, in that case Qt, you could if the API didn't change. You would have to do more internal testing, file some paperwork, and get a slightly less light external regression test. As soon as you have to change other areas of the code due to an API change, you are well outside of the light to medium external regression test path. At least, that has been my experience in the medical device world. You now have to go through shiny new device approval process, just to add support for a new thermometer.

Using the old stuff only works for a little while. Pretty soon the library (Qt) has moved too far for you to bring in new talent.

Qt is currently in the process of hosing a lot of customers with Qt 6. These customers (and I'm not speaking for either Hillrom or Welch Allyn as I don't currently work for them and have never been authorized to speak for them) are currently looking for a library that won't hose them with API changes.
CandL
Posts: 49
Joined: Mon Oct 14 2019 6:37 pm

Re: API stability and proje philosphy question

Post by CandL »

I will see you VMS and raise you Honeywell (36 bit) or cards and paper tape ... used them all an got paid :D ... By the way the last Vax I saw was on a farmers flat bed going to the scrap yard, and our HP9000 HP-UX machines we can't even find used parts on E-Bay (lost the source)

Seasoned_Geek does raise some points of value...

I am a Mechanical Engineer, my wife an Electrical Engineer each of us with 40 yrs in the field. For the stuff we make a life span of 10-40 years is not unusual. With many of our products lives can be at risk, and this is where federal oversight comes in. In the US that means FDA,FAA,NTSB even OSHA. Just look at what Boeing is going through now.

In the last month I have opened codes that are 50+ years old ... but the good news is physics hasn't changed much. However as engineers we live for change ... with out change the world doe not need us.

So where does leave us?

May I suggest we define what is meant by "long term support". Does it mean:
  • It works on this CPU/OS and will for x or xx years?
    * Compaq Visual FORTRAN, designed for Win 7 DOES NOT want to run on Win 10 for example
  • The code is compiled and released with newer compilers
  • The code is ported to new CPU/OS
I could see a statement like:

Copperspice version support policy:
STS: Each x.x version will be supported for 1 year
LTS: Long term support versions of the form x.x will have 3 year support
XTS: Extend term support for the X version (i.e. the last x.x.x version so version 1.20.3 becomes supported for 10 years) would be for 10 years


LTS: Means Bug fixes, security updates and re-compiles on current compiler versions and OS
XTS: security updates re-compiles on current compiler versions and OS

Of course this is all up for discussion, but it may *start* to address seasoned-geek's concerns.

But to be fair seasoned-geek, this is asking a lot of Copperspice ... based on the "promise" of a cash stream. I believe the Copperspice team to have the integrity not to promise what they have no intention of delivering. I also know large companies got to be large by charging a lot and paying very little.

Getting Copperspice to commit to what you are asking for without substantial financial backing is just ludicrous. If they were to commit I would personally be quite suspicious. Maybe if KDAB made these statements it would have credibility... they, KDAB have been around longer and are larger... nothing against the Copperspice folks.
barbara
Posts: 446
Joined: Sat Apr 04 2015 2:32 am
Contact:

Re: API stability and proje philosphy question

Post by barbara »

CandL wrote: Mon Jun 29 2020 10:49 am Of course this is all up for discussion, but it may *start* to address seasoned-geek's concerns.

But to be fair seasoned-geek, this is asking a lot of Copperspice ... based on the "promise" of a cash stream. I believe the Copperspice team to have the integrity not to promise what they have no intention of delivering. I also know large companies got to be large by charging a lot and paying very little.

Getting Copperspice to commit to what you are asking for without substantial financial backing is just ludicrous. If they were to commit I would personally be quite suspicious. Maybe if KDAB made these statements it would have credibility... they, KDAB have been around longer and are larger... nothing against the Copperspice folks.
Your assumptions about our project and the team are very accurate. We do not want to make a promise we are not prepared to keep. We are also not interested in chasing shiny objects. Contributors and users are attracted to CopperSpice since we treat open source software with respect. Oddly this should be standard operating procedures and yet it is missing from some projects.

We will in due time offer an LTS version of CopperSpice, but I am not sure if this is what seasoned-geek is looking for. With a paid subscription policy we can keep that version "alive" forever. Ok, but what happens when someone finds a bug in that LTS version? Not all bug fixes can be back ported. So how do we keep the old API perfectly in place and yet offer new fixes?

For what we can tell he does not want us to modify anything, ever, in the API once it has been added. This sounds decent on paper but not practical in reality. At times it does make sense to jump from version X to version Y and make good changes. Our documentation is updated all the time and we have migration docs to help users move forward. That is the right thing to do and what we would want from a project.

CopperSpice has evolved massively over the past few years and there is so much we want to change and make better. We are very actively working on ideas and trying to figure out how to offer a solution for some API stability. There is no no one size fits all but something I can promise is that our team will listen and be a part of the discussion.

Barbara
Post Reply