As far as PKP developments are able to do the job "out of the box", some organization decided that a single OJS installation is enough for all their magazines.

mOJO is designed for the opposite: To have each magazine in a separate OJS installation and facilitate the usual tasks over those publications.

Why multiple OJS installations?

A separate installation for each magazine (aka. multiOJS), have some benefits and some lacks.
Notice that in some contexts a benefit could be considered a lack.

Advantages

"More flexibility"

Management:

Independent list of users for each magazine.

Plugins' system:

Install different plugins for each magazine.

Enable/disable different plugins for each magazine.

Theming:

Different templates for each magazine.

Different themes for each magazine.

Performance improvement:

Database level: Smaller DB (less tables).

Cache level: Independent cache folders (less files).

Escaliability:

Magazine granularity: You can "operate" at magazine level.

Script/DB/Files segmentation: You can balance your charge (even with different servers)

Different Apache settings for each magazine: multi-domains, multi-webusers, multi-caching...

Maintenance:

Keep different OJS versions for each magazine.

Independent Backup & Restore for each magazine.

Disadvantages

"More complexity"

Management:

More complexity: multiple OJS instead of a single OJS (mOJO helps)

Independent list of users for each magazine.

You can not "operate" over multiple magazines at same time (mOJO helps)

Presentation:

Catalog of magazines it's lost.

Global searcher (between magazines) it's useless.

Maintenance:

You need to configure/upgrade each magazine independently (mOJO helps)

What is mOJO?

mOJO is the acronym for "Multiple OJs Operations (aka. mojo)" and as described in the GitHub's repository [1] "it's a bash script to create multiple Open Journal Systems (OJS) installations and "rule them all".

Was developed to fill the "gap" between both installation approaches so helps administrators to deal with some of the listed disadvantages as well as offers new features as:

Create pre-configured magazines from a pre-formated base in seconds (including crontab and htaccess)

mOJO was developed and is tested against OJS 2.3.6 but it's expected to work with any 2.x version and will work with 3.x with minor changes.

The script could be (will be) extended to do better error checking, to work with other DB engines, Web Servers or migrated to other languages (PHP?) but as far as the whole system is based in symlinks mOJO will only work on UNIX operating systems.

Example of mOJO callings

mOJO usage:

$ mojo
$ mojo help

List all your magazines:

$ mojo list

Create a "pre-configured" magazine:

$ mojo create all magazineAlias
$ mojo create all magazineAlias "editor@example.com"
$ mojo create all magazineAlias "editor@example.com" "Real Name of the Editor"
$ mojo create all magazineAlias "editor@example.com" "Real Name of the Editor" "Title of the Magazine"

In the root directory you will like to place a CMS to publish news and a list of all the magazines included in the system, whatever... but this is not our concern now (See it running at: http://revistes.uab.cat)

The interesting part is in each OJS sub-folder that will be a physical directory with symbolic links to a "base" ojs.
What is the "base" ojs? It's the OJS code that will be shared between ALL journals.

Notice that not everything could be "symlinked": We need different index.php, config.inc.php and caches for each OJS installation.
A few extra folders (ie: webdata) will be also specific for each OJS: files, public and registry. An .htaccess (in root folder) and/or vhost will do the redirection work.

Keeping this structure up to date could be very boring and manual operations inevitably drive to errors, so we use mOJO to do the hard job.

The script generates the structure of a new OJS installation (web code & web data), and fills the database with a "preconfigurated OJS model" (the "base" one). The script also plays with string-replacement (sed) to substitute some tags with the appropriate information in config.inc.php, database dumps and so on... so when you do:

A new magazine is created and filled with the specified title, editor's name-mail, etc. in just seconds.

Comment: After we create the magazines, we meet the staff and we fill together OJS's configuration 5 steps to fit the magazine to their needs.

So mOJO helps in create/delete/backup/restore operations but also include a few snippets to work with symlinks, domains, crontab.

Notice here that as far as templates, plugins... folders are symlinked, you can replace any of those folders with physical folders and keep something a little bit different. This let us keep same code (except templates) for magazines as different as:

Password command: To periodiaclly change admin password globally (all the magazines) or set different DB usr/pwd for each magazine.

Select command: To run comands against a set of magazines.

Mantainence: Play nicely with git. Even backup code in git.

Staging: Define different contexts and let mOJO move magazines from test to production (and vice versam)

[DEV] Verbose or progress bar for "slow" operations.

[POSTPONED] In discussion: Migration from bash to PHP (as far as OJS is PHP)

...

Known issues?

Unable to login if your OJS code is not "patched"

Some code in OJS (plugins classes) use absolute paths instead of relative and it breaks the system.
This is partially fixed but still under discussion with PKP.

Better error checking

Doing mOJO operations in damaged OJS (for instance, without DBs, webdata folders...) could result in tar or mySql warnings.
Reading the warning will be enough to figure it out what happened (try to remove an non existing DB) and fix it, but would be nice to clean it up with better error checking.

Arguments

Right now, params need specific order, could do not include quotes, are not seriously checked...
Till now, parameter handling was not a priority and it must be improved ("getopt" looks like the right candidate).

Further questions

Here you can find some questions that raised up during the presentation of mOJO to the PKP Technical Committee.
The discussion made obvious we were thinking in a little different contexts: an "institutional" one, and a "hosting" service. We refer to both in the explanations.

Some of those questions need a deeper analysis or cross work between interested parts.
Feel free to extend this list.

How to deal with PKP recommended patches?

This is not implemented yet but it's something we have in mind (and it's probably connected with the GIT question).

If is possible, in our "institutional" context we like to keep all the magazines in the same version (the last stable one). It means that we like to apply the same patches for ALL our magazines at the same time. It's usually a win-win: Editor's are happy because their magazines are "up to date" and we (sysadmins) are happy because the complexity is reduced.

As explained mOJO creates links for every OJS instance to a "base-version" of OJS code (in our case I have 3 versions running: "current" with 2.3.6, "new" with 2.4, "dev" with 3.0...)

If you don't have "file customizations" (aka. "forks" with different templates, plugins...) we have at least two easy solutions here:

A BASE magazine: We can keep a fake magazine that links to the OJS base-version (pe: "current") and you can nicely play "pkp tools/download patch" or whatever so (as symlinked) the change will be applied to ALL the magazines.

I suppose would be nice to run a "php tools/update.php" patching so mOJO could also be extended to help with this and do the job in every magazine that links to this base-version. Something like "update all the magazines symlinked to current version and warn if a magazine include "customizations".

I'm not sure if this approach will be good enough in a "hosting" context with needs as the one explained in the next question. Please, let us known.

Is it possible to keep different permissions?

I understand this question is not related with OS file permissions it's more about user permissions and apache security modules (as suExec, suPHP...)

In our installation we use "ojs:www-data" and as far as "mojo" is (and will be) a sysadmin script runs as root, permissions is not a big concern for us. Please, comment if you disagree.

Any way, some security modules will complain if the destination of a symlink is not in web folder (public_html...), users don't fit or file permissions are too permissive (777), etc. More than this, in a "hosting" context you will also like to offer ssh/FTP to your users, "chrooted" spaces, etc.

In this sense, the "hosting" scenario could be very variable and looks a little far from the "controlled" context we are building so we will need to detail to see if mOJO can fit.

Any case, in this wide context, seams that mOJO will need to be extend to: