Tuesday, August 05, 2008

Why Would Anyone Want to Work on Sakai?

Speaking rhetorically: Why would anyone want to work on Sakai? Think about it. It's a bloated morass of java code written in a dozen or more styles with no overriding standards, poor (and scattered) documentation, an architecture that works well in some areas and is pretty much broken in others, etc. The learning curve is significant towards creating even the simplest tool. Even setting up a development environment is an advanced task. If you get past all that, your work is likely to language in a branch or patch and never see the light of day. Heck, it isn't even clear who to talk to, since committers are largely unknown.

Many of the people who work on Sakai do so because they are directed to by the IT organization in their university. It may be possible to expand that base, but not by a lot, I suspect. The universities that can apply resources to Sakai probably already are. My question is: how can we change how we operate to make existing participants WANT to contribute more? More importantly: how can we improve our processes such that developers who control their own time might want to participate in Sakai development.

Lest I sound too negative here, I freely acknowledge that the project has made SIGNIFICANT improvements over the past few years and this trend continues in a positive direction (I believe). That said, let's explore the lifecycle for a minute (or 10) and see if we can isolate some pain points. I'm going to focus on the independent developer case, in part because it is the more challenging one.

At four years into the project, Sakai is widely known in the educational community. There was a lot of buzz and interest initially and while that has settled down quite a bit, we still make the news from time to time. Suppose I am an experienced Java developer, perhaps in a
university setting, with time that I am allowed to use at my own discretion. I am removing the funding part of the equation to focus on other aspects, though funding is a part of the larger problem, too. So read a reference to Sakai in the Chronicles (etc) and I'm interested. How do I find out about Sakai?

The obvious place to start is http://www.sakaiproject.org. (Feeling lucky on Google will bring you right there). There's lots of good news here. Anthony has done a great job of pulling together a lot of the links needed to find things right on the home page of the web site. I can find most of what I need to get started from here. Sadly (and this is no criticism of Anthony), I also notice that the site is already pretty dated. The last newsletter is for July 26th -- I wonder if there have been any since then? The 9th Sakai conference is listed as an upcoming event. Etc. First impressions are important. Our web site needs to be up to date at least to the current week.

If I have never experienced Sakai before, I might want to poke around a bit. Fortunately, there places I can do that. Both Unicon and rSmart have test drive sites and there is another one called SakaisTheLimit (which, somehow, I have never heard of). All of these do a find job of dipping a toe into the Sakai waters (though sharks lurk below). Interestingly, there is no link to collab.sakaiproject.org on the home page of www.sakaiproject.org. Perhaps it is a bit difficult to explain what that site is for. Hmm - what is it for? (We need to re-think what collab is used for.)

In the interests of brevitiy (ha!), let's assume that I (as a developer) decide to poke around the code a bit and maybe set up a development environment. More good news/bad news. The good is that Aaron Z. has done an outstanding job of describing how to set up the Sakai development environment. Further, it is kept up to date with the latest release of Sakai (big rep points there). Following the instructions, I get my first glimpse into the complexity of Sakai. Depending on how good my developer skills are, I can get the basic environment set up and running in a few hours. Less skilled developers will probably take a day or more and the odds of them getting it right are not good (as documented in any number of sakai-dev messages). This is another pain point that we could improve -- streamlining and simplifying setup of a development environment.

So let's assume that I'm pretty familiar with setting up java web application development environments and databases. Following Aaron's instructions, I get a working Sakai environment. Building and deploying Sakai can take an hour or more, depending on how fast your computer is (K1 will speed this up some). That's frustrating, but unless me (as the new developer) understands that there is a stripped down version of Sakai (Cafe), I'm likely to build the whole shebang and that takes a fair bit of time.

