Brent Severance – Four Gold Medals – Horseback Riding

We had had our own little “mini-Michael-Phelps” event today when Brent won four gold medals at the Michigan state-wide 4-H show.
The state-wide show is where riders who do well in 4-H fairs and horse shows around the state during each summer are invited to compete at the state level with riders from around the state. The show is always held at the end of the summer at the Michigan State University Livestock Pavillion – it is a great event with everyone bringing their best game.
Brent has been riding as part of his physical therapy for Cerebral Palsy since he was five years old and he has been in 4-H since he was 11. He is now 17 years old so he has been riding for 12 years. Bonnie DePue (who runs CHUM Therapy) feels strongly that having therapy riders compete in 4-H is an important part of their therapy – it serves to motivate them to do their best and gives the participants a handicap-friendly event several times per year.
A bit of background:The 4-H has a special class for differently-abled children – it is called the Proud Equestrian Program (PEP). There are special classes for handicapped children to compete against one another – 4-H supports the PEP classes across all of its activities. They alter the activities to make them accessible for all. They do things like allow the PEP riders to ride first – in the cool of the morning – before the heat of the day as well as have specially trained judges for the classes. The classes are still quite competitive and riders are expected to perform flawlessly to the level of their ability to get the top ribbons. This is not just about participating – it is about competing – competing with yourself and striving to do your best in the ring with other riders.
Because the horse gives even very handicapped children mobility in a competitive situation, for many severely disabled children – 4-H PEP is likely the only time in their life where they will compete and earn an award in a physical competition. Children do not have to get a blue ribbon to be very pleased with their efforts and create great memories for their life.
Back to Brent’s story:Brent has been riding for six years in the PEP program and this was his last year in the PEP program – next year he moves into the regular 4-H program and will compete with all the other riders in 4-H.
So this year’s state show was his last competitive ride in PEP. Brent competed in four events:

  • Walk-trot Equitation (unassisted)
  • Horsemanship Challenge
  • Pattern Riding
  • Obstacle Course

The classes were pretty small – Brent put on his best riding performance ever (at least the best I have ever seen). He sat up tall and proud and hit every mark perfectly and did each of his gait transitions with careful focus. It did not hurt that Bonnie had let him ride Splash. Splash is my favorite horse of all-time. Splash belongs to Chris DePue (Bonnie’s son) – and Splash is very well trained in jumping and equestrian events – Splash is so good with the children and a great horse to ride (I always tell Splash that she is my favourite puppy – because she is so cuddly).
The announcer knew it was Brent’s final PEP ride and as the Gold medals racked up in each of the events, the announcer let the crowd know that this was Brent’s last PEP event ever – which made him even prouder of his work.
At the end, Brent had won four gold medals and won all of the classes. The judge/announcer told him to take trot Splash around the arena for a “victory lap” – which Brent did to a standing ovation and more than a few teary eyes.
The 4-H state show is very competitive and I am guessing that four gold medals is possibly the record for a single individual to win in a single state show. Like Michael Phelps – this may be something that will not be repeated. Brent was at the top of his game – at the end of a long and distinguished PEP riding career – the classes were small. Since it was PEP, there is an asterisk – But who cares!
Next year is Brent’s last year in 4-H – he is a senior. The senior year culminates with a special ride at the Ingham County Fair called the “senior ride” where the rider walks around the arena while a short story is read about what they have done in riding and what it means to them. If you come – bring tissues.
By the way – you are always welcome to donate to Bonnie DePue’s – CHUM Therapeutic Riding at www.chumtherapy.net. CHUM Therapy is a non-profit organization that is dedicated to making this world a better place through horses interacting with handicapped children.
Bonnie understands that the purpose of CHUM is far more than one hour of physical therapy per week for these children – and I publicly thank her as often as I can.
You can see some online videos of CHUM Therapeutic Riding that I have produced over the years.
A video about Brent.

Rant: Wishing we had someone who worried about the “whole release” when decisions are being made

