Opensource filePro Project

[Fairlight]

With neither thought nor caution, Jay Ashworth blurted:
> Obit of the *year*:
> 
> Heston: You can have my guns now.
> 
> Heh.

Second time I've heard that one.  Still grimly amusing.

> Here's a *different* question: is there any 3rd-party IP remaining in
> the filePro code base that would prohibit such a thing?

That's not the entire question.  The part you're missing, given the
company's history, is, "Who all holds rights to the IP, even if fP=Tech
currently [mostly] controls its use?"  It's possible someone has a partial
grip on it behind the scenes.  For instance, if the company went under
tomorrow, who inherits the IP?

> And, Jose, here's one for you: how would fpTech make money?

MySQL prolly isn't hurting.  Red Hat, despite a history of hemmorhaging
money, is still around.  Novell has SuSE.  Go commercial support on a
dual-licence freeware/corporate solution like MySQL did, I'd say.  One
of the less intelligent moves fP=Tech has made in recent history was in
offering unlimited support for about $2500/yr.  Novell will charge you
$675 just to talk to them about a patch they released that breaks systems,
if you have no contract with them.  Welcome to our service economy.  But
it makes sense to adapt that model if it's more lucrative--and if you
don't make absurd offers that cut off your nose.  Heck, Novell and RH both
license the software -and- charge for support--it needn't be either/or.
And they're both OSS software packages.  OSS doesn't mean "no revenue
stream" anymore, and hasn't for years.

I still maintain that de-coupling the storage format and abstracting I/O
to one API with common denomenator functions between SQL engines would be
the way to take it.  Start with a MySQL lower level driver module, move on
to MSSQL, JET/Access, then Oracle, Postgres, and a few others, roughly in
that order.  They'd have (TTBOMK) the only -character based- SQL RAD.  You
can find GUI, and you can find web based.  I've yet to find a character
based one for SQL.  They could keep native storage as a default, not lose
anything of their current offering, and gain a lot--IF they get themselves
advertised decently.  They could even license the driver modules separately
now with the new LM, so the more heterogeneous the environment people have,
the more they'd make.  Imagine Oracle, MS, My, Pg, and Access all under one
unified top-level hood, with no need to migrate the data between stores.
And probably a bit of the work is already done from the fPODBC product, in
terms of both code and figuring out how to make both native and ODBC play
nicely in the same house.

I've promoted that option for years.  It's doubtful they've heard,
listened, understood, or cared.  Pick any or all.  Not my problem, but I do
think it's their best bet for the future.

mark->
-- 
"Moral cowardice will surely be written as the cause on the death
certificate of what used to be Western Civilization." --James P. Hogan