OJS, a hosted platform, or something custom: how to actually decide
Every journal or press evaluating a new publishing platform ends up at the same three-way fork: run Open Journal Systems (or another open-source platform) yourself, use a hosted commercial service, or commission something custom. Most comparisons focus on feature checklists. The feature checklists are usually close enough not to matter. The question that actually decides it is about control.
Self-hosted OJS: you own the whole stack
Running your own Open Journal Systems installation means the institution controls the server, the data, the plugin ecosystem and the upgrade schedule outright. That's the entire appeal, and it's a real one — no vendor can discontinue your platform, change pricing terms, or restrict your data export.
It's also the option with the most ongoing technical responsibility attached. Someone has to apply security patches, manage the hosting environment, test plugin compatibility before upgrades, and be reachable when something breaks. That someone can be an in-house team or a technical partner, but it has to be someone with actual accountability — 'the current IT person, when they have time' is not a maintenance plan, it's a plan to eventually need a rescue.
Hosted commercial platforms: you trade control for less operational load
A hosted platform removes almost all of the server-level maintenance burden. Updates happen on the vendor's schedule, uptime is (usually, contractually) someone else's problem, and there's a support line to call. For a small editorial team without dedicated technical staff, that trade is often the right one.
The cost is real, though, and it's not just the subscription fee. Migrating off a hosted platform later is harder than migrating off self-hosted OJS, because the data model, URLs, and sometimes the DOI registration history are shaped around that vendor's system. Read the export and migration terms before signing, not after deciding to leave.
Custom-built: only justified by a genuinely unusual requirement
Custom platforms make sense in a narrow set of cases: a workflow that doesn't map onto standard journal publishing at all, a scale that breaks assumptions built into existing systems, or an integration requirement so specific that adapting an existing platform would cost more than building the piece you actually need.
Outside those cases, custom development usually reinvents features OJS or a hosted platform already solved — submission tracking, peer review assignment, DOI registration — at a fraction of the maturity and a much higher long-term maintenance cost, because now there's no upstream project fixing bugs or publishing security patches for you.
The actual decision framework
Ask three questions in order. First: does someone at the institution have both the capability and the accountability to maintain a self-hosted system indefinitely? If genuinely yes, self-hosted OJS is usually the strongest option on cost and control. If no, move to the second question.
Second: is the requirement close enough to standard journal publishing that a mature open-source or hosted platform covers it well? If yes, choose between self-hosted and hosted based on the maintenance-capability answer above. Only if the answer to the second question is a clear no — the workflow genuinely doesn't fit — does custom development become the right call, and even then, it's often cheaper to build a plugin against an existing platform than a system from nothing.
Takeaways
- The real question is who has both the ability and the standing responsibility to maintain the system — not which platform has more features.
- Self-hosted OJS maximises control but requires a named, accountable maintainer, not an occasional volunteer.
- Read a hosted platform's data-export terms before you sign, since that's when you have the most leverage to negotiate them.
- Custom builds are rarely justified by convenience — only by a workflow that genuinely doesn't fit existing platforms.