Half Baked Modules and Plug-Ins

Half Baked Modules and Plug-Ins

by Steve Mack -
Number of replies: 6
I know that I should not look gift horse in the mouth. I was really excited when I came across Moodle because I was looking for a low cost collaboration tool. The baseline Moodle Discussion tool is functional but not exactly what I needed. I came across several plug-ins that promised the additional functionality. However they do not function properly in the current version of Moodle. From the listed update dates it appears that further development on them has ceased. So I am disappointed. But before I walk away from the product, let me make two suggestions.

  1. Develop a tracking process for identifying modules and plug-ins that are nonfunctional. Like people identify dead links on a webpage, let Moodle users ID nonfunctional plug-ins on their parent page. And then perhaps have someone occasionally walk through the plug-in database and validate the reports of nonfunction and either contact the developer and suggest that an update be made or else delete the reference to the module.
  2. The second recommendation is more phliosophical. Open source is a great idea for getting a product quickly out the door. And getting the user community excited about developing additional capability. The one drawback is the lack of discipline in module and plug-in development. So a lot of good ideas are sprung, but many are not worked to completion. I don't know what the mechanism should be but there seems to be a need to somehow pick up the balls of good ideas that have been dropped. Maybe charge a subscription price for access to modules and plug-ins, with the collected fees being distributed proportionally to the module/plug-in developers based on the number of downloads. And allow the user community to also rate the quality of the download and its documentation. That would incentivize the developers to work to a higher quality standard and reduce the amount of anguish users have by experimenting with modules that don't work.

Regards,

Steve Mack
Average of ratings: -
In reply to Steve Mack

Re: Half Baked Modules and Plug-Ins

by Don Hinkelman -
Picture of Particularly helpful Moodlers Picture of Plugin developers
Hi Steve,

Amen! We need a rating and review system for the modules and plugins. The list has grown huge and it so hard to sort through it. I, for one, would be happy to write reviews and give ratings to those modules I use. It would also be useful to have a history of development by versions, and the number of downloads per version. If you have time, post a feature request in the Moodle Tracker with your suggestions. The first point should not be hard to implement, and the second one is something that is worth discussion.

Cheers,
Don
Average of ratings: Very cool (1)
In reply to Don Hinkelman

Re: Half Baked Modules and Plug-Ins

by A. T. Wyatt -
Agreed! When you put the tracker request in, please post here so we can all find it easily and vote for it! smile

atw
Average of ratings: -
In reply to Steve Mack

Re: Half Baked Modules and Plug-Ins

