RE: [tlug] [OT] Good IT Resume

["Stephen J. Turnbull" <stephen@example.com>]

burlingk@example.com writes:

 > have wide spread use.  If you are dealing with a
 > new product, and the only ones that have hold of
 > it are the "alpha testers" (gods help them),

Alpha test is by definition part of the project, so it is not a
problem: it's *their* job to deal with interface and implementation
changes.

 > and the beta testers, then change is expected.  At
 > that stage, it is acceptable to break anyting and
 > everything.  :P

You apparently have an unconventional definition of "beta test" in
mind.  A beta test is a test in a production context, using real data
(but presumably not in a mission critical role).  Beta testers should
*not* be whipsawed with interface changes if you can possibly avoid it.

In open source, it is acceptable to use the tradeoff between source
availability and interface stability to some extent, depending on
case.  But most open source projects abuse the freedom in my opinion.

 > Also, if the library is only in use by a tight
 > knit community of developers who all contribute in
 > some way to the library and it's developement, then
 > it is not so hard to send out an email saying "Hey,
 > we might be breaking this.  This is how we plan to
 > do it, and why...."

You're describing the way Emacs runs.  This is fun for the core Emacs
developers, but it really sucks for everybody else, including all the
not-so-core Emacs developers, but especially those who try to support
XEmacs as well.

Note that open source by definition does not fall into that class.

 > THAT cannot be blamed completely on the library developers.
 > It is still ultimately their decision to drop support for
 > an API call (so they are partly to blame),

That depends on whether their code is open source or not.  If not,
responsibility necessarily rests with that project.  There are also
some projects (glibc, Xlib) where maintaining a private copy of the
library is often infeasible because the product is way too big and the
internal APIs change a lot.

Also, there's a problem that some projects (XFree86, I'm looking at
you) choose to have a specifications-based process, then deliberately
ignore the specifications.

 > but it is also an application's dev team's choise of whether or not
 > to update their code to use a new library

They may not really have a choice.  This is the case with XKB, for
example.  If you want an X application that does fancy things with the
keyboard (XEmacs and maybe GNU Emacs), you need to support both the
legacy interfaces for the commercial Xlibs, and the XKB interfaces,
because the workarounds to use legacy interfaces available for XKB on
XFree86 corrupt data on some versions of Solaris, at least.