Regardless, I'm into the code now. Train wreck time. How the heck am I supposed to figure out how to write an application, even something as simple as "Hello World" by looking at the code base? There are answers to this question in the Programmer's Cafe and Sakaipedia (admittedly out of date, mea culpa), but how does a newbie (even an experienced one) find that answer. Documentation is getting better, but our organization of it is still horrible. This gets worse once I start digging down into confluence. Which pages are the "official" documents? Worse still once I start looking at code - six ways to do even simple things. There are many examples of Sakai code (including in the Framework) that would (frankly) disgust me. The use of public inner classes, for example. I quickly come up against the lack of standards as well. Which presentation technology should I use? Should I code my application as a server-side one or client-side? There are many, many reasons for why things are the way they are, but I believe the state of Sakai code is one of the biggest turn-offs to developing for it. We need more tutorials, better documentation, better organization for documentation, and enforced coding standards.

Clearly these guys need my help badly (otherwise, I am out of here). I've got some time, so lets work on something. The first question is: what? What work needs doing in Sakai. Sure, I could figure out Jira and tackle one of the 2871 open issues (today's count), but I know almost nothing about Sakai. Further, I don't know anyone in Sakai or what the processes are (again, buried documentation). By this time, I'm several days into coming up to speed on Sakai and it's getting a bit frustrating. Aha! I've discovered something that needs doing: there is no utility to manage the creating of academic sessions (long story behind this that will be dropped to avoid in-box size limits). A simple tool that CLEARLY is needed. I've done JSP work before, so I code the tool as JavaServer Pages (not the best choice, but how am I to figure out what is best?). Getting it to work was a real chore, but I managed to find a couple of examples in contrib that let me figure out how to configure web.xml and get it recognized as a Sakai tool. Yeah, I did write it using JDBC instead of Hibernate (lack of standards, again), but I did add support for Hypersonic, MySQL, and Oracle - I even tested it (manually). It all works just fine. So, with great pride, I announce the completion of this work on sakai-dev and attach the code as a ZIP archive.

What sort of reaction do you think I'd get? The kindest reaction would be a patient explanation (from four different people) that Sakai has a process by which tools are written. You need to have a Jira entry. You need to propose it to the community first. You should check it into contrib. Sadly, we can't include in the next build of Sakai (in spite of the desperate need), because it is only a contrib tool and needs to be carefully evaluated and used by several universities first. At this point, we lose our new developer. It's not that our processes are bad - they are designed to ensure the best possible quality applications we can manage. It's that they set newbies up for failure. Even if he did follow the recommended procedures, chances are it would be stuck in contrib for a year or more. Our new developer is unlikely to see that this doesn't really matter as much as it appears, since a truly useful tool will get used, even from contrib and it will migrate into the release over time.

The simple fact is that we have not rewarded independent initiative. This happens over and over on large and small scales. To me, this is the main reason why we don't retain good (or even fair) developers. If they make it past the learning curve, there isn't enough reward. It's open source! If I'm not getting paid to do it or I have the choice on how to spend my time, what is the return to me? (Interested readers are urged to read Eric Raymond's book available from Amazon at, *http://tinyurl.com/5scnac)*

We (as a community) need to think hard about how we support and reward contributors. I'm not just talking about Sakai Fellowships, TWSIA awards, or even grants. I thinking about feel good responses, ego-boosting, or even simple thanks. Just a feeling that, somehow, the rest of the world (Sakai in this case) appreciates the fact that someone spend hours working on a contribution to Sakai rather than play a video game. BTW, this extends to ALL contributors, not just programmers. I include teachers who write up new pedagaogy practices, UI designers, accessibility specialists, QA testers, a CIO who shares the slides she wrote to pitch Sakai, etc. Somehow, we need need to find a way to make people WANT to work on Sakai.

Labels: , ,

Tuesday, June 05, 2007

Announcing the Sakai Registry

I'm pretty excited about the possibilities for the Sakai Registry (see announcement below). I've long felt that Sakai needed a better way to search for tools and other content, so rather than waiting for it to happen, Erik and I tackled it ourselves. The content tools are in place, Erik's done a great job of entering the intial products, and I've contracted for a series of interviews with "The People of Sakai".

The Registry is supported by contributions and advertising. The reason for this isn't so Mark and Erik can get rich (though we wouldn't complain, honest!). Rather, the idea is to have money available to compensate people for their time. Besides the interview series, I'd like to be able to pay (a nominal amount) for papers about Sakai. Wouldn't it be nice to read papers about how Sakai is used pedogogically? Erik and I have a lot of great idea for more content, but it's going to time and money to realize. Hopefully the Sakai community will help support these efforts since, in the end, they will be the ones to benefit.

