[ale] Stable, backward compatible APIs

[JD]

Thanks for the thoughtful response.

On 08/30/2012 03:58 PM, Lightner, Jeff wrote:
> Of course this is why RHEL is setup the way it is.   You can put your
> Enterprise on it and trust that you don't have to do a complete revamp of
> everything every year or so.   (In fact for RHEL5 Redhat announced earlier
> this year they were extending its life from 7 years to 10 years even though
> RHEL6 has been out for over a year.)

I probably wasn't as clear as I could have been.  I wasn't talking about long
term support for a specific release.  Ubuntu LTS releases have support for 5
yrs, but that isn't really what we need.  Being stuck on old an old OS release
to run an old commercial program is the issue.

Rather we are talking about consumer-level desktop releases that supports
programs over many years. Since I haven't touched anything from RH since 2002, I
can't talk in those terms - but what end-users need and demand is a stable API
across Ubuntu 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 .... with new APIs added, but
old APIs remaining for GUI programs.  Any program that ran on Ubuntu 6.06 should
be able to run unchanged on Ubuntu 14.04.

Backwards compatibility, while not forcing anyone to hold back their desktop OS
revision.

Any Gnome2 program should work under Gnome3. Any KDE3 under KDE4. Just look at
Android v1.6 programs that work under Android 4.1+ and every version in between.
 A few programs are tied to specific hardware but the vast majority of them are
not. They are Android compatible.

> On the flip side it means some things on RHEL get a bit long in the tooth.
> (e.g. BIND 9.3 is the base RedHat uses on RHEL5)  Redhat does backport
> security and bug fixes from later upstream versions into theirs but still it
> becomes limited compared to newer things.  But then again for an app like
> that you can always forego the RHEL provided package and download/build the
> latest from source.

Programs that do not cost SW-CAP to install don't count.  It is the Adobe
programs, the gee-wiz-bang new gaming company and Intuit who need this level of
commitment.  It would help smaller developers too.

Sorry, but until Quickbooks works on a Linux desktop, tens of thousands of small
accounting companies will not switch.  Saying we don't want those end-users,
does them and us a disservice.  Linux desktops should be inclusive, not exclusive.

Building from source is not an option for most commercial offerings on a
desktop.  For example, build Skype from source.

Perhaps the Linux Foundation can lead the effort for a stable API?

I believe that servers are a different animal.  The merits of Linux + GNU with
BSD/MIT/Apache licenses have all but won this market already.