Modules, and the road to 2.0

[Ethan McCutchen]

Hi all,

Several of us have started working on strategic plans for Wagn, and we'd love you to get in on the discussion.  So as not to overwhelm these lists (I'm sending this first email out to both the developer and the wagneer list), I wanted to introduce key strategic ideas chunk by chunk, rather than laying 5 years worth of sketches on you all at once.  The hope is that this will lead to richer conversations and help us focus on the most pressing issues first.  (If you're skimming, make sure you get to the two numbered questions below).

This week's chunk is our module system, the centerpiece of Wagn 2.0. 

What are modules? 

They're basically a way to add capabilities to Wagn without changing the core Wagn code.  Think "add-ons", "extensions", "plug-ins", etc.  These terms often have special definitions in special contexts (like, say, Firefox), but in this context, so far at least, they're largely interchangeable.  We're not committed to the name "module" and we don't have real specs yet, but we're committed to being able to extend Wagn fluidly, to giving Wagneers the capability to turn these things on and off, and to finding ways of doing this that are as consistent as possible with the design principles that make Wagn special.

Why is this the centerpiece? 

We think this is the best route to growing a healthy open-source community, which is one of our key goals.  A module system will:

• ease progression from Wagneer to Developer, or at least as far along that spectrum as you might care to go.  Right now it's a pretty big leap to go from creating cardtypes to editing the core source code.
• help keep Wagn's core codebase light and nimble
• mean Wagn can meet the needs of projects for whom Wagn is perfect, except this one piece that you want to build in a custom way.
• enable a lot of other features that many but not all projects want (we'll touch on those soon)
• lead to lots of integration with other systems
  

What does it mean to be the centerpiece? 

Basically, as we were looking through all the different things we wanted to do before Wagn 2.0, we looked at each feature and asked: do we really need to have this in place before we do modules?  If the answer was yes, we stuck it in the 2.0 plan. In coming emails we'll be introducing and discussing several of those features that we thought/think are necessary, but since modules are the pivot point, let's dig into them first.

What do you want from us?

For starters, here are two key questions we have:

1. What lessons, good and bad, do you think we should learn from existing module systems
2. How do you think you might use a module system?  (Help create user stories for what a good module system provides)
   

Though we don't have specs, we do have a lot of ideas, and we're even playing with some very rough code.  (Anyone familiar with Wagn's code knows that the cardtypes are already pretty modular, but there's no real module system for sharing them or turning them off.)  Over the next couple of weeks we'll spend more time discussing where things are and where they could go, including trying to answer some questions we've already been getting about modules.

In fact I want to have a quick go at one question now.  Marcus Estes asked: "When do you imagine that the first undocumented glimmers of a module system might be in place? It seems that security would be an issue in your multi-tenant environment."  (By multi-tenant he means that all the different wagns we host are using the same copy of Wagn code.)

My best guess is that in the first quarter of 2010 a few bare-bones pieces of the module system will start taking shape, but that at this point you would mostly interact with the module system by editing card content, not by uploading files, which could help address a lot of the security concerns.  Our current schedule (and everybody here knows what can happen to schedules of open source projects) has us launching the module system in full force in Q3 next year.  None of this really answers on a deep level how we'll address all the security concerns involved in the long term, but we'll dig a little further into that as we get deeper into this discussion.

Please do remember: deep geek talk (involves discussing ruby, javascript, filesystems, etc) should go on the wagn-dev list, and the wagneer list should stick primarily to user experience.  Many of the questions we're asking (including both the numbered ones above), clearly welcome both angles.

What think ye?

- ethan

--
Ethan McCutchen
One of the Wagneers, Wagn.org

Patterns.  They're not just for quilting anymore.