Michael made a nice post about my SimpleLTI effort - here are some of my clarifications as well as comments on one of his previous posts. Michael's post about SimpleLTI:
http://mfeldstein.com/secret-society-maybe-not-so-secret/
Michael's earlier post about IMS needing to open up:
http://mfeldstein.com/opening-up-the-ims/
I also can fix the typos I made in Michael's entry :)
Michael - just to clarify - my new site is not technically a subset of the IMS LTI specification. The scope of Simple LTI is a subset of the *scope* of the LTI spec - and Simple LTI takes a very similar technical approach to IMS LTI 2.0. Because of the timing of my Google Summer of Code projects and the timing of the IMS LTI 2.0 spec - I needed to do *something* so those students could move forward. Simple LTI is just one vendor’s approach to this (i.e. me and all the pals I can round up). As a Sakai developer I want something that could be in use in limited production in Sakai (and wherever else) this Fall - hence I need to do something now. The beauty of this approach is that by staying close to IMS LTI, I can help get the industry aligned in anticipation of the release of LTI - we can learn about real engineering issues in real-life situations based on real implementations - and use that to inform the IMS LTI process.
Just to be clear, Rob Abel has approved and encouraged what I am doing with Simple LTI - I sent him drafts of everything I did - I have not broken any IMS rules - the real draft is right where it should be particularly at its current maturity level. Since I work part-time for IMS - I need to stay pretty squeaky clean on the IMS rules.
I have been meaning to respond to your original post about open/closed - I gently disagree with you. There are times where it is good to have a small group, with each member having deep skin in the game discussing things without a public eye watching everything. The problem when very early thinking is happening - you need to try things and throw them away or change direction. I have now seen IMS LTI 2.0 change direction three times - each time for good reasons. If we had done it all in public all along - people would get upset each time we switched because then they have to rewrite things at some code and time. What we are seeing in the IMS LTI 2.0 working group right now is amazing progress - If the whole process was publicly wide open - I am convinced that the process would be much slower.
However the more things get settled - the more people that need to see the draft work - and IMS is set up to broaden the view of a document as it matured. You can argue that it should be faster or slower, or this or that spec waited too long to go public - but I am strongly convinced that the approach to start small and private and expand the eyeball count as the work matures is essential for nearly every engineering process which hopes to be successful.
I have done standards work in IEEE, IMS, JCP (Java COmmunity Process) and IETF (a little bit). Each of these processes to one degree or another follow the start with a few people and then grow the exposure of the document. Even though participation in JCP is free - being part of an expert-group and having access to the early work is very limited and “invitation only” - period. As part of the JSR-286 Expert Group (which got Steffan Hepper of IBM an award as Spec lead of the year in JCP) - private and a small deeply involved expert group was *essential* for over a year.
So for me, I separate the notion of pay-for-play from optimizing the engineering process. Each should be debated on its own merits - I think that you make a bit of a maistake connecting them.
Oh yeah - the IETF is the most open of the bunch - but heck - who wants to read and comments on the next rev of the Exterior Gateway Protocol (EGP) anyways? IETF could be wide open from the very beginning because of the massive barrier to even understanding what was being discussed. The deeper inside the cloud a technology is, the less it needs a quiet/private time in which to incubate.
All in all - thanks for the plug. SimpleLTI should be fun - It is also an experiment for me about how to get standards implementations dispersed as quickly as possible. Perhaps I can use the experience I gain in SimpleLTI to have a nice suite of software ready to go when IMS LTI comes into the public eye - and we can get it implemented in real products at light speed.
Posted by csev at June 18, 2008 04:03 PM