When Omeka Needs One More Thing

Omeka does a great deal out of the box, and the module and plugin directories cover a great deal more. Most institutions get further than they expect without writing a line of code.

But every collection is eventually a specific collection, with a specific workflow, run by specific people who have been doing it a specific way since before the software existed. And at some point there is a thing the platform will not do.

We build those things. Before we do, though, we ask a few questions — and often the answer is that you do not need us.

First: are you sure you need custom code?

We would rather talk you out of a project than take one you did not need. Three questions usually settle it.

Has someone already built this? The Omeka community is small but productive, and a surprising amount exists outside the official directory — on GitHub, in a repository at another institution, mentioned once on a mailing list. It is worth an hour of searching before it is worth a budget.

Is this a workflow problem wearing a software costume? Sometimes the request is for a module that enforces a step that three people keep skipping. Occasionally software is the right fix for that. Often a checklist is, and it costs nothing.

Could configuration get you 80% there? Omeka's flexibility with resource templates, item sets, and vocabularies solves more than people expect. If a well-designed template gets you most of the way, the remaining 20% may not justify a build.

If you get past those three and still need the thing — good. That is a real project.

Modules and plugins

For Omeka S we build modules; for Classic, plugins. The work generally falls into a few shapes.

Filling a gap in the directory. Something your collection needs that nobody has built, or that exists but was abandoned three versions ago.

Connecting Omeka to something else. Your ILS, your institutional repository, a vendor's API, a spreadsheet the registrar maintains. Integrations are the most common request we get, and the most satisfying to deliver, because they usually replace someone's recurring manual task.

Admin tools for your workflow. Bulk operations, review queues, custom reports — the unglamorous internal tooling that makes cataloguing faster. Nobody outside your building will ever see it, and your staff will notice it every day.

Themes

A custom theme is worth it when your institution has a visual identity that a stock theme cannot carry, or when the collection has a shape that generic layouts fight. An oral history archive and a photograph collection want genuinely different front pages.

Two things we insist on, and will argue for even when nobody asks:

Accessibility is not a phase at the end. Public institutions have obligations here, and beyond the obligations, a collection nobody can navigate with a screen reader is a collection with a smaller audience than you think. We build to accessibility standards as we go, because retrofitting is more expensive and produces worse results.

Responsive is not optional. A meaningful share of your traffic is a phone. Often the majority. We test on real screen sizes, not just a desktop browser made narrow.

How we work

Discovery first. We start with a conversation about your collection and the people using it, not with a feature list. What is the actual task? Who does it, how often, and what makes it slow today? A surprising number of requests change shape in this conversation, usually getting smaller and more useful. We do not write code until we agree on what the thing needs to do.

Built to the platform's standards. Custom work that ignores Omeka's conventions becomes an obstacle at the next upgrade. We build the way the platform expects to be extended, so your module is a module and not a private fork you can never update.

You own the code. The finished work is yours — repository, documentation, all of it. Keep it internal if you like. Release it to the Omeka community if you would rather, and plenty of institutions do; the directory exists because people gave things away. Either way it is your decision, not a licensing term you have to negotiate.

It has to deploy. Custom work installs cleanly on RefBytes Cloud hosting or on whatever server you already run. We are not going to build you something that only works if you also buy hosting from us.

What this costs

It depends entirely on the work, which is an unsatisfying answer, so here is a more useful one: the discovery conversation is where the estimate comes from, and it is worth having even if you do not proceed. You will come out of it with a clearer description of the problem than you went in with, which is useful regardless of who builds it.

Get in touch and tell us what your collection will not do. We will tell you honestly whether it needs code.