The State of Rev (Was Re: [ANN] Rodeo IDE preview video)

Richard Gaskin ambassador at fourthworld.com
Mon May 31 14:32:36 EDT 2010


I got so carried away with my Linux fanboism that I forgot to address 
the main point of this thread, the third-party afermarket:

Andre wrote:

> When Peter says things should be on the core product, I think he means, it
> should be available when you have the core product. The difference is subtle
> since the second phrase means that the features he want could be produced by
> anyone but should be available. If we had a Free Open Source Movement here
> (wearing by David hat now) we could fix many issues and ship some good stuff
> to solve our problems while waiting for RunRev to fix theirs. While I don't
> believe all the products could be FOSS since we all have bills to pay (I
> have lots of them), I think everyone would contribute to some Standard
> Library or set of libraries if possible.

About commercial add-ons:

Two things communicate the strength of a development tool more clearly 
than anything else:

- Examples of professional-quality apps deployed with it
- The size and scope of its third-party aftermarket

On the former, the runrev.com site has gotten much better about this but 
there's still a lot that can be done to show off what this community has 
been doing with Rev.

On the latter, RevSelect offers a lot of great stuff of enough breadth 
that it really helps newcomers understand the scope of the Rev world.

Where would Visual BASIC be without Crystal Reports? Having CR available 
along with thousands of other add-ons has been good for both those 
add-on vendors and for VB.

The same is true for the Rev add-on tools.  Unlike Andre I don't buy 
many, but when I do they've been big time/money savers:  I got Malte's 
ChartsEngine shortly after it was released and I got Curry's libDoc for 
importing Word and OpenOffice docs into Rev fields, and both of them 
cost so little compared to the time it would have taken me to write them 
myself. The ROI for those tools has been HUGE here.

I think it's natural and healthy for a viable dev tool to attract 
third-party toolmakers.  In fact, it would look very bad for Rev if it 
didn't have such tools, common as such things are in nearly every other 
IDE community.



About Rev FOSS projects:

Having participated in what may be the longest-running FOSS project in 
the Rev community, the MetaCard IDE (released under the MIT license in 
2003), I've had high hopes for FOSS tools in the Rev community.

But the fact is that MC's been a relatively simple project, since it 
started out in a finished form and has a mandate of minimal change to 
preserve its original flavor.

For most other FOSS projects code needs to be written from scratch and 
code is expensive, requiring the one commodity that's most limited and 
precious on Earth:  time.

Anything other than the most trivial FOSS projects are a rich man's 
game, requiring that one has done well enough with commercial work to 
subsidize the uncompensated time needed to give away code.

Sometimes there are well-funded orgs willing to pay for such things, as 
one of my clients does and as IBM has done with the millions it pours 
into Linux.  Such investments aren't just random feel-good but sound 
business, part of "commoditizing your compliments" as Joel Spolsky 
explains here:
<http://www.joelonsoftware.com/articles/StrategyLetterV.html>

For for most FOSS projects, it's just developers scratching an itch, and 
sharing their solution in the hope that it'll be useful for others.

There's certainly no harm in that, and much good can come from it, as 
with the two FOSS initiatives in progress at the Rev Interoperability 
Project:

- stdLib

   Inspired by a comment Andre made at the first-ever RevCon in
   Monterey, stdlib's goal is to provide a library of the most
   commonly-used handlers and functions that most apps need,
   things like getting file mod dates, managing preferences,
   etc.

- Input Validation Behavior

   The goal here is to provide a behavior script you can attach
   to fields to handle the most common input validation tasks,
   like verifying that the input is numeric, or contains a
   valid email address, etc.

Both of these projects have been slow-going, because they rely solely on 
donated time from volunteers.  But if they seem interesting to you 
please consider joining the group and diving in, either contributing 
code or even just suggestions for things these libraries should include.

Completed projects from RIP have included the "Edinburgh Core MetaData 
Initiative" (ECMI) headed up by Ken Ray, which provides some helpful 
guidelines for using custom props for storing commonly-used metadata 
about components (version, vendor, url, etc.) which has been used in 
tools like Trevor's DataGrid, some tools by Eric Chatonet, Phil Davis, 
and others, and the forthcoming update to my devo toolkit.  There's even 
a handy tool palette there named RIPEditor to make it ultra-simple to 
add and update RIP properties in your tools.

Like any FOSS initiative, the stuff that comes out of the group is only 
as useful as the guidance and code that goes into it, so feel free to 
jump in - anyone can join RIP at Yahoo Groups:
<http://tech.groups.yahoo.com/group/revInterop/>

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv



More information about the use-livecode mailing list