A History and Roadmap of the MC IDE Project

Sat May 8 14:13:18 EDT 2004

An overview of the MC IDE project may be useful at this time, worth 
taking a moment for any of the readers here who may have joined after 
the acquisition (long, but consider it a rough outline for an eventual 
FAQ entry):

A History and Roadmap of the MC IDE Project

Phase I: Getting it going (the long road to v2.5.1)
---------------------------------------------------
The MC IDE project is an unusual animal, borne from a unique history 
giving rise to a uniquely democratic process.

While every project is different, most successful open source projects
have this in common: they are driven by one strong programmer, usually 
the one who delivered v1.0 single-handedly.  By delivering a successful,
completed v1.0, it's clear to other team members who come on board later
who's driving the show and why that person deserves to.

Many orphaned open source projects are those that never shipped a v1.0 
because they started out attempting consensus before any coding started 
(why that's so frequently the case is a complex issue probably best left 
for another time).

The MC IDE project differs from these because it already had a v1.0 (and
a v2.0 and a v2.5), but the person who wrote it (Dr. Scott Raney) had 
said he will encourage migration to an open source process only if he's 
not the one responsible for "herding cats" (a phrase that comes up a lot 
in discussions of open source project management <g>).

In the absence of Scott's day-to-day management of the project (though
he remains available for consulting and contributes to the engine) the
next question was, "Who will replace him?"

Personally, since Scott also wrote the engine which drives all IDEs, I
don't think he's replaceable.  He's not a god, but he is an uncommonly
smart person and he knows more about the engine than anyone else. 
Clearly anyone other than Scott would be a very distant second choice.

In the discussions here last summer after the acquisition of the engine 
by RunRev, the natural best second choice seemed to be Everyone.

Of course, as with any democracy, there will rarely be total consensus
on issues.  But we all agreed on one thing:  we really like MetaCard, 
just as it is and has been for years.  We all appreciate Scott's good 
work on the IDE, and note that he rarely made changes to it over its 
long history.

To allow healthy and sometimes necessary changes while avoiding a
"tyrrany of the majority" which might adversely affect stakeholders with
a minority view (always the greatest risk in establishing a democratic
system), a simple mandate evolved -- in essence:

   1. When in doubt, leave it out.

   2. Consistent with the IDE's history, any final release
      must be completely bug-free.

Since the one thing everyone using the MC IDE always agreed on is that
we like it, a mandate of minimal change seemed a simple and effective
checks-and-balances system which allows everyone to at least maintain 
the high value they've been getting from the IDE for years.

And Everyone stepped up to the plate:  there was a lot of research by
nearly a dozen people presenting the pros and cons of various open
source licenses, a lot of evaluation of various hosting options for the
files, etc.  Major kudos to all who participated in those efforts, as
they've allowed us to continue using the IDE through two new engine
releases thus far and have given us a workable process for continuing to 
use it indefinitely.

Of course when the talking's done someone needs to do the grunt work of
implementing the community's recommendations, so some sort of vote was 
needed to assess how to proceed.  Given the understandably sporadic 
participation of most of the list members, a rather loose voting method 
evolved which seemed at least inoffensive:  issue are proposed here on 
the MetaCard list, arguments for and against are weighed on their merit, 
and when a clear majority of vocal members express a consistent opinion 
if it does no harm it goes forward.

