OpenEuphoria

1. Arguments upon Arguments, in Open Source!

• Posted by Mario Steele <eumario at ?rila?e.net> Jun 06, 2008
• 665 views

Hello guys,

I'm here to talk a bit about the "abrasive arguments" compared to the
"productive arguments".  And before you ask, yes there is a big differnce. 
There's ben quite a bit of traffic (Enough to start making Rob get a bit worried
about his monthly bandwidth problems) about various new features being added to
the Euphoria interpreter.  Now, I've not seen the development list for Euphoria
(Though I will be signing up guys), but from the EUForum, there's all of these
abrasive arguments, and productive arguments going on.  Heh, let me clue a few of
you in to how Open Source Projects work.

Since my departure from Euphoria as my primary language to Ruby as my primary
language, I've become more involved in Open Source projects.  I'm Matt's
competition on the Ruby side, for two projects.  wxRuby (wxWidget bindings for
Ruby), and wxRIDE.  wxRuby I joined, but was someone elses project, and I'm one
of the core developers there, wxRIDE is my own initative.  And both have been
major learning experinces for me.  For thoes of you who believe that Ruby get's
financial backing.....  heh, there's hundreds of thousands of programmers working
on that Language.  The most financial backing they get, is to cover the costs for
the hosting of the SVN and the Web Site.  Quite a bit of traffic goes through
there, cause of the fame of Ruby on Rails.  Just wanted to clear that little
point up.

Now, in my experince, projects that start out open source, generally do good,
cause there's a single authority, to make the final decisions on what is being
incorperated.  wxRIDE, I have that luxuary, cause that is my baby, I started it,
and I know what I want, and what I don't want.  So, one of my programmers come to
me, telling me of a feature that they want to incorperate, I consider it, and see
if it fits or not with what I want, if it will actually be convient to the "END
USER".  Let me emphisize that some more.  I see if it will actually be convient
to the "END USER", not myself.  If it works for me, great, if not, but can
benifit someone else, then fine, I will consider it.

Now, this is the same ideals in place with the wxRuby development team.  We're
at a feature freeze currently, for wxRuby, as we are looking to push out Version
2.0 of wxRuby, which will be considered for Full Development stability.  We have
a different idea about release versions.  We consider the primary number, as
being the official, deployment in a full development system, as being stable. 
With a bunch of features being added in the 1.x.x series, as well as bug fixes,
and all that good stuff.  And it's a long process, we only have truely 3 people
working on the project, to get wxRuby together, and we've ben doing a pretty good
job at it.  It's becoming more and more stable as we go along.

Now, for the kicker in this.  Ruby just moved to pushing in release 1.8.7, and
boy did that mess quite a few of us library writers.  They changed half of the
back end that we've been use to for quite some time.  And they did it without
notice.  From 1.8.6 patchlevel 114 onwards, things have tooken a radical change
of course.  And what for?  To make compatability transition betwen the 1.8 series
to the 1.9 series and eventually the full 2.0 series of the Ruby interpreter,
which will switch to a Bytecode VM of it's own.  Not that it benifits the
interpreter as it is right now.  And they never "asked" the community if they
wanted to do it or not.  They just did it.  So you guys should be happy that
Matt, Jeremy, Derek and Rob are even considering talking with you guys about
major changes to the core of Euphoria!

Now, a last bit of "advice" I'm going to give you guys as far as Open Source
projects are concerned.  Untill the 3.0 release of Euphoria, Euphoria has been a
closed source project, maintained by 1 person, and 1 person only.  The Open
Source life span of Euphoria is still very very much in it's infancy.  You guys
want to see features get in, get involved with the Development team, help them
out in any way you can.  You want to not see a feature get in, then do it
constructively.  Don't just go off half ended, and say that this feature
shouldn't be done, cause it's going to create "Bad code", or "Unreadable code". 
Yeah, get over that, no matter the language, even Euphoria, Even Great old Basic,
or C/C++, Java, Ruby, Perl, Python, PHP, __HTML__ can have the most god awful
code in it, that you wouldn't even begin to understand, if it's not done
properly.  Some people do this on /PURPOSE/, to prevent people from being able to
reverse engineer their stuff.  Isn't it lovely?

All I have to say, get involved, get involved constructively, not deconsending. 
These people are doing it, for the love of the language, they aren't getting paid
for it, they aren't there to serve your every whim.  And they are certianly not
going to bow down to presure, without good cause.  Make the cause good, make the
argument constructive to the "Subject" at hand, show examples, give your "CLEAR
REASONINGS" behind it, not some quick and easy cop out, just to say your right,
and everyone lse is wrong.  Open Source code does not work that way, and often,
is the death of many open source projects.  Do you really want to see Euphoria
Die?  If you do, then go someplace else, your not contributing in any way good to
the development of the language, unless your being constructive.

Yes, I use the word "constructive" quite a bit in this post, cause it is what
Open Source is all about.  Being constructive, between yourself, and the
development team of the Open Source Project.  Heed my words carefully, and
understand, I'm taking this from my own perspective, from leaving Euphoria, for
an Open Source Language, and moving on to work with other people /ON/ a open
source project, and creating my own.  Cause trust me, you will learn this, one
way or the other.

L8ers,

Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...