User:Roan/Moving Dokeos forward
From Dokeos
This is currently a personal text, intended for thinking about the future of Dokeos. I do not pretend to have all the answers, this text is helping me get a clear view and might learn us something, so all feedback is welcome, for example in the talk page of this article.
Dokeos is moving forward quickly. As you can see from all Dokeos activity, summarised in the History of Dokeos, we are becoming both better and more popular. The website gets huge amounts of visitors every day, the online campus is a great success, the forum and wiki are working well, we just launched a website for extensions, 1.6.1 is underway, we have more developers now than ever before, the release process for 1.6 with its frequent beta and release candidates brought us a lot of user testing...
For me, how things happen is often more important than the exact results. Open development, trying to build a community, those are good steps. Not incidentally I believe these also produce superior quality software. When i say belief, stop sending those copies of The Watchtower. It's based on the proven success of many free software projects. Open projects with a community succeed and grow. The others wither and die.
Contents |
The software revolution
Free software / open source has made a revolution happen. The old days of cathedral style development are over. Gone are, for most applications, the ridiculous "big design up front" processes. There's no more managerial meetings assigning committees to produce designs of hundreds of pages, implementing them when the design is thought to be perfect, and only releasing them when the software is thought to be perfect. These waterfall models are dinosaurs, slowing development, killing flexibility, and never reaching the user until it is too late to change and react to ever changing requirements.
"Linux overturned much of what I thought I knew. I had been preaching the Unix gospel of small tools, rapid prototyping and evolutionary programming for years. But I also believed there was a certain critical complexity above which a more centralized, a priori approach was required. I believed that the most important software (operating systems and really large tools like the Emacs programming editor) needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time.
"Linus Torvalds's style of development�release early and often, delegate everything you can, be open to the point of promiscuity�came as a surprise. No quiet, reverent cathedral-building here�rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches (aptly symbolized by the Linux archive sites, who'd take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles." -- Eric S. Raymond
The way forward is different. The great babbling bazaar is creating software that is not only superior in quality, but also engaging its users to become producers themselves, not just customers who have to buy software that alienates them from involvement and halts their creativoty. Ultimately, users simply care more for open source software. The positive, inclusive atmosphere has also brought many users to contribute sigificant time to helping development, bugfixing, designing and translating. This has baffled traditional closed companies, who have to spend tons of money for decent test teams and afterwards still get accused of exploiting their customers, not listening to their demands, and having helpdesk support seemingly from an age before the telephone was invented.
Community
We want a community around Dokeos. If we're developing Dokeos just for our own organisations, taking what we need, we're not doing much good. How do we build a community? First of all, it is done by doing some things well, and not doing some other things. Great, that was easy. Now to figure out exactly what...
Do's and don't's
- Do have real open development. Either you do this for real, or you try to fake it and fail. Several companies have tried their old tricks with the open source community: pretending the are open and community driven, but users soon discover they are taking contributions but never giving anything back, beign only partially open, etc. SuSe, once a very popular linux distribution, is now opening up to the community idea, since they see their popularity wane in favour of more community driven distributions like Fedora, Debian, and many others. Even Microsoft is both attacking open source and pretending to be open itself, with a shared source program that lets customers - who have to sign non-disclosure agreements - to have a look at the code.
- Don't discourage community involvement by closing up. This means not having closed decision meetings to set all sorts of priorities without the rest of the world knowing what's going on. Since a lot of the developers live in belgium we can take advantage of this and actually meet live, but this should not come at a cost for the rest of the world.
- Do take in user contributions. Several of our users post some bugfixes on the forum or mail them to us. However, we do not always take the time to test and check this code in. This is something that should change, because not following up on this feels like saying "you / your code is not good enough" to users, and that should not happen.
- Don't wait to release to eager betatesters During beta develoment, package as often as possible and release to the community. An unstable testing campus on the Dokeos website is a very valuable tool. In the future we should install it more often - once a day for example. After some exercise, it's possible to install Dokeos in just a few seconds :-)
See also: Dokeos:Community Portal for a discussion text on the meaning of freedom and openness.
Development
How do we produce software that is of good quality? The start is easy: we combine the GNU GPL license and freedom philosophy of the Free Software Foundation with the pragmatical development approach of The Cathedral and the Bazaar. We can also learn from an number of agile software development processes, such as extreme programming (XP). All these new ideas help us grow and evolve to better software development.
The main aim of XP is to lower the cost of change. -- XP wiki page.
The importance of being open cannot be stressed enough. Code that is not publicly available might as well not exist. It is dead, it has no purpose, it contributes nothing to this world. Luckily all version control systems hav ways to always have all code by the developers publicly accessibly, in the main development branch or in special experimental or personal branches.
See also a view on how to have good release scheduling
As for versioning, perhaps we can also find another compromise: "Linus coppers his bets, too. In case there are serious bugs, Linux kernel version are numbered in such a way that potential users can make a choice either to run the last version designated ``stable`` or to ride the cutting edge and risk bugs in order to get new features. This tactic is not yet systematically imitated by most Linux hackers, but perhaps it should be; the fact that either choice is available makes both more attractive." -- Eric Raymond, Release early release often
How do we apply this to Dokeos? We will continue t fix bugs in the 1.6 stable branch for some time to come. We could also have a "nothing is guaranteed" 1.7, and after that once again a stable 1.8.
Content
The freedom ideals of free software / open source have happily spread to content as well. From dictionaries over music to encyclopedias and free books. For most users, content is the most important. Logicall then, content must be one of the main focuses of Dokeos. We must do more research into typical use cases for Dokeos users and promote open content licenses for spreading their work.
We can also use a content page with courses in the native Dokeos course backup format, and/or as an exported SCORM package. This would of course require people releasing their content under some open license: crative cmons, libre commons, GNU FDL...
Decisions, decisions
All new organisations - schools and universities that look for Dokeos and consider a switch - I meet ask the same thing: who decides? What is the decision process? Well, euhm... The truth is this process is not very clear. It is not simply authoritarian or democratic or meritocratic or dictatorial... it seems to combine elements in all of these. A professor at Ghent University (Jan Blommaert) once said (quote from memory) that good government needed a combination of democracy, efficiency, and expertise. This is certainly true for Dokeos as well.
Initially Dokeos was just a few people. Then it was less difficult (though even then not very easy). Decisions, who had the power to make changes, it was all very informal. I wouldn't like to see this change to very bureaucratic decion making ways. But we should make sure no groups feel frustrated. And the least we need to do is be honest about our decision process. It doesn't have to be a secret.
It is clear that the people who devote a lot of effort to Dokeos have a lot of influence.