The first vote held was for how long a volunteer "project manager" (I
prefer Ray Miller's less formal term, "poohbah") would remain in place, 
and the second was for who should be first to do that grunt work.

A term of six months was decided as a useful minumum, and since no other
volunteer was as excited about doing close to nothing as I was, I became 
poohbah largely by default.  At the time, most of the groundwork was 
administrative in nature (rewriting the license for the IDE, putting it 
into the IDE, coordinating its release with Scott, replacing the 'Get 
MetaCard' page to reflect the current copyright holders, etc.) so it
wasn't very glamorous, and hence not a very compelling set of activities
for anyone.

But as I reminded the folks here in January, formally my term expired on
Groundhog Day.  If folks feel like having another vote my position from 
last summer remains:  I'll continue volunteering as code monkey until 
someone else comes along who wants to do as little. ;)

Phase II: Plugins Manager (v2.6)
--------------------------------
To allow nearly infinite extensibility with minimal effort, a Plugins 
Manager is being added with contributions from Robert Brenstein, Wilhelm 
Sanke, and myself.

With the Plugins menu now exceeding expectations, other than a few bug 
fixes here and there to accomodate engine changes no further work should 
be necessary until the next licensing change.

Phase III: Anything and Everything (concurrent with v2.6)
---------------------------------------------------------
With the Plugins Manager nearly done, if we may please consider the B5 
implementation the last word on that spec we can move on to a much more 
interesting set of enhancements:  anything anyone wants, done as plugins 
so folks can mix and match their favorites to tailor the environment for 
their own needs however they like.

There are many benefits to using plugins for enhancing the environment:

- They are easy to build, and easy to trade with others.

- As self-contained modules they encourage following the
  "best practice" of high-cohesion/minimal-coupling (i.e.,
   connections between a plugin and the host environment
   are few and well defined, so changes to one should not
   affect the other).

- They require no complicted integration with the IDE code.

- Many already exist, with more written every week.

- They allow MC developers to share their enhancements with
   the majority of Transcripters using Rev, and for the most
   part vice versa.

- It obviates the "herding cats" syndrome:  now that there's
   a feature-rich plugin system, no one has to decide anything
   anymore about whether an enhancement needs to be added --
   anyone can knock themselves out and add any enhancement they
   like; folks can use the ones they like and simply not install
   the ones they don't need.

- Jacque's "Blocker" runs well as a plugin. ;)

Phase IV: Documentation (independent of specific versions)
----------------------------------------------------------
The MetaTalk Dictionary is getting long in the tooth, with some 10-20% 
of tokens added to the language since the Dictionary was frozen in time 
with v2.5.  It's too much work to replicate the good writing in Rev's 
Transcript Dictionary, so finding a way to use that documentation within 
MC seems in order.

Rev's content is not governed by the X11 license and therefore may not 
be allowed to be included in the MC package, but it's not hard to craft 
a shell that imports that content for use in MC.  Since the MC IDE 
cannot be run without having first licensed the Rev package, every MC 
user already has the content installed on their drive.

A prototype of such a shell was developed by Ray Miller, Jacque Gay, and 
myself, and will be posted to the MC IDE group for consideration once I 
clean up a couple things in it.  There are some details that still need 
to be worked out, but this sub-project is independent of any other IDE 
considerations so it can run on its own timeline (and few here complain 
about the current dictionary anyway).

It may also be useful to draft a more complete Read Me detailing IDE 
functions and maybe even an FAQ.  But to be honest, with so few people 
using this IDE I'm not motivated to do much on those myself, though I 
would welcome contributions from others.

Phase V: Licensing Change (v2.x?)
---------------------------------
When the inevitable licensing change happens it'll require working with 
Scott and possibly an NDA, and since I maintain a correspondence with 
him and have an NDA in place I'm happy to contribute to that set of 
changes in any capacity that's useful.

Note that these changes will affect the Home stack, likely requiring you 
to replace yours. So if you've modified your Home stack you may want to 
consider migrating those changes to a plugin now that the mechanism for 
that is in place.

Conclusion
----------
Given the unique history of this project, I feel that anyone acting as
poohbah du jour best serves the project if they see themselves as merely
a conduit for the needs of the community.  Such a servitude is not at
all demeaning, but arguably a good way to further the lifelong journey 
of learning to design to meet the needs of a specific audience.  With 
any luck, by the time I'm 70 I'll start getting good at it. ;)  This 
project is good practice, and since the functional needs are few it 
usually takes little time away from billable work anymore.

-- 
  Richard Gaskin
  Poohbah du jour 1.0
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com