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 ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com
_______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