Sorry – this is a rant. The rule in rants is that you don’t have to be logical – you are just mad. So I apologize in advance… I don’t intend for this to be about anyone in particular but there are some example things that I call out – just because I call something out – it does not mean that it is a bad idea – and certainly does not mean that I am upset at a person who is just trying to do what they think is right. I am ranting about governance and process and approach – and community culture – not any single individual.
Back in 2004 and 2005 we had a “chief architect” – that was either me or Glenn – or most likely a combination of both.
The major role of the chief architect was to worry about the the entire scope of the Sakai release and not look at just their little corner of the code base and be “selfish”. Having global conventions and rules that were enforced across the code base – make everyone’s life better. And to really *have* global rules – you need policing activity and judges and you need to tell some people at times to “stop that!”.
Now a few people in the community over time looked at this police/judge (chief architect) role as a great privilege and a glorious source of ego building power. Actually this role is one of the crappiest roles in any project if it is done well. Everyone is pissed at you all the time and sometimes a person who is told “no” they go find a few friends and come at you with a mob when they get really mad. Sometimes the chief architect is wrong because they needed to be educated and has to publicly admit it and reverse their position. You cannot survive the chief architect position and keep your ego – it is beaten out of you if you do the job right.
—Sub-Rant—-
The key in any open source project is that leadership is action – not position. People who come from organizations where leadership is not valued and instead management is the more valued than leadership – they react to titles and positions differently. People who are sadly stuck in and/or grew up in in manager-oriented organizations get all veklempt about titles. Those who have seen leadership truly modeled really hardly care less about the title and focus on what a person *does* – in organizations that value leadership – management activity is seen as another task that is equal in importance (and often less rewarding than) non-management work. Management generally is the act of “taking care” of the non-management people – and since this is tiresome – it is often well-compensated. But in truly leadership-centered organizations – having a title of “manager” or “director” does not automatically make you better than other people in the organization – you must earn your rank in the pecking order based on what you *do* and how well you do it – not the fact that you have a fancy title.
So, these people from unenlightened organizations see the chief architect role as something that has a lot of power and little responsibility – and since they have never experienced nor understand real leadership – they treat that person like all of the useless troll managers they have met in their life and either whine and complain or kiss butt / play politics to get what they want.
—-End-Of-Sub-Rant—-
Back to the original rant.. So the chief architect role is an unloved and unappreciated role – they make decisions and tell people “no”. But here is the key – they also take responsibility for the *whole code base* and the whole release process and after release process and the production issues and and and – if something drops through the cracks – this person picks it up – or at least tries to catch things and warn folks – or get the right folks involved.
We don’t have a chief architect any more as best I can tell. I am certainly not it – and I am glad – it was a role that kept me nervous all the time and I was glad that while I had that responsibility I was paid full time with unlimited travel budget to do nothing other than guide the Sakai community – it is so engrossing – that it does not blend well with other tasks.
It is not clear exactly why we don’t have a chief architect role any more – the two biggest contributing factors are (a) management types wanted control of the core decision making processes – so that decisions would be made manager-style (lots of meetings, lots of politics, lots of quid-pro-quo, lots of compromise, and none of those loud technical people involved in the process) and (b) because we just got too big for one person to know and watch it all. The reality is that it is a little of both.
However we got here – we no longer have one-stop shopping in terms of when things break – who do we ask and/or blame. We make technical decisions Murder on the Orient Express style. The deed is done – and there is no one to blame because everyone naturally takes such “fractional” responsibility.
The way this works out in Sakai is that someone proposes some broad new approach in a meeting or on the list. A few people give a +1 affirmation or grunt assent in a meeting – the person walks out of the interaction claiming they have a “mandate” and proceeds to take us down this new direction.
Often the proposals are called “improve our XX approach to be in line with industry best practices” – and then this gives folks a carte blanche to change our overall direction in some small way. So they go off and change our overall direction – and if challenged – they say something like “the folks in the meeting at XXX seemed to think this was OK”.
Usually I am the one opposing things – and usually I am the lone opposition voice (or at least the only one who has the guts to try to say “no” out loud). And so it looks like the “people advocating moving towards best practice” (apple pie, patriotism, world peace) versus the old cranky guy.
I am vastly hampered in my attempts to be critical about dangerous changes in direction is because the people I am arguing with are all smarter than me technically – and I know that. The top 20 people in Sakai are so damn smart it is not funny – they are all way better developers than me. But they are also often young and in a hurry and do not have experience with the long-term pain of seemingly simple decisions.
As an example of long-term pain, in late 2003 – as chief architect I decided that Java Server Faces was a good UI technology. It turned out to be ABSOLUTE CRAP! The effect of my decision was to cause great harm to this community and my estimate of the wasted effort from that single decision to be about 2-3 million dollars across Sakai – it doomed several projects to lose years of progress – particularly Samigo – I feel horrible about the decision to rewrite Samigo in JSF. And the new chat is in JSF – AARGH. I live with this decision and publicly admit my shame on this over and over.
The key lesson is not that somehow I am stupid and all the other people in Sakai are smart. The key is that sooner or later a mistake will be made and that a bit of caution is a good thing – and most importantly – the pain of a decision is often not evident for months or years after the decision was made.
We are making decisions now of the same magnitude pretty regularly – and we won’t know whether they are right or wrong for a while. I have opposed both of these vehemently – and folks just treat me as the “old cranky guy”.
– The use of Wicket in the main SVN and Sakai 2.6 is absolute crap – it comes up with ugly warning messages about Wicket configuration and this is ta test version…. Aargh.
– The independent versioning of every little piece of Sakai – I call these “vanity versions” – is absolute crap
Perhaps “absolute crap” is to strong of a term here – but at least lets *delay* these decisions and explore them in experiments with production systems before committing the whole community and whole release to go in the direction.
But NOOOO – someone got three “+1” votes and one “-1” vote from Chuck – and we all discount Chuck’s vote to be “-0.001” because he is just an old cranky guy who says “no” to everything.
I am an old cranky guy because I know that we are making these decisions too quickly and with no real consideration of the long-term consequences three years from now. We have no chief architect and we have no structure that moves us toward being conservative in the overall direction of the product. Our governance structure lets major shifts in direction to happen with the agreement of 3-1 vote out of 100 developers.
Another thing that annoys me – is that we *do* have smart conservative folks in the community – other “cranky people” who are generally nervous about too much change – too fast. But they are also *verrry quiet* people.
In a few years – the code will be a swamp. Making a release will be like finding a needle in a haystack.
Now – all is not so dark. Here are a few really brilliant points of light in what we are doing:
– The Kernel 1 work is brilliant – it took over a year to make sure that this was a good idea – Ian gave us many opportunities to look at his idea and he patiently did it over and over again each time someone raised a question or issue. He did his work as a branch and let it become nice and boring before we switched to his new practice. And the switch was awesome and pretty much flawless. Even with this much preparation there were a few things that needed thinking through after the switch – but with Ian as our leader – we could work through decisions while letting Ian keep the big picture intact.
– Take a look at this JIRA – http://jira.sakaiproject.org/jira/browse/SAK-11875 – Look at the reasoned conversation – look at the depth of thinking look at the attention to detail – and most importantly look at how many really bright people brought their thinking to the problem and how deeply they thought about the problem. We are blessed to have 10-15 people who are smart enough to see the whole code base and work collaboratively to narrow down a really hard problem and produce a superb solution to the problem. So we have 10-15 people who have talent to be architects.
But we still have no chief architect – we still do not have someone who feels pain when the release breaks – like in the Orient Express – when the release tanks – no one feels responsible for more than a small part of the release – and the cause of the failure is likely to be someone else. The math is simple – if you own 5% of something and the whole thing breaks – there is a 95% chance that it is not your fault. Except of course for me – I screw up more than most so even though I touch about 5% of the code – if something screws up – it is 10% chance that it was my fault :).
So we have these people that make long term decisions – fight fiercely over my lone opposition and win – drop in their change and then run for the hills leaving the community to do the long term support of their new decision – and the sad bit is that 2-3 years later when the overall impact of the decision comes home to roost – the people who screwed it up will likely be gone and so there won’t even be the satisfaction of “I told you so”.
This is all OK – open source communities have people that come and go and new folks pick up from old folks – this works except when there are major direction shifts or major changes in community commitment that slip in under these “+3” votes.
Enough whining Chuck! What is the solution?
A year ago – I yearned to go back to the Chief Architect Model. I did not want (and do not want) to be the chief architect – I just wanted there to be one. I wanted to have the feeling that someone was watching over the work that we all do – and would swoop in and save us from ourselves. It is nice to know someone has your back. We kind of have that for the Kernel in Ian – this is cool – I want to help and cooperate with Ian and I hope we all support Ian and help him – he volunteered for a really painful job. Don’t look at this as a “power grab” – look at as a “life sentence” that he voluntarily accepted – be thankful and appreciative – send Ian a “thank you note” once in a while – buy him a beer when you have a chance.
What do we do in the rest of the SVN where most of the current crap is happening?
First, we clearly have enough talent to do this together and if we focus on the “one person” approach we leave a lot of talent on the table unused and slow things down to a crawl – and we also suffer from the fact that no matter how smart one person is – they have blind spots and they have personality that creeps into their decisions and pre-conceived notions that creep into their decisions over time – so many eyes on the problem of the size of the main SVN are a good thing. And it cannot be Ian – he is used up on the Kernel now.
Here are my recommendations:
– Bringing new technology in the core – like Wicket – needs to be done with at least one semester of production experience with software at more than one site. If there are folks who think wicket is the “next best bright shiny object” – let them prove it and let them vote with their production instead of the very inexpensive “+1” in an E-Mail. Wicket should not go into 2.6 – let a few adventurous sites run it and see if wicket has memory leaks or the internationalization sucks or it fails on IE7 (or whatever) The vote that matters is the “who ran this in production” vote – not the vacuous “+1” votes on the dev list. People need to *Stop* thinking about this as an ego issue. I am writing lots of code that is new stuff in Sakai – doing this in trunk of the main release is scary for me – my IMS tools will be run at UM for a whole semester before I would even make the slighted *peep* about them in the main release – this makes my life *better* not worse. It means that when they go into 2.7 – I can sleep at night knowing that I won’t be the one who crashed Rutgers production because I pushed my stuff into the main release before it was production hardened.
– When people want to do something that will make the “release process better” – like this crazy idea that we need 40 versions of things in the main SVN instead of one. Maybe this *is* a great idea – if it is a great idea – lets try it one place and get through a release and see if the process *IS* better. And then see if we can actually make a release with the “glorious” new ideas in place. If we do it only a little bit and it turns out to be a horrible failure then we back out the little bit. If we convert the whole SVN to the new approach and find out half way through QA that it was a bad idea then we have a massive back conversation. And folks – good ideas have staying power. If it is a good idea – it will happen in the next release – folks don’t forget about it – if the simple use of the new approach shows the glorious way forward – people will rush to the new approach. And maybe these folks who are so “smart” about how to change how we do the release – perhaps they ought to try to *do* a release with their proposed ideas before they just check it into trunk. There is a long way between Sakai compiling in a developer environment and Sakai having 100% squeaky clean release artifacts.
We can make these decisions collectively if we just do things more cautiously and folks who advocate new large-scale directions are willing to be patient. Frankly the last thing we need is someone who wants to make some global change *right now* because they want to get it done and then move back to some other job. This is a major red flag for me – it means that when their great idea takes a crap – they will be busy on something else. Making folks wait also tests their own conviction that their ideas is really good.
OK – so now my coffee cup this morning is empty so it is time to wrap up the rant.
All I am saying is give peace a chance. Actually no – his is what I am saying:
– Quit thinking that +3 is a mandate and sufficient justification for major change – the justification for major change is *proof* that it is a good idea.
– Take a conservative approach to new directions and new technologies – make them stand the test of time for 6 months before we dive forward – it is hard to go back
– Lets make a culture that makes it OK to oppose something. While I am the guy who publically does a “-1” on stuff – I do it so often that my credibility is shot – at least it is shot enough that my -1 alone means pretty much nothing when the proposer knows they are smarter than me (a common occurrence).
We have a lot of people with a long history of experience watching decisions happen and watching things hurt later because of those decisions (and yes most of the mistakes were mine) – but even though it is different people making the decisions – the mistakes are and will be the same – the core reason I made a mistake was when I was in a hurry and was not willing to try something out in the small before it because our “direction”.
Lets learn the “red flags”.
– A major rewrite that surprises the community right before code freeze
– Something that claims that it will *improve the release process* from someone who has never done a release
– A major new technology that one tool writer “discovered” and decided to use
– Anything where someone seems to be “in a hurry” or trying to slip in under the deadline
Change is essential – if we stop moving we start dying. All the decisions that have come back to haunt me over the past five years were “yes” decisions. It is easy to say “yes” – it is harder to say “no”. Just saying “no” is also a bad approach – no can be wrong as well.
We can recover far more gracefully from a wrong “no” decision than a wrong “yes” decision. If a “no” decision turns out to be wrong – we just turn it into a “yes” later. We hold on to the status quo a little longer – for those of us in this for the long term – we can be patient.
A bad “no” decision means we endured a “stable but sub-optimal” situation for a little while longer. A bad “yes” decision can cost us millions of dollars in wasted time and effort.
If a developer or team does not like being told “no” and want to make their own decisions – or thinks that Sakai is too conservative about changes to its release process or new technologies – and prefers a “more agile” approach – then just move your to contrib. You have 100% freedom in contrib – no one will tell you what, when or how to do something. People can put your code in production and if it craps out – then it is *your* creditability that drops and not Sakai’s credibility.
What I am looking for that will tell me that our process is healthy is when we as the community learn say “no” to something once in a while. Or at least we as a community make a strong statement “Please slow down” – to *something*. Once we as a community can learn to say “no” once in a while – maybe we can get to the point where our collective wisdom is better than a single individual making long-term decisions.
At this point my assessment is that we are worse off in terms of making long term decisions about the product than we were in the 2.3 era. From the 2.4 release and onward – we switched from the “chief architect” model to the “collective wisdom” model. We cannot and should not go “back” because one person cannot hold this all in their mind – but we do need to go “forward” to a point where we are truly reflecting on choices and making hard calls – and firmly telling folks “no” or “slow down” in certain situations.
Until we do that – our code releases will get mushier and mushier and the maintenance branches will become more and more important. This is an indication that our process for managing trunk is not working as well – and we fix things when we have a branch-manager (chief architect for the branch).
I would like to see us making better decisions in trunk – and making the branches – truly maintenance.
End of rant.
One of my favourite sayings is that “A project is doomed if the smartest developer is the chief architect”. Having someone as chief architect who is smart but not the smartest sets up a natural balance-of-power and leads to well reasoned decisions.

