[ale] Stable, backward compatible APIs

Thu Aug 30 18:58:23 EDT 2012

I'm not so sure the API has to be stable to the point of stagnation in
order to instill trust.  There are disciplined ways of evolving an API
and many FOSS communities have done so successfully.  From what I've
read and seen the problem in the Linux desktop arena has been the
undisciplined evolution driven by the developers/designers.  Deprecating
entire subsystems without advance notice because one of the key
designers thought of a cool new way of doing it over the summer,
regardless of how entrenched or critical the API may be.  (And no,
publishing your intent on your blog before the next release doesn't
count as advance notice.)  I've abandoned a couple small projects
because of stuff like that.

So in short, I find fault more with the personalities involved than the
nature of the enterprise.

On Thu, 2012-08-30 at 17:33 -0400, Jim Kinney wrote:
> It _sounds_ good but it's not feasible. For an API to be stable for
> years, it must be very simple, very limited and mostly ignored. A
> desktop environment fits none of those.
> 
> This doesn't work in Mac/Windows land either. Apps that used the
> desktop gui are hit-or-miss after an upgrade to a new OS on either of
> those. The way they handle this is with long-term support.
> 
> Keep in mind that most commercial crap is released when it compiles.
> They'll patch later with the upgrades. So hard stuff like API design
> for a decade is really not going to happen. In Linux-land, API design
> is done by committee, coded up and then a new committee comes in.
> Yeah. That works well :-)
> 
> On Thu, Aug 30, 2012 at 4:54 PM, JD <jdp at algoloma.com> wrote:
> > 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.
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
> 
> 
> 
> -- 
> --
> James P. Kinney III
> 
> Every time you stop a school, you will have to build a jail. What you
> gain at one end you lose at the other. It's like feeding a dog on his
> own tail. It won't fatten the dog.
> - Speech 11/23/1900 Mark Twain
> 
> http://electjimkinney.org
> http://heretothereideas.blogspot.com/
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20120830/2cec5d9f/attachment-0001.bin 