[DECtalk] DECtalk TTS licensing

[Don]

On 8/31/2021 1:57 PM, Chime Hart wrote:
> Bravo Karen-and-I would also say that maybe more often in Linux, folks write
> software because they enjoy a challenge,

No.  Folks write software to *tinker*.  They want something to focus
on (instead of just trivial "exercises") that they can point to
when it *almost* works.  And, then move on to some newer endeavor.

If they "enjoyed a challenge", they would be chasing down every bug
and ensuring they produced a *quality* product.  The first 80-90% is easy.
It's the last bits that are challenging!

This is the risk with any "free/open" software project; there is no
long term incentive to maintain the effort, fix bugs, incorporate
new features, etc.  It relies entirely on the enthusiasm of the
person(s) doing the work.

And, more often than not, they are more interested in playing with
some new feature than in finishing up the niggling details of
some OLD feature.  True to form, they will likely only partially
implement that new feature, as well.

This seems to be human nature.  How excited are you about proofreading
a friend's manuscript?  How *diligently* will you do this?  Or, will
you just go through the motions?  How much 'recognition" do you think
you will get for being the guy who TESTED the manuscript (program)?

Now imagine proofreading your own manuscript (i.e. program!).  How
eager will you be to scrutinize it in the minute detail necessary
to catch the bugs/errors that you didn't catch moments/days earlier...
when you were still "writing" it?  Or, are you alrady tired of it
and eager to move on to something else?

I talked with a firm that was looking for help designing an electronic
("credit card") lock for use in hotels, etc.  They flew me out for
an in-person talk -- so we could meet each other, see their facility,
etc.

During the visit, I was given a tour of the facility.  The last stop
was a visit to the lab in which they were developing the lock
prototype.  They had a complete system set up for demos (my role
was to be sorting out how to make these systems talk to each other).

My guide gave me a 5 minute demo of the lock and the "front desk"
equipment that was used to make the "keys" for the guests
(keys are disposable so a guest can't get back into his room
after checkout time -- when the room might belong to a NEW
guest!).

I asked if I could try it for myself.

And, proceeded to make several "grand master" keys (for the
imaginary hotel) without the machine having any record of my
doing so!  I.e., an employee could do likewise!

Ooops!

Now think about it.  They've been working on this for more
than a year.  Long enough to actually have BUILT a functional
prototype of the lock AND the "key maker" console.  I first
saw it 5 minutes (literally!) ago.  Yet, I've found a significant
flaw in their design without ever having a look at the internals
of that design!

I.e., this was OBVIOUS to me.  Obvious enough that I only needed
a 5 minute demo to sort out where the flaws would lie.  Why wasn't
it to them?  Would they have discovered it had I not come along
to exploit the flaw?  Would someone *hired* to find flaws
have found it?  Would they think of doing that?  Or, would they
rely on their own staff to stumble on the problem?

Who had the bigger incentive to find these flaws -- me or them?
(again, my role had nothing to do with the normal operation
of the system, just tying them together!)

> as where in windows, not sure about
> DOS, there are more commercial projects. Certainly if you offer a paying
> project, there are more chances an average user can get help or even have an
> avenue of suggesting improvements.

This cuts both ways.  A vendor can STOP supporting *or* selling a product.
What recourse do you have, at that point?  They've already written you off!

> And lastly, didn't an Echo 2C have speech in the early 80s?