The State of Rev (Was Re: [ANN] Rodeo IDE preview video)
ambassador at fourthworld.com
Mon May 31 13:32:36 CDT 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:
> 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
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
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
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,
- 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:
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