by Ralf Hilgenstock -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Translators
What you describe is the difference between Standard-Modules and Third-Party-Modules. The standard modules are standard because they are stable and functional. There are maintainers working continously on them. From time to time modules are going from third party status to standard (like the feedback module in Moodle 2.0. But there is also the way that a module goes in the other direction from standard to third party (like Workshop in 2.0).

If you check third party modules you should look on the supported versions and also at the discussion in community to see if there are other reports about bugs or problems. Its not enoguh to look on the comments in the plugin database.

I agree with Don and A.T. that the system of comments for the modules should be optimized.

Everyone can add a new module or tool to this database. There is no control or check before. Sometimes modules are working very well under special environments, but have problems in others. Often such information are given in the information text. Sometimes the developer dorsn't know it, because they didn't test the system in different environment.

Average of ratings: -
In reply to Steve Mack

Re: Half Baked Modules and Plug-Ins

by Anthony Borrow -
Picture of Core developers Picture of Plugin developers Picture of Testers
Steve - In my role as CONTRIB Coordinator, I am interested in seeing how we can improve the process of collecting data on the code submitted through Modules and Plugins. In fact, this summer I am hoping to make a push to get as much code into Moodle's CVS server so that it is easier for folks to step forward on projects and take the lead on maintaining them. Your ideas in how to implement this process are very much appreciated.

My concern with the first suggestion is who decides when a piece of code is usable or working or not. While initially it seems fairly simple to determine if some code actually works or not, Moodle is used in a great number of different environments. So it may work for you and not for me (or vise versa). If someone is having difficulty with a plugin, I am happy to help them get in touch with the developer. Generally I start by messaging the person who added the record to the database. Folks have been very generous in stepping up to help maintain abandoned projects.

In my experience, there are multiple reasons why and how code actually becomes shared. There is some great code in CONTRIB that is stable and functional and actively being maintained. Such code may never be included in core for a variety of reasons. So the need for folks to understand more about contributed code is key. The most important thing (at least from my perspective) is that it is shared. I am currently at the MoodleMoot in San Francisco and speaking with a number of universities that have written code but have been hesitant to share it because they are worried about the quality not being good enough or that they will not have the resources to maintain it. I am encouraging folks to share at will. Of course as they begin to do so we will need to develop a way of providing feedback about how that code works. I am also keen on helping to encourage the development and maturity of good ideas. I am convinced that the more code with have in CONTRIB the better.

CONTRIB is very much evolving so let me know your ideas of how we can best serve the diverse needs of the community. I do not think that charging a fee is consistent with Moodle's model of sharing code. At the same time, it is good to explore ways that we can acknowledge (and perhaps even compensate) folks who demonstrate a commitment to a piece of contributed code. I think it is possible to have the best of both worlds (i.e. free and compensate) but we need to work out the best way to do that. Personally, I have been inspired by the generosity of so many who have contributed and maintained code for motives other than financial gain or profit. I find that most of the folks involved with Moodle are motivated more by passion that profit (not that there is anything wrong with profit). So let's keep this discussion going and keep sharing your ideas as we work together to evolve contributed code. Hopefully we can encourage and provide the tools that will allow for contributed code to mature and give system administrators more tools to better assess whether or not to use contributed code on their sites.

Peace - Anthony


Average of ratings: -
In reply to Anthony Borrow

Re: Half Baked Modules and Plug-Ins

by Steve Mack -
I apologize for not following up on my original post sooner, but I have been involved with other things so have not visited this page in sometime. However, I do want to thank the other contributors for their feedback to my original post.

I have given this issue more thought and I've come to realize that it transcends open-source in general beyond Moodle. I have also been looking at wiki software as a collaboration platform. I walked into that investigation without knowing much about wiki development at all. And then I found out that there are scores of wiki generators with hundreds of programmers supporting them in some context. So wiki is analogous to Moodle.

The problem is that the pristine philosophical argument for open systems precludes collaboration amongst these different developer communities. While a commercial development firm that bought out a handful of other systems under development would integrate them into a single platform, utilizing the best ideas and components from each parent system.

It just seems to me that there is a lot of well-intentioned but wasted effort in open source development, because there is not a collaboration model to derive disciplined and focused efforts to neck down the best design principles from the larger efforts. And there is also the issue of orphaned plug-ins. Firefox extension development is robust because of the general nature of the baseline application. So there is actually a kind of mini competition among the extension developers. However, while Moodle and wiki have large user bases, they nowhere near approach the numbers of Firefox. So when a Moodle developer tosses out a prototype of a good idea but then walks away from it, there is probably not an alternative developer out there pushing to deliver a stable solution to the same problem.

I am a Myers-Briggs ENTP, so am a radical pragmatist who also does the vision thing. As a visionary I think that Moodle and wiki are really wild efforts. As a radical pragmatist, I would consider a heresy of leveraging the profit incentive to instill discipline of commonality and closure of modules and plug-ins. In other words, if it takes allowing somebody to make a buck off of Moodle, and that provides an extremely valuable service to the entire community, it would be something that I would consider.

SteveM
Average of ratings: -
In reply to Steve Mack

Re: Half Baked Modules and Plug-Ins

by Don Hinkelman -
Picture of Particularly helpful Moodlers Picture of Plugin developers
Hi Steve,

Thanks for your comments! Have you made a feature request in the Issue Tracker? If so, I will go there and vote for it. Don't spend another minute discussing these points here. A lot of people agree with you, and just need a proposal to rally around.

I am a developer of perpetually half-baked modules (over ten of them). I don't release seven of them because my capacity to maintain and handle inquiries is limited. So the ones that our school does use actively I release. Ones, that I think have a fair chance of continued funding. I think part of the my assessment of whether to use a new module or not comes from the degree of commitment by a developer. When OU commits to something or when a colleague I know well makes a committment, I trust that module better. I also watch how quickly bugs are fixed or new versions created.

I am fundamentally happy with the current system (though a more formal system of ratings would be nice, as I outlined above) because of the organic nature of development. I think there is no evidence that commercial or open source development is more or less wasteful. It is good to "waste" time on an experiment because through it we learn about good education--what works and does not work. Teacher-developers are probably the best ones because they are close to the learners and can trial and revise in quick cycles.

Cheers,
Don
Average of ratings: -