Well, I went to dinner here in Bathurst with the folks from Charles Sturt and Nathan Bailey of Monash showed up for a meeting tomorrow and James Dalziel of LAMS and MacQuarie fame was there as well.
Here is a cool picture of Nathan Bailey, Mike RIbecci, and James Dalziel - Matt is just to the left out of the picture.
http://www.dr-chuck.com/images/2006/10/index.php?img=31-10-06_054806_01.jpg
What a trip - San Francisco, New Zealand and Australia. Tomorrow morning - back to San Francicso and then home :)
Brad Wheeler send around the following excerpt from the Chronicle of Higher Education:
http://chronicle.com/wiredcampus/article/1632/a-marriage-of-open-source-and-commercial-software.
It is a nice article about how there is often a place for a blending of commercial and open source products at an institution.
It also invented the phrase "Open Source Software is Free - as in Free Puppy".
This is just one opinion - Sakai deeply loves both Location and Injection - both will be around for a *long* time.
My rough rule of thumb actually is to use Location in tool code and Injection in Service code. Although my personal example code (Presentaion tool) uses Injection for the tool jsut to show how cool I am.
Here is my logic - feel free to disagree.
- Tools simply want a service - they just want to find it and use it - end of story - there is little reason to expect that a system admin will want to wire the resources tool to use one UserDirectory impl where the chat tool uses a different impl. I think that injection is most valuable when there is a "re-wire use case". I like to see tool code more declarative and easy to read and modify. For example when we just write tools in PHP, Ruby or JSP, there will be no "injection" - just use locator and be happy. Location is why we can easily do thins like JWS, JSP, etc. DO don't diss location - it is your friend.
- Injection is *hard* to debug - sheesh - how many people put log statements in their setters? If it is harder,why do it unless there is some value that we can identify. Why make all the poor saps writing tools do Injection to be cool? *Write less code when possible*...
- I also am not a fan of moving code from Java to XML - some folks *love* the notion that they write 1000 lines of XML so they reuse 200 lines of Java instead of just writing 400 lines of Java. People will say "my IDE" checks the syntax of the XML file - I say - sorry - vi does not do this :)
- Services are where rewiring is likely to happen. For example, we might want to give the SiteService a version of the UserDirectoryService with some little aspect thrown in to log the interactions (silly example) - or perhaps we just want some cool system-wide parameters that get poked into things.
- It *is* possible to confuse Spring and overwhelm it by asking it to resolve too much wiring across the whole system at initial startup - using location allows resolution/lookup to happen without forcing Spring to figure out startup order - the complex bits are wired *together* at startup - and then those simpler things where you just want to do look up are resolved later in system-wide lifecycle. So for me - we should use wiring when there is a benefit - not just because it is seen as "cool".
- I also strongly prefer injection in Services as this may someday allow us to go "distributed" or "SOA" or "eFramework" - by wriging in clever proxies instead of the real impls - we can seamlessly wire up a Sakai system that puts different servers on different physical hardware. Service injection is *far better* for this use case than location - in some ways if we wired services to each other with location only this distributed SOA implementation wouldbe much harder.
- Also for something like setting the provider - we would be insane not to use injection and Spring - there is no more elegant way to do this - especially when bean properties are enhanced by system-wide properties in Sakai - so the easy stuff comes from one place - while the tricky wiring is always available when you have a need.
Again - this is just my crusty old school feelings and I don't push my ideas on others - so there is a wide range of approaches across Sakai - This is cool and a strength of the flexibility of Sakai.
Yesterday I saw rain in Phoenix. I never thought I would ever see rain in Phoenix.
Here is a video of rain in Phoenix that I offer as proof:
http://www.dr-chuck.com/images/2006/10/index.php?img=05-10-06_180104_01.3gp
Cool thing - it is raining again today!
A friend asked me to comment on which language to use and which was better. I whipped up this response.
I also was at the bookstore and skimmed a idtiotic book called From Java to Ruby written by Bruce A. Tate. It is a fun read but the guy is a moron. it got me thinking.
Don't get me wrong - I like Ruby and see it as a neat point on the evolution of languages and explores neat space blending framework and language - but it is only a point solution and the book suggests that Ruby is a whole new species and will be LAMP - Hah!
There are a lot of contenders for the "What will be next after C# and Java burn out". Ruby is cool but does not raise its head above the crowd.
This breaks down pretty much along these lines:
- Syntax does not matter
- Strong typing versus weak typing and interfaces and implementations is a real difference - effectively some languages code the contract into the syntax of the functions while others encode the contract in the logic of the code (like how they parse an XML dom). Strong typing is needed when projects get really large and complex and have long lifecycles - like 10 years plus. Small applications for one purpose - do not need strong typing.
- Frameworks do matter - when you move outside the core language into image processing or multimedia - what does it feel like? Good or bad? Most people pick a language because of the frameworks it supports as much as the syntax of the language.
- Interpreted or compiled - hardly matters any more - they are all interpreted - they are all compiled
- Interoperability does matter - one thing for sure about the future is that there will be more than one language out there - support for data interchange formats is critical to any language and/or framework - new languages "get this" and build interoperability in - old languages have to add frameworks.
- Performance is not a language issue - they are all fast
- Performance is a framework issue - the easier a framework is to use - the harder it is to performance tune - this leads to an infinite number of religions around frameworks - "tastes great - less filling".
When new languages finally topple old languages - it will likely be because of the flaws or creakiness in frameworks - not the language itself.
I wrote this up in an E-Mail discusison and figured that it was kind of cool so I figured I would blog it. Feel free to disagree.
Looking at the base level operating principles of Sakai - just like Apache - we believe in open source, open community, meritocracy, do-ocracy, and the collective wisdom of the community. In a sense we depend on intelligent brownian motion to "do the right thing". We know that there is no way to take something as rich and diverse as Sakai and orchestrate it in the classic top-down corporate sense.
Our bylaws are very careful not to "appoint" anyone to positions of "power" like in a traditional corporate organization - no volunteer reports to any other volunteer or to Foundation staff. Viewed from an individual contributors perspective we attempt to be as egalitarian as possible. We never want a new member of community to feel that they "report to" anyone or are to "take orders" from anyone - we are all created equal - anyone can by their own investment and commitment - do anything they want to do in Sakai.
That said, Sakai is not random - nor do we make major decisions "by committee". Tactical technical decisions are made by those volunteers with commit responsibilities for the various components of Sakai - we strongly encourage open engagement with the entire community - this is often teams of 1-5 people who have long term commitment to that software - but at the end of the day - the project teams for the parts of Sakai self-determine - just like Apache.
On top of that we have paid staff - the Executive Director, Project Coordinator, Branch Manager, Framework Architect, QA Director, and others (not all are paid at this time - some volunteer to be Foundation staff and all that entails).
This group of folks *is* coordinated and works together in an org chart way - people are paid - so this is "OK" - none of the volunteer developers "report" to the Foundation staff. The Foundation staff are there to serve the community and help the community communicate and coordinate amongst themselves.
There are times where the Foundation staff assert more control - that is not around development, but instead around releases and long term direction. Foundation staff consult the community all the time, but ultimately are empowered to make some decisions. For example, the Foundation staff will decide what goes in each release and when the release will happen.
The Foundation staff insure that we keep the community together - they are naturally motivated to listen to the community and do what is best for the *overall* community - not just individual developers or organizations. If the Foundation staff get uppity and start making bad decisions as seen by the community - we will fork the community and organizations will cease to see Sakai as providing value and Foundation Staff salaries will go away and we will have to lay off people. So the motivation to be responsive to the overall long-term needs of the community is important - the consequences of a Foundation staff member alienating the community in the long term are very tangible.
The Foundation staff in their coordination role can affect long term direction by giving advice to the volunteer community. Mostly this comes in the form of "I want to try X - do you think this will make it into the release?" or "Is there something that I should do to this tool or feature to make sure it fits into the release?" This way folks can have some sense of their individual work fitting into the always evolving plan/roadmap. Foundation staff do their best to publish the plans/roadmaps - always encouraging community comment to make the plans better.
That said - decisions do get made - and there are examples of decisions where there are several conflicting strongly held opinions among the community - we do not wait until everyone agrees - we make a decision and move on. Hopefully in the fullness of time these decisions will be "right" more often than not and those who were in opposition - will either be satisfied some other way - or satisfied later - or will change their opinion in time when it turns out the right decision was made. If the wrong decision is made - that will also become apparent in time and we will re-adjust - hopefully learning from our experience.
And if in the final analysis, a decision seems particularly difficult to resolve - the Executive Director makes the decision. Often the toughest decisions need to be made quickly or a lot of effort will be wasted.
In summary, Sakai takes great value from the "brownian motion" of the community's ideas and enthusiasm - it is the source of Sakai's energy - but we do have a few folks who try to steer things so as to move in some coordinated direction. There are checks and balances (very strong) that make sure that the folks "steering" Sakai do not drift far from the overall goals and needs of the community - their salary depends on keeping the overall community happy in the long run.
If you look at other open source efforts - including across Apache - those projects with some type of identified leadership do much better than those projects which are just a committee with no "committee chair". Projects which have leadership like Jetspeed (David Taylor) and Pluto (David DeWolf) thrive much better in the long term than projects like WSRP4J where when you ask if it is OK to do something - then answer is effectively "sure - whatever". The key is making sure to only have leadership that "adds value" and is "service-centric" - not leadership that becomes oppressive and power-centric.