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.

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 →

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!

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.