I had a Strange Dream Last Night – About Google App Engine

I must be hacking too much. Last night I had a very vivid dream about the Google App Engine.
In my dream I am reading my E-Mail and I get a note from the Google App Engine folks that I have had too much traffic to my simplelti.appspot.com site and that now I had to start paying for it. I was all freaked out because the site was down and I could not figure out how to pay for App Engine (I don’t think it is possible yet – they just shut you off).
So this was really disturbing because I could not figure out how to get it back up.
One of the first things this morning was to update the site to add some screen shots of dokeos (http://www.dokeos.com/) supporting SimpleLTI (thanks Daniel) to the site. And after I finished uploading to the site – I realized that it was only a bad dream – whew.
It was a pretty vivid dream – the visual images of E-Mail reading in the dream were very accurate. This was part of why it seemed so real.

Google App Engine Rolling Back an Update

If you had an App Engine update go awry, you may need to roll it back. You will get a message like this when things are messed up and you try to “Deploy Application”:

*** Running appfg.py with the following flags:
--no_cookies --email=acct@gmail.com --passin update
Password for acct@gmail.com: Scanning files on local disk.
Initiating update.
2008-08-12 08:51:32,117 ERROR appcfg.py:1334 An unexpected error occurred. Aborting.
Error 409: --- begin server output ---
Another transaction by user acct is already in progress for this app and major version. That user can undo the transaction with appcfg.py's "rollback" command.
--- end server output ---
If deploy fails you might need to 'rollback' manually.
The "Make Symlinks..." menu option can help with command-line work.
*** appcfg.py has finished with exit code 0 ***

The solution (paths from a mac) is to running the command:

python /usr/local/bin/appcfg.py -verbose --no_cookies --email=acct@gmail.com --passin rollback simplelti

“simplelti” is the application directory – you need to run this where your application is a subdirectory.

Why Would Anyone Want to Work on Sakai?

A couple of days back Mark Norton wrote a blog post with the above title. His post is at:
http://technomark.blogspot.com/2008/08/why-would-anyone-want-to-work-on-sakai.html.
It was a well written post, but it actually answered a different question. Mark’s post answered the question, “What are the barriers to a new person finding a way to contribute in Sakai?”. His answer to that question went into some excellent detail about our documentation, etc – a nice post summarizing many obvious and real issues. The sakai lists buzzed about it for a while – pretty much in agreement – as usual,once the buzz dies down, folks got back to work – after all we have a code freeze coming up pretty soon and we all have work to do.
So I would like to take a crack at Mark’s question and really answer it. I will use first person a bit and focus on why I want to work on Sakai.
This was my first summer “off” in my whole life – I have a 9-month appointment in the Michigan School of Information and I get paid all summer long – I could have sat by a stream fishing all summer if I liked. Also I have good consulting opportunities where I can make money during that summer spare time as well. Why, then is it that the thing I spent more time on than anything else this summer was working on Sakai. I made no money for this work and it certainly took away from my fishing, motorcycling, landscaping, basement remodeling, book writing, consulting, and camping I had planned for the Summer.
Here are a few reasons that I spent more time on Sakai than any other thing this summer:
(a) A million teachers and students use our software every day. Every day. Learning is probably the most important thing humans do – we are part of that every second and every day. We the creators of Sakai have a purpose. As described in Matrix 3 – it is not just important to know “What?” it is important to know “Why?”. When you are part of the Sakai creative force – you have a very clear answer to that elusive question – “Why?”
(b) 200 Schools use our software as their enterprise solution – for many of those schools – Sakai is the only alternative – if Sakai fails to run for a minute, hour, or week – the technology bit of learning stops for those schools. The teachers, IT staff, and administrators at those schools took a risk on us and we need to honor that risk by our efforts and energy.
(c) 150 other fellow committers – many of whom are far more dedicated in terms of time and energy than me – many of whom I *know* would pull several all-nighters in a row if their code broke – and would pull at least one-allnighter if it was my code that broke – there is a sense of pride and responsibility that is contagious. Once you have earned the right to be responsible for a critical element of Sakai that others depend on – no one takes that lightly. Like in the military – we know that the person to our left or our right would do whatever was needed to help get us out of a tight spot and we know the we must be ready to do the same.
Ultimately being part of the creative force of Sakai is like being part of a company – but within a context that is academic – within Sakai we can expect respect and admiration for our work from our peers (and constructive commentary or criticism when appropriate) – we are doing research together and each time we make a breakthrough individually – we move the whole community forward together so we can focus on what is next. With the free flow of thinking and the free flow of code and the free flow of innovations – we can rest assured that we are not wasting our efforts – what we are doing is making a difference – even if it is performance tuning in the 2-5-x branch.
Of course when you take responsibility in something like Sakai – you are putting your ego on the line. If you make a mistake in Sakai – usually it will be caught in hours or a few days – someone from 3000 miles away will let you know the mistake while the 1500 people on the dev list are watching. And then when your code is backed out or fixed by someone else – it is there in the SVN logs for all to see for all perpetuity. For some folks – this might be damaging to one’s ego. For the folks who thrive in Sakai – they see this as a good way to (a) learn new things and (b) not ship crappy software – so the public humbling is a small price to pay. This *does* hint at the fact that the people who thrive being part of the creative force of Sakai – are somewhat unique people.
This brings me to the part where I disagree with the core hypothesis of Mark’s post. Mark lists all of the things that would make it so some random person stumbling in off the street after finding our site Googling “Learning Management” – and how we can get that person to write kernel code with as few barriers as possible (I exaggerate a bit to make it interesting). In previous incarnations of this debate over the years, I call this the “Why don’t we have a Dummy’s Guide to Sakai Internals?”. My answer is and has always been, “We don’t want dummies committing into authz.” So the fact that there is no book for those dummies to get a leg up actually is a form of protection. The fact that there is a bit of a barrier to entry is good thing.
Note I: Before I go too far with this line of reasoning – I do think that we need a way for non-professionals to extend Sakai. But here is the key – non-professionals can not and will not write and should not even try to write scalable code. They should write in PHP or Python and run their application on a stand-alone server with no more than 1 or a few courses using the server. The moment you go enterprise – there is *no place* in the core of Sakai for non-professional programmers to contribute – sorry. I am as committed to making it easy for hobby programmers as I am committed to the notion that Sakai’s core needs outstanding professional programmers – hence my obsession with IMS Tools Interoperability – this allows hobby programmers to write stuff, and host it *anywhere* and mash it up into the enterprise LMS without coding in the LMS.
Note II: I am not opposed to better documentation, better training, or a better web site. Sure – when we get around to it. But to suggest that investing a bunch of resources to make it so hobby programmers can work on the core of Sakai – bah humbug!
OK – Back to my rant :)
The single most important reason that I want to work on Sakai is my fellow members of the Sakai creative force. If you look at www.ohloh.net and look at the Sakai contributors – these are some of the most amazingly talented people I have ever worked with in my 35+ year career in IT. These are brilliant people pulled from all over the world – and these are people who are very unlikely to *ever* work for a company – because these people are driven by their passion for excellence and far too often companies are dominated by next weeks revenue. Companies take brilliant people and hitch them up like sled dogs to a bunch of marketing and accounting oriented management and say “Mush” – we drag the whole company along but are treated as the low creature on the food chain. The better and stronger you are in a company setting – they more load you get and the more folks you need to drag along.
In open source projects, if you are strong – you become the leader – the strong amongst us makes the leadership decisions. And what really happens is that everyone is both a leader and a worker and an assistant and a manager and a designer and a developer – all people do all roles and the percentage distribution of their time amongst the roles if very fluid – adapting the the needs of the moment. This is the kind of collegial collaborative environment that attracts the best and brightest – and *keeps* them interested, engaged, and excited for a long time.
Working with like-minded folks in a high-stakes environment is addictive. For the right kind of people, the right kind of pressure is a good thing – not a bad thing.
But the beauty of Sakai is that you are still a volunteer – if you need to slow down a bit (like I will this September) – someone will step in and take your place. You can contribute when you have resources and coast for a while when you need to focus on other things – in a company setting – the stakes are high and the challenges are great – but your timelines are set by someone else and likely someone who has very little understanding of what you really do.
So this environment acts as a filter. The challenging documentation means that the core Sakai creative people can rapidly read and parse vast amounts of confusing information. The fact that Sakai is a million lines of code and hard to grasp in a day – it means that the Sakai creative people are damn brilliant. We have about 20 people who have the ability to go into any of 10,000 files of enterprise-scale code and work competently to find and fix a bug in virtually any file – many places only have 1-2 people with that level of code awareness. The distributed nature of our team and the lack of strong management structures lead to many independent thinkers who can make progress when goals are unclear and confusing – management is local – folks do not work as individuals – team size is self-organizing and the amount of coordination is self-adjusting. No company could *EVER* optimize its management structure from the top down as well as the way we are organized.
Now of course companies have the advantage that the “one” leader – the “Steve Jobs” can set out a quest and have it followed. Some folks in Sakai yearn for this kind of power – they want to be the “Steve Jobs” and they want to the community to listen to them – to those folks – sorry – not happening. If someone in Sakai want to invest a few tens of million dollars – that person could get their agenda pushed forward – at least until the money ran out. And then back to the organic wisdom of crowds. So we attract and retain people who cope well with a fluid organizational structure.
So all in all, the reason I want to work in Sakai is that it is one awesome open source project. It has great customers, great creative minds, and a dynamic and fluid organization structure that is constantly adjusting to the real needs of the software. We are pretty resilient to “management types” that come in with ideas and no resources. We listen for a while, learn form them and then go back to working on what we see as the real top priorities.
I watch several other open source projects in Apache pretty closely. And Sakai is far larger than any of the projects. When look at things like productivity, code quality, problem scope, community strength, etc in those Apache projects and compare it to Sakai – I see Sakai about as good as the two better projects and far better than the two weaker Apache projects that I monitor. That is pretty good.
In the 4.5 years of Sakai we have 50,000 commits. That means 30 commits per day on average 24 hours per day seven days per week – and we keep releasing and running in production. And no-one in the Sakai community was ever *forced* to do any of this work – we all choose to take on this work – sometimes our local boss told us we had to this or that locally – sure – that is your day job. But those commits are your / our voluntary contribution to the common good. The reason that we all do this is not to earn a check – I bet most Sakai contributors work to insure that their boss gives them free time to work on the problems of the commons. I don’t think that we have any core contributors that are hired and *forced* to work on the common code in Sakai. These are people who are driven to do this work.
And that is the kind of people I want to work with. Not people who are doing it just for money and not people who are doing it because their boss has threatened to fire them unless they contribute to Sakai – instead people who live for this kind of thing.
A company could not assemble a team as good as the top committers in Sakai because the people who are the top committers in Sakai are the kind of people who want to work for an organization whose mission statement is to “make the world a better place” – not “increase shareholder value”.
So if bad documentation, large and complex code base, complex install instructions, no formal roadmap, and having everything mushy and vague management-wise – contributes to the fact that our top committers are truly brilliant people – those people who made it through the complex mess to rise to the top – then perhaps we should not be so quick to insist that our top priority is to write the “Dummies guide to Making Changes to improve the Performance of Sakai’s Roleprovider.”
P.S. Mark is one of those wonderful people that I am proud to work with. And even though Mark is a consultant with no other day job – I know he spends plenty of time working on Sakai for free. Just like the rest of us, he has a day job (working for himself consulting on Sakai) and he is part of a volunteer community as well. Because he knows that this is not just about a job or money – you need to feel passion as well and you need to work on what feeds your passion.
P.P.S. A quick note to those who want to contribute to Sakai – sorry for the crappy documentation and complex code – I assure you that it is worth it once you work through it all and get to be part of the community.
P.P.P.S. I also know a person who learned Sakai with no training, no boot camp, no “many hours” with a mentor, and no visit to a Sakai Conference. She learned it quickly and learned it well. She is also totally brilliant. Non-brilliant people do not get that far. So the folks who can hack their way through the briar patch it are pretty much universally brilliant and don’t give up easily. That combination of traits a good enough reason for me to want to work in Sakai.

Sakai Copyright ECL 2.0 – Nearly Complete

One of the key value propositions of the Sakai Foundation is clean intellectual property of our shared code – while things like signed contribution agreements and copyright audits may seem like they are not in the spirit of “open and fun” – these things are what allows us to truly be open and freely work together.
They say that “from time to time the tree of freedom must be refreshed by patriots” – In intellectual property, “from time to time in an open source project “the cleanliness of the IP must be refreshed from time to time with a number of E-Mails and a bunch of small commits”.
I just cleaned up a lot of lax and unintentional poor IP practice over the past four days and I very much appreciate everyone’s cooperation and understanding as the commits rolled by.
The good news is that our IP is *much cleaner* now than it was for Sakai 2.5. There is more work to do – after my informal audit – the Foundation will be hiring experts to do a formal audit.
Here is my report to the community – sent to the dev list.

Continue reading

Today: My Favourite Feature of Python (at least for today)

I have been doing object oriented stuff before the word was coined. I have tried all the languages (except LISP) and each has bits to like. But the feature where I can manufacture a return object on the fly is simply too awsome for words!

It completes Object orientation – and yes I know – it was stolen from / homage to LISP. OK – I admit is LISP was right on 5% of its language.

Here is my snippet – a silly bit of code.

def addandsub(a,b) :
return (a + b, a - b)
print "Hello"
(x,y)  = addsub(10, 4)
print x,y

I returned a tuple with two integers – it solves the sucky single primitive return value of Java and C++ which both inherited from C.

Perhaps this is the strength of Python – it inherits from C, PERL, and LISP and mixes them nicely to make a new life form with superior hybrid genetics. HURRAY!

Update: Thanks to Stuart Feeeman from Georgia Tech, the right way to make an empty block is to use the “pass” statement.

Ok – while I am gushing – I should explain what bothers me the most is the fact I cannot make an empty bracket like this

if x < y :
# Do nothing here
else:
print "Hello"

I want to have the first part of the brace to be empty - but nooooo - I can't do that. I have to do this:

if x < y :
pass # I love an explicit no-op in a language
else:
print "Hello"

Thanks Stuart!

More Deep Thoughts on Copyright

I am not a Lawyer. I do not legally represent the Sakai Foundation in any way. I am just a teacher, volunteer developer, and former lots-of-things. This text is only to stimulate discussion and to share my opinions on these matters.
This exchange was with John Norman – it hits on some subtle issues in contribution agreements and copyright. I have some additional commentary beyond the E-Mail exchange below.
Hi Chuck
Where I am hazy is whether that distribution under the ECL 2.0 license requires Sakai Foundation to express copyright Sakai Foundation copyright in the whole work and if that in turn requires copyright statements to be removed from contributions.
There is no *legal* requirement that we *must* remove author copyright as long as those copyrights are compatible with the ECL.