Developer meeting July 2007 meeting minutes
From Dokeos
Dokeos meeting of July 5th, 2007 held at the Free University of Brussels, Belgium.
This was an international meeting about Dokeos 1.8 and the future of Dokeos, the way we organise ourselves and the architecture of Dokeos 2.0.
Contents |
People present
- Thomas De Praetere - Dokeos company
- Patrick Roth - University of Geneva, Switzerland
- Mohamed Menacer, Saïd Menacer, Amar Arbaoui, Ali (?), Taibah university, Saudi-Arabia
- Kevin? - Develop-It
- Michael Fiorenza, David Steenhoff - Erasmushogeschool Brussel, Belgium
- Evie Embrechts, Roel Neefs - Free University of Brussels, Belgium
- Bart Mollet, Stefaan Vanbillemont - Hogeschool Ghent, Belgium
Debriefing Dokeos 1.8
Thomas De Praetere opened the meeting with his debriefing about Dokeos 1.8. The Dokeos 1.8 release is mainly about authoring: creating content in Dokeos like tests, web pages, animations. And importing it. The learning path is improved and we have tests with reporting and detailed scoring. The next step is coaching: seeing the results of John and helping John to learn better.
Dokeos 1.8 tried to copy good ideas from offline authoring software with the added bonus of being online. In the tests module, we have not just types of tests but scenarios. Listening comprehension is a test type from the viewpoint of the users - this is more the step to an authoring tool. People were very attracted by the conversion of presentation tools, OpenOffice.org is a great conversion machine. As well as Microsoft Powerpoint, OpenOffice Impress is also imported. We also wanted to have the ability to record voices online. In Thomas' view, it adds high-level sophisticated features, but for a user it remains simple. The problem is that underneath it has become quite complex. People want not just an LMS but also authoring, reporting, videoconferencing... "You don't need an offline non-free software tool, we have online free software" The Dokeos competitors do not have all this authoring, videoconferencing...
As for usability: we wanted to keep things simple as before, but look less dull and "sad". We've devoted time to creating improved paper manuals.
From a process perspective, we worked in a typical commercial way: clients payed us for features and we developed them. There was enough margin to have developing time/money to develop the general aspects of the release. The limitation is we are still a small company - 3-6 paid developers which is not enough in itself - not enough testing, etc.
Dokeos 1.8 is a very feature-oriented release. The good news: from the market perspective it is very good, we develop features our competitors do not have. We had a good collaboration with the clients, also content providers. Scorm norm was implemented from the documentation, but that didn't work just like that - vague at times "separate context from content". Content providers have different practical views - how do we see content authoring, how do we make our authoring something that works in a real live situation.
The bad news is for Dokeos 1.8 the company had a very bad cooperation with universities. Conflicts, splits... it actually was a failure. One regret is the idea that people should present a complete analysis and design before implementing. You should describe shortly what you will do, but not submit completely to a jury telling what you will do before you even write one line of code. We do not need that jury-like approach anymore, we want to spread the message, hope collaboration improves. Community with different agendas, the open SVN repository is not an agenda. The different agendas should not result in different softwares. Otherwise, every time there is an argument we stop collaborating - that's not how it should be.
We tried to do more marketing. 2006 was a big success: the company is sound in terms of money and has a future. Two strategies:
- take one feature and promote the software through this feature: OOgie. Oogie road show. "LMS is complex, sell one simple feature, supported by a system"
- partnerships, e.g. Spanish partner sold Dokeos support to companies, Italian & UK partnes sold videoconferencing...
To conclude, user day in Valence was very nice. However no conclusions were published due to lack of time. We learned a lot from user & dev meetings. We should have a new user day in 2008.
Discussion
Several interesting points were raised:
Bart Mollet
- The main problem was a lack of communication. We used to have developer meetings where we discussed the roadmap etcetera, but we stopped having them. Many new features were fine but the way they were implemented was not. Sessions spring to mind as one of the worst examples: it's included in the code, we see it in our universities and we also have the problems but we could not discuss about it and the way it was implemented. It needs discussion so that we can work together on it. All the features right now for 1.8 were developed for the company clients but the universities are also big users and we should take advantage of that fact. For 1.8 schools and universities didn't have much input, there was lack of communication. The commercial part: develop features for money as fast as possible, this conflicts with discussion about design.
- It's by having input from others that you can improve. You can have similar features that are implemented in a better way. It's often not the feature itself but the way it is implemented. The academic institutions should have input from the beginning, not just after something is implemented. This is beneficial for the company also.
- Is it necessary that developments for clients are always included from the start in the main release?
Thomas De Praetere
- Agreed, but the problem is we often need to do things as fast as possible. E.g. "within 20 days", if an expert says it can be better it is often too late.
Patrick Roth
- Some company features can be created as plugins: have them first as a plugin, if one has a lot of succes we can add it in the next release.
Stefaan Vanbillemont
- E.g. the blogging software: that could've been a plugin, it wasn't needed e.g. in our school. We had to tell people "this is the software, we're stuck with it, we couldn't weigh on development enough".
Bart Mollet
- The blog in a course module: if you don't want it right now, you have to delve into the code to remove it. The system architecture just isn't there to support all ways of plugins we need.
Thomas De Praetere
- This is a debate we've had since a long time but now we have a solution, political and technical. The future Dokeos based on LCMS is the technical solution: it does have a better architecture. On the political side I think we can come to an agreement. We can ask people to develop their features as plugins and we (company) can do the same.
- What I cannot accept is that people only make critiques and not proposals/contributions. Collaboration is also at mandays level: who does what.
Bart Mollet
- Agreed, but we are still an open source software and we will always have suggestions / criticisms also from people who do not have time to cooperate on development.
Stefaan Vanbillemont
- Maybe it's just that we lack a good Dokeos community. We should reorganise that and build that community. We should not only brainstorm about features also about community
Patrick Roth
- We are two people who write code in our university. E.g. I changed the code a bit dealing with sorting, sent it and it is not accepted. It is frustrating.
Patrick Roth also developed Shiboleth single-sign on. It is agreed he will receive SVN write access from now on.
Stefaan Vanbillemont
- We should have more accepting / time about accepting code from community: who are developers, what are they doing, can we integrate it into the code...
- We should meet more often. You can't build a community when you just meet one day every year.
Mohamed Menacer
- Maybe the problem is the lack of community structure. E.g. if somebody wants to develop something, he goes to one person.
It's important for somebody who wants to develop somethign that he can start developing, he has the information and the contacts that he needs. We should have some kind of workflow that helps quality of contributions. E.g. Moodle has responsible persons for diffrent areas.
Bart Mollet
- We do have a community, a small one, and some developers, but it should be made more visible. E.g. we have students that develop stuff, and we post a bit about that in the forum, but it is not visible enough. People who go to the website just see the commercial stuf 'new company uses dokeos', but that's it. More visibility on the website is needed. The company website is now also a community website, but not very well visible.
Stefaan Vanbillemont
- If you go to the Dokeos website: only one link about community, big "buy dokeos" banner. It's important that there is a commercial aspect but this way the community has no place to grow.
E.g. moodle has moodle.org and moodle.com, this is very well done.
There is general agreement that (a) we want a community website as well as the company one, and (b) this is not the responsibility of the company and (c) there should be good connections between the company and community websites.
Conclusions
- The user days have been very successful and well received. There should be a new user day in 2008, however who will organise it and where, that remains to be seen.
- Dokeos 1.8 will receive at least 2 more bugfix releases
- Patrick Roth from University of Geneva wil receive SVN write access
- Dokeos development will focus on producing Dokeos 2.0 based on the LCMS code, see LCMS Features.
- We will create a community website separate from but closely connected to the company website. The new site will be launched October 1st. dokeos.com -> company site, dokeos.org and/or dokeos.net -> community site
Presentation about schools
Mohamed Menacer presents information about future/wanted developments.
In Saudi-Arabia, there is a big debate about which learning system is to be used for schools, universities... for a project now they are running Dokeos with Live Conference. For a school it's not just teaching / learning, it's also e.g. getting parents involved and how we can get more monitoring. Also one more module is needed, SMS/MMS.
Another development they'd like to do is a smaller, mobile version of Dokeos (mDokeos). This would not need ll the tools, but some of them e.g. the agenda.
About the future
Besides creating bugfix releases for 1.8, Dokeos development will now focus on producing Dokeos 2.0 based on the currently existing Dokeos LCMS architecture. Bart Mollet gives a quick overview of the LCMS and explains about the LCMS features - what's there and what still needs to be done. He ends with a call for participation.
Hogeschool Gent will continue building the LCMS, Free University of Brussels is already working on a Portfolio system on top of the LCMS, and University of Geneva will work on integrating other repositories. Dokeos company will also contribute to development.
There is general agreement this is an area the community website will need to focus on - get people to participate in the development and testing of this new release.
Dokeos 2.0 will be a very important major release, since it completely replaces the current Dokeos 1.6/1.8 architecture ("kernel").
Next meeting
The next meeting will be held in the first week of October 2007.
Meeting minutes by Evie.
