On 1/16/07, M. Edward (Ed) Borasky <znmeb / cesmail.net> wrote:
> Brian Mitchell wrote:
> > Why not. Not a single word in that told you to go out of your way to
> > use it. Thanks goes wholly to OSS. Some of us like to innovate rather
> > than sit around. I don't think I would be productive trying to modify
> > Subversion's code base to do what I want out of an SCM tool. It just
> > comes down to the fact that I am better with Ruby.
> Yes ... I understand the need to create and need to innovate as much as
> anyone. However, there are lots of worthwhile projects that are begging
> for developers to enhance and maintain them while other developers are
> re-inventing wheels, levers, inclined planes and pulleys. And there's
> even more "worthwhile" open source software that is languishing because
> only other programmers can use it!

Yeah. I can agree here. So I am asking if anyone else has a nice
project where I might be able to lend my skills. I really think it is
a an important thing to discuss on a mailing list like this because
more people become aware of others who share their interest in
projects.

> Now in the specific case of version control systems, the main reason
> there seem to be so many of them is that different project management
> schemes have different requirements, and only the heavy-duty industrial
> strength (and expensive) ones like ClearCase have any hope of covering
> lots of those bases. And before you go beating up on ClearCase, I don't
> happen to be a big fan of it, I know it has warts, but it's what's
> mandated in a lot of places.
>
> CVS is still "good enough" for lots of SCM users, and between CVS and
> SVN, there's not much need for more innovation as far as I'm concerned.
> One of the big principles of "agile" and "pragmatic" development is
> YAGNI -- You Ain't Gonna Need It!

Right but also a little wrong. There are plenty of cases where I still
reluctantly use svn (job being one -- though they are becoming more
open to alternatives). I think it is perfectly fine to put getting
real work done high on the priority scale. It doesn't mean we
shouldn't ever ignore things that never translate to getting things
done.

Over time everyone develops a bit of an environment that seems to work
but sometime there are small gaps in the workflow. Taking the leap to
fill that can sometimes mean an interruption in real work. Trying all
day to fill these is bound to get you about as far as perl 6 }}:-).
Trying to improve things here and there might just lead to a little
more enjoyment if you spend as much time in such an environment as I
do.

 Balance in everything might we a way to look at it.

> >
> > sarcasm do
> >
> > For that, why are we even speaking multiple of anything? Why don't we
> > all use the same language, the same OS, the same hardware... and while
> > we are at it, we can have the same attitude ideas and personalities.
> >
> > end
> Well, actually, we pretty much do all use the same language -- C and
> dialects of C -- and we pretty much all do use the same hardware -- x86
> and x86-64. We pretty much all have a "File" menu in the upper left
> corner, we pretty much all have a mouse and a keyboard and a color
> graphical display, we pretty much all talk to each other using IPV4 and
> dozens of other standard protocols, etc., etc. Innovations need to be
> *compelling* to get someone to use something else.
>
> I don't really think of Ruby as innovative -- one of the charming things
> about Ruby is that it is a collection of good ideas that have stood the
> test of time. Regular expressions, classes, objects and methods, dynamic
> "typing", flexible syntax, "it's always run time", continuations,
> arbitrary precision integer arithmetic, flexible arrays and hashes ---
> these are all wheels that Ruby didn't re-invent!

Right. Sorry, I should have dropped my sarcastic comment. I just get
tired of people complaining about something that they don't find an
interest in when it is a public forum. It did let me blow a little
steam though ;-). On the other hand, it might show how far some people
take the assumption of Yet Another *.

Thinking out loud again:

People asking why we are building yet-another-ruby implementation
should probably sit in on the discussions that go in the community
before they blast out asking everyone to go work on a single project.
I bet each project has its own interesting points that they are trying
to address.

So is fragmentation the worst of the open source community's problems?
Not really. It comes down to communication. Advertising the existence
and making ideas addressable is really a break past the fog. We can
already see some mixing because of this in projects like JRuby and
Rubinius.

Brian.