gnupic: gpal fork


Previous by date: 9 Mar 2004 12:59:49 -0000 Re: gpal fork, pic00
Next by date: 9 Mar 2004 12:59:49 -0000 Re: 16F877 I/O, Scott Dattalo
Previous in thread: 9 Mar 2004 12:59:49 -0000 Re: gpal fork, pic00
Next in thread: 9 Mar 2004 12:59:49 -0000 Re: gpal fork, Michiel Boerman

Subject: Re: gpal fork
From: Byron A Jeff ####@####.####
Date: 9 Mar 2004 12:59:49 -0000
Message-Id: <20040309122713.GA3525@cleon.cc.gatech.edu>

On Mon, Mar 08, 2004 at 05:56:56PM +0100, pic00 wrote:
> Is someone interrested in the fork ?

No.

> It adds some OO capability, and more types compared to gpal.

Doesn't matter.

> In difference, the language is stronger, variables and procedures
> must be declared prior it's usage, subprocedures and -functions are
> allowed and for the main program's and modules little changes or
> addition are planned.

Here's why. The author is planning to subvert the spirit in which gpal is
produced to make a closed source private fork. I'd by very interested if
these enhancements were offered in the same vein Craig created gpal to
begin with: a Open Source, open development system. But despite Scott's
suggestion to "take it down a thousand dude..." I feel like Craig does.

All of the advantages in the world will not overcome the fact that because of
the closed source nature of the additions percludes anyone else from regression
testing, optimizations, bugfixes, and the like.

What closed source authors have not yet figured out is that there really isn't
a constituency that exists anymore that benefits from the closed source model.
There used to be a time where it was a viable profit model. It just isn't
anymore. Here's what's going to happen: Developers won't use it because it
won't meet their needs. Someone will need a Mac or FreeBSD or other kind of
port. Others will need better performance or a specialized interface. But
in the closed source model only one person (or a small group) can fulfill
all of these requests. So it'll move slowly.

This will be compounded by the cost model. While that works fine for end users
who do not have the time or inclination to compile something much less do
actual development, gnupic folks are used to getting their hands dirty.

The final element is that gpal, and Craig as a driving force is still out 
there. Craig understands from previous development that if you keep it simple
and make it work, then folks will use it. He understands that the fastest way
to kill a project is to give it featuritis. As a language developer myself
adding all that other stuff when the target is a limited memory microcontroller
is a recipie for disaster. So what will happen is that Craig's stuff will
work, work well, have fast bug fixes, and be multiplatform in short order. 
So most of us will use it.

Open Source is a volume model with distributed development. So more people
will be working on improving gpal, and more people will be using it.

So no I'm not interested in a closed source fork.

BAJ

Previous by date: 9 Mar 2004 12:59:49 -0000 Re: gpal fork, pic00
Next by date: 9 Mar 2004 12:59:49 -0000 Re: 16F877 I/O, Scott Dattalo
Previous in thread: 9 Mar 2004 12:59:49 -0000 Re: gpal fork, pic00
Next in thread: 9 Mar 2004 12:59:49 -0000 Re: gpal fork, Michiel Boerman


Powered by ezmlm-browse 0.20.