Featured plugin: moosh

Featured plugin: moosh

by David Mudrák -
Number of replies: 0
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators

Today's featured plugin is moosh. The name stands for MOOdle SHell. It is a command-line tool that will allow you to perform most common Moodle tasks. It has been inspired by Drush - a similar tool for Drupal.

Strictly speaking, the moosh is not a Moodle plugin. It is a standalone utility and can not be installed by plugin installer built into the Moodle administration interface. Still it is registered with the Plugins directory and actively maintained by Tomasz Muras.

Hi Tomek. Can you shortly tell us something about yourself and your background?

Photo of Tomasz Muras

Software engineer and a big fan of Open Source.

Heh, that was short indeed smile Can you describe the moosh and its main features? Who is it primarily intended for?

It’s a commandline tool that exposes some Moodle functionality. Making it CLI means that using moosh for some things is super quick and convenient - it basically brings the power of Linux commandline into Moodle.

You install it only once on your machine/server and use against all Moodle instances on that host. moosh will figure out current version of Moodle and will use/run appropriate version of a command (e.g. course-backup for 1.9 is totally different than course-backup for 2.X).

It’s intended for:

  1. Developers. Within seconds you can do things like:
  • create 100 test users, e.g. moosh user-create user_{1..5}, create a course with course-create and enrol your users into the course with course-enrol.
  • have moosh generate some code for you with generate-* and form-add commands, update version.php with current timestamp
  • clear caches
  • turn debug on/off
  • dump sql or login into mysql console without the need to look for your DB password
  • run ad-hoc SQL query or Moodle PHP code against current Moodle
  • download Moodle module or Moodle itself
  • run code checker
  • reinstall your module
  1. Moodle admins and power users:
  • backup 1000 of courses, scp them to another machine and restore in one super-combo
  • manage users/courses/categories/plugins/files
  • monitor & check your Moodle installation

How did you get into Moodle and Moodle development?

Years ago, in the dark ages when some people were comparing Open Source to cancer and Linux was just my hobby, I found a job offer from a company that was using Linux, MySQL, PHP and Open Source software. For me it basically meant doing things I now do in my free time (because I enjoy them) but also getting paid for it… impossible! Turned out it actually was possible and since then I have the best job in the world.

You recently joined the Plugins guardians team. What was your motivation to do so?

To support Moodle as a project and enjoy doing it at the same time (I like to read the code). I’m quite surprised by the number of new plugins being submitted to Moodle each week - well done Moodle community!

What software and IDE do you use when developing for Moodle and how does your typical screen look like?

Nothing very fancy really - Linux box (Ubuntu) with PhpStorm plus Firefox and terminal (terminator and zsh as shell). I also use zim for nearly everything else.

Tomek's desktop

What is your common plugin development workflow and how do you organise the code in terms of branching, tags etc?

With moosh it’s very simple - git, master branch for development, with tagged releases and debian branch for creating Debian/Ubuntu package.

Many Moodle plugin developers are looking for a business model that would, at least partially, cover the time spent on their plugin development and support. Can you give some recommendations based on personal experience?

I think this is a big issue in Open Source world and nobody has a perfect solution for it.

First, there is discussion wherever open source developers should be paid for their work at all (google for “Debian Dunc-Tank” disaster) or should that depend on volunteers. I strongly believe that yes, they should be paid. It would be beneficial for all us if we have motivated developers being able to work on useful plugin full or part time continuously. It’s always sad to see unmaintained plugins.

How to get there is a big question. As far as I know (second-hand) those ideas don’t usually work:

  • Selling gadgets (t-shirts, cups) - nobody is buying them.
  • Donations. If it doesn’t work for the projects that half of the Internet depends on, there is no way it will work for Moodle plugin, to quote arstechnica: OpenSSL typically receives about $2,000 in donations a year and has just one employee who works full time on the open source code.
  • Offering paid services related to the plugin. As far as I know this is not sustainable (so you still need full time job, so you don’t have free time for development…) What may work:
  • An interesting idea that may work is snowdrift - read more about the problem and possible solution on https://snowdrift.coop .
  • Crowdfunding done with support from Moodle - e.g. the one at moodle.org but maybe Moodle HQ could facilitate it? Help with promotion and actually collect and distribute funds?
  • Finding a sponsor (or sponsors) that would provide X each month for just being listed as a sponsor of a plugin. I also like the way you can sponsor vim - check this out: http://www.vim.org/sponsor/

Do you have some particular plans for further development of the moosh?

Just had a look at my zim page - I have 85 open moosh todo items, 6 new commands in the queue and 23 open issues on github. Unfortunately I have very little free time, so I’m not expecting any major development there any time soon. The next thing I should really sort out are functional tests - many commands are already covered (see moosh-online.com/ci/) but there is much more work there. Since the tool is used on production systems, I’d like to make it as stable and reliable as possible.

Thanks a lot Tomek. And good luck with all your contributions!

Average of ratings: -