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.
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: Development, Open Source, Sakai
posted by Mark J. Norton at 10:15 AM
1 comments
