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
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to