[OT] OpenEU
On Mon, 18 Aug 2003 14:51:57 -0500 (08/19/03 05:51:57)
, Ted Fines <fines at macalester.edu> wrote:
>
>
> Hi all,
>
> Can anyone provide examples of successful and unsuccessful forked
> software projects?
>
> I understand and agree with many of the arguments both for and against an
> open source Eu competing with Euphoria. I'm just curious about what has
> happened in other instances.
Sorry, but I can't help you with this.
However, I'd like this opportunity to clarify some perceptions that people
may have about the 'open euphoria' idea.
Firstly, and *very* importantly, OpenEU is not trying to compete with RDS
or Euphoria. All OpenEu code will be proactively sent to RDS (rather than
assuming that RDS might passively acquire it). OpenEU is not intended to be
sold. I do not want RDS to go broke because of OpenEU, and I can't see how
that would ever happen. Instead, we hope that OpenEU may broaden the
exposure for RDS and Euphoria and direct some extra sales RDS's way.
Secondly, this is not a forking exercise. We are not starting with the RDS
code and then diverging from it. We wish to make available an alternate
compiler/interpreter for the Euphoria Language, starting with just the
current Euphoria specification. Currently, there is only one realistic
source for Euphoria interpreters and that is RDS. Just in the same manner
that you can acquire C compliers from different organizations, we would
encourage the situation where one could get Euphoria compliers from
different organizations.
The definition of Euphoria is controlled by RDS, and that is not about to
change anytime soon. We do not intend to declare that OpenEU is the 'only
true Euphoria'; that is still in RDS's domain. And we assume that RDS will
be the caretaker and driver of future Euphoria specifications.
OpenEU will, at best, implement Euphoria v2.4. It may try to keep up with
any future changes coming out from RDS's official Euphoria definition, or
it may not. This depends on many, many variables and we just cannot see
that far into the future yet.
OpenEU will introduce additions to the Euphoria specification, but we will
endevour to do it in a manner that will not break existing Euphoria code.
There is a huge resource of existing Euphoria code and it would be stupid
to disenfranchise all of that.
The primary driver behind the OpenEU idea is that RDS is moving slower than
we would like to enhance the Euphoria language. I believe that Euphoria is
a great language and that it can be still greater. However, the process
that RDS uses to move the language forward is taking more time than I would
like. I am not saying that RDS's process is flawed or invalid; on the
contrary, RDS is perfectly within their rights to do whatever they wish
with Euphoria. I have no issue with that. As I feel that I can't wait for
RDS's enhancements, I now wish to take a different route.
In some respects, the relationship between Euphoria and OpenEU will be
similar to the relationship between C and C++, in that C++ can process C
source code but the reverse is unlikely. Please don't read in to this that
OpenEU is going to be like C++ - it isn't! It is going to be like Euphoria.
There has been a long hiatus in the OpenEU preliminary work due to other
commitments, but that is coming to a close soon; meaning that I can resume
preparing the groundwork for OpenEU in earnest. I do apologize for the slow
beginning, but my family needs to eat too.
Finally, at no time so far, has RDS expressed any concern to me about the
OpenEU concept. As a sub-plot, we hope that some of the new functionality
introduced by OpenEU will find its way in to RDS's Euphoria.
--
cheers,
Derek Parnell
|
Not Categorized, Please Help
|
|