To that end, we'd love to hear ideas from the community about what's really needed, or even what they'd like to see. Think about technical reviews on Sakai tools, or on-line training on how to use Sakai. Should we publish user/technical manuals? Do people like reading news articles and want more? Let me or Erik know.

- Mark

With each passing release of Sakai there are more tools to choose from, new ways to customize, and improvements to integration. How do you find what you need to make intelligent decisions?

Introducing the Sakai Registry (http://www.sakairegistry.com). The registry is a database of Sakai products: tools, services, and commercial offerings. Using simple search commands, you can browse through over 40 descriptions of tools. These descriptions include information on when the tools was released, what status it has (contrib, provisional, full support), and other technical data. Links are provided to the tool source, documentation, and related information. Screenshots are being added.

You are invited to comment on tools and later you'll be able to rate them.

While initially focused on listing Sakai products, the web site will expand over time to include other kinds of content as well. The first new content is "The People of Sakai", a series of articles about the movers and shakers in the Sakai community. You can read interviews with Joseph Hardin, Jeff Merriman, and Charles Severance. A new interview with Rob Lowden will be posted soon.

The Sakai Registry is a joint project of Mark Norton and Erik Froese. The site is supported by contributions and advertisements. If this site is useful to you, please consider making a dontation and supporting our advertisers. Money will go towards maintenance, expanded content and new features.

If you have any feedback or suggestions, please send them to suggestions@sakairegistry.com .

- Mark Norton and Erik Froese

Friday, January 26, 2007

High Tech in India

I spent a week in Hyderabad, India during the week of Jan. 7. I was hosted by Vinod Palcharla
of Oracle-India, who will be leading a team of developers to integrate certain Oracle products into Sakai. I delivered a three day tool development workshop to the team to help them get a better understanding of Sakai development and it's key services.

High Tech in Hyderabad

India is an amazing country. Everywhere I saw signs of a people doing everything they can to move from an agricultural society to an information-based economy. Not just in HiTech City, but everywhere Indian people are focused on education and connecting to the global economy. Hyderabad, like Bangalore and Pune, have created conditions that allow multi-national corporations to take advantage of low cost development and skilled developers.

HiTech City rises in a once-rural part of Hyderabad. The transition from regluar city to an enclave of modern office buildings is remarkable. In particular, the architecture struck me. The buildings all have a very modern treatment. They stand in visual testimony to the participation of India in modern age. Even the first building on this site has a graceful, circular form that I think will age gracefully, artistically speaking.

Wandering around this complex is like taking a tour of global high technology. There is the IBM and Motorola buildings. Oracle has a whole campus of buildings. Arthur-Andersen over there and many with no names outside, but quite recognizable inside.

This is the other side of out-sourcing. Easy to be critical from so far away -- jobs lost to a foriegn country. How different to see the positive impact its had on Hyderabad and India as a whole. The western world (U.S. in particular) has concentrated so much wealth for so long. Personally, I like the fact that some of that prosparity is flowing to other places. Even if it makes things marginally harder at home.

Cultural Explorations (click links to see pictures)

Work didn't leave me much time to explore the local culture and history. However, Mr. Palcharla was very kind to spend some of his weekend with me showing me Golconda Castle.
This large fortification was built by three warlord families: the Kakatiyas, the Bahmanis and the Qutub Shahis around a hill. The architecture combines Muslim and Hindu inflences with many remarkable rooms, buildings, and walls. I saw the Raj's hareem (now destroyed), his sitting room with niches for dozens of candles focused through diamons, and was treated to an explanation of the wonderful accoustics used to warn guards of enemies.

Later in the week I toured Chowmahalla Palace, a stately palace of royalty, the Charminar Monument rising from a city square in Hyderabad, and the Birla Temple. The temple was a great experience for me. The temple is constructed in white marble and very beautiful. There are several shrines and I had the chance to be blessed by a holy man in one of them.

Perhaps the highlight of sight seeing in Hyderabad is the Salar Jung museum. Salar Jung was the third Salar (royal Nizam minister) who amassed a collection of art objects from India and all over the world. The museum is extensive and ecclectic, with art from Europe, Japan, China, Africa, and India. Perhaps the most remarkable piece in the collection is the Veiled Rebecca. This life-sized marble statue by the Italian sculptor Benzoni is amazing to look at. The treatment of a fragile veil over the body of young bride-to-be ranks it with the world's great scuplture.

Monday, November 13, 2006

Java - Wide Open

Sun Microsystems has decided to make Java open source. Is this a good thing? Only time will really tell. I generally favor open source project, but somehow, making Java open source leaves me feeling a bit uneasy. Those who enjoy sausages (as I do) are better off not knowing how they are made or what goes into them. I'm way past that point with open source, though. I know only too well what can go wrong and what goes into the process.

Call me old fashioned, but I *liked* the idea that Sun stood behind Java looking after it's interest. In general, I've agreed with the evolution of the language. The 1.5 release has some solid features that I've already started using. Will that continue to be the case or will we start to see langauge feature creep? Sun indicates that it will continue to test releases and I would imagine that they will have a lot of influence on the directions that things go. Will they continue to support it financially?

If I think about the work that I'm doing -- what changes to Java does Sakai need? None that I can think of. Oh, it can be more efficient. Recent rumors of it running out of memory are not pretty, but that's not a feature, per se. Nope, I can't think of anything, at least in terms of langauge definition.

Naturally, the Java object libraries will continue to evolve. Sun has always considered the object libraries to be part of the langauge (java.*). It's hard for me to think of it in those terms after so many years of Fortran, C, C++, etc, etc. This is the area that I think open source will improve the process -- get several thousand programmers working on improving the object libraries, push them in new directions, update things as technologies and standards evolve, etc.

Sun's stated intent for making Java open source is to encourage new people to use the langauge for new applications. They figure that it will sell Sun products and I hope they are right. On the other hand, they've lost the IDE race to Eclipse and I don't see most of use buying Sun workstations for our home or office, though there are exceptions. Sun does make some mighty fine servers, if a bit on the expensive side.

So welcome to the wild world of open source, Java. It's not all law and order out here on the frontier -- people do occasionally get shot on the street. On the other hand, there is lots of wide open territory. Open to innovation, crazy ideas, and the merits of hard work.

- Mark

Wednesday, October 11, 2006

Live from Educause

I'm writing this from Dallas, TX, host city of Educause 2006. I've been to many Educause shows over the past 10 years or so. This one is typical of them. Most of the action happens in the exhibitors hall. So many of the people I've come to know over the years come to this show. It's a bit like a class reunion. I think it's one reason why people continue to come every year -- it's a place to meet friends and colleagues.

Needless to say, the BlackBoard patent was a bit topic of debate. BB held a "Town Meeting", which I managed to miss. There were a lot of jokes made, impassionated hallway conversations, and chair-top pundits all willing to share their veiw. I have to believe that BB is getting a better understanding of the reaction this has caused in higher education. I also believe that it's not too late for them to salvage this situation. Time will tell.

As always, I wander around the show floor looking for cool things, new ideas, heck even slick marketing. The swag has come down in quality in recenty years, so I don't bother much. Glowing yo-yo's seem to be prevalent this year. Ho-hum.

Apple had a very nice booth. Josh Holtzman was giving Sakai demo's there. Josh is a great spokesman for Sakai and it was nice to see him at Educause helping to evangelize Sakai (or was it Apple?). I got a closer look at Final Cut Pro. Apple is now claiming a larger marketshare than Avid. Given Avid's very solid market position for many years now, I have to wonder how Apple defines the market. Still, there is no denying that Final Cut Pro is indeed a killer app for the Mac. One very slick application.

Some may know that I consult to Unicon on a part time basis. Unicon was showing a preliminary integration between uPortal and Sakai. Essentially, uPortal and Sakai have single sign-on via CAS. Unicon wrote a small portlet that shows the active user's Sakai sites. A site can be selected launching Sakai. Kinda cool, but needs more work, which I discussed with John Lewis of Unicon. This is just a small example of how uPortal and Sakai are finally coming together.

The keynote speaker was Ray Kurzwiel, founder of many companies and author of "The Age of Spiritual Machines" and "The Singularity is Now". Ray spoke at length about exponential growth in technology and biology, how it relates to where we are now, and where it will likely lead in the future. He demonstated a hand-held reading machine that would enable a blind person to read signs on the wall, a restaraunt menu, or a book. Very slick. Many people have tried to pick holes in Kurzwiel's analysis, but I find it very compelling, having lived through the early days of electronics, and the rise of the information age. His predictions can be outrageous, but his track record is good, looking back over the 20 years I've been following his work. Much of it is hopeful, and all of it interesting.

- Mark

Tuesday, October 03, 2006

What will Sakai do about Presentation Technology?

This was written in response to Chuck's annoucement about the JSR-301 Call for Participation. I've been struggling with JSF for over two years now. While it has some very positive aspects to it, it has a large learning curve and some serious internal problems, especially in the Sun Reference Implementation.

My own work on JSF over the past six months has caused me to shift towards the MyFaces implementation of JSF than the Sun reference model. Clearly there is a LOT more development activity going on here (in Apache) than at Sun. Personally, I'd recommend that we drop the Sun RI and just go with MyFaces. There is no downside, except for some code migration.

Presentation technology continues to be a problem for Sakai, IMO. While I'll be exploring the alternatives in a presentation at the upcoming conference, I don't really have a strong recommendation at this time. Frankly, JSF is a barrier to building tools for Sakai. Yeah, there are alternatives that are starting to emerge, including non-Java ones. For serious and major tools, however, we are still encouraging JSF (is that still true?).

If we are NOT encouraging JSF, then we'll continue to see a proliferation of UI technologies. Already we're seeing Sakai tools written using Struts, JSP, and RSF, not to mention pure servlets. While this flexibility does encourage people to "use what they know", in the long term it's gonna hurt us in (lack of) consistency in user experience. Further, the effort we put into developing cool JSF gadgets won't help a bit to someone writing a servlet.

Rather than point at a particular technology (RSF!!!) and declaring it to be the next great thing, I'd like to explore how we will decide this problem. Comparing technologies is a start, but do we REALLY understand what our requirements are in a UI system? Where do we want this to take us? Can we make a choice now that will hold up for the next 2-4 years? How much of the problem is social in nature (lack of training, documentation, best practices, and standards)?

- Mark

Saturday, September 30, 2006


Took the last two days off to recover from surgery to my left shoulder. I injured it sixth months ago (or so), probably being thrown about in my dojo. Martial arts in my fifties is different than practicing in my twenties, I guess. Anyways, it left me with pain that wouldn't go away, so last thursday a sports medical specialist poked in there to file things down, shave a few loose ends, and generally tidy things up. So far, it looks like a complete success.

I've been doped up for the past two days and I can honestly say that drugs and Java just don't mix, so kids .... stay off drugs! I'm clearing out of the fog this morning and have started back in on work. Too much to do to sit in the living room channel-surfing.

One of the things I'll be spending more time on in the coming weeks is requirements for Sakai 2.4. I've started preparing a Sakai 2.4 Requirements Summary page. You can have a look at it, but it doesn't say all that much at the moment. It does start to shape some of the things that we could work on, but it's not a closed subject by any means. If you have suggestions or things you'd like included, give me a shout.

It's not the job of the requirements group to tell developers or designers how to write code for Sakai, but I do think that we can make the job easier by collecting up requirements, use cases, design sketches, comments from the community, etc. into a central place and then promote what needs to be done. Again, you can help me by telling me (representing the rest of the group) what you'd like to see captured or collected.

- Mark