What DergiPark does — and doesn't do: an honest framework for institutional publishing

“DergiPark alternative” — a phrase typed into search engines regularly, and usually the wrong question. Wrong, because in most cases what people are looking for is not an alternative to DergiPark; it is an owner for the work DergiPark does not cover.

In this post we will try to do two things: first, give DergiPark its due by explaining what it is and what it does; then, clarify which of an institution’s needs naturally fall outside that scope. This is not a “this is good, that is bad” piece; it is a “which job belongs in which tool” piece.

Credit where it’s due, first

DergiPark is the national journal-hosting platform of Türkiye, operated by TÜBİTAK ULAKBİM since 2013. It offers Turkish academic journals free hosting, submission-to-publication workflow management, and DOI assignment. Its scale is impressive: the platform’s counters point to over 3,000 journals and over 800,000 articles.

That is nothing to sniff at — quite the opposite. That a university journal can publish on zero budget, without standing up its own server, on trusted public infrastructure is one of the most valuable achievements of Turkish academic publishing. Let’s also clear up a common confusion: DergiPark is not an index; TR Dizin (Türkiye’s national journal index, run by TÜBİTAK ULAKBİM) is a separate evaluation process. Being on DergiPark does not mean being in TR Dizin.

Let’s say it plainly: if your journal lives happily on DergiPark and your needs are met there, you have no reason to look for an “alternative.”

The natural limits of the scope

So why do people keep searching anyway? Because an institution’s publishing life is not reducible to journal workflow management. There are areas DergiPark — quite understandably, as a journal-hosting platform — does not cover:

The book side is entirely outside. The larger share of a university press’s work is books: their submission, their review, their production, their ISBNs, their printing. If your journal lives on DergiPark while your book processes live in email and spreadsheets, the institution’s publishing memory is split in two.

The economics of sales and access. Selling print issues, paid article access, institutional subscriptions, book sales… These are matters of e-commerce and accounting, not of a hosting platform.

Institutional visibility and brand. When an institution wants a publishing storefront on its own domain, under its own identity — one face showing its journals, books, and calls under a single roof — that goes beyond the journal page a shared platform provides.

Production and financial processes. Coordinating typesetting, cover, and print; publishing contracts and royalty settlements; invoicing; stock. None of it is a hosting platform’s job; all of it is a publisher’s job.

Not “migrating” — completing

The practical conclusion that follows: for most institutions, the right architecture is not substitution but division of labor.

We accepted this reality from the start when designing Nasirus. For institutions whose journal is published on DergiPark (or another external platform), the journal takes its place in the institution’s storefront with its name and current issue, and the reader steps through to the platform where the journal lives in a single click. The institution manages its books, sales, production, and accounting in Nasirus without ever having to touch its journal’s life on DergiPark.

For institutions that want to run their journal processes in their own system, the full journal module is there: issue management, the table-of-contents editor, early publication, open-access modes. The two models can even live side by side at the same institution — one journal inside, another outside.

Two setups, two examples

To make it concrete, consider two typical institutional profiles.

Profile A: a university strong on journals, scattered on books. Its two journals have lived on DergiPark for years, appear on schedule, and are indexed in TR Dizin. On the book side, though: 15-20 titles a year, processes in email, sales handled as “invoice on request.” Changing anything about this institution’s journals would be pointless — the right setup is to bring the book processes, production, ISBN and stock records, and the store into the system, and give the journals their place in the storefront. The institution shows up at a single address as a publisher; the journals go on living where they live.

Profile B: a journal that wants command of its own processes. It wants an institution-specific review flow: two-stage editorial screening, section-editor assignment, custom forms, internal reporting on the reviewer pool. When a shared platform’s standard workflow cannot bend to that need, the journal may want to manage its processes in its own system and deliver the published output through whatever channel it chooses. For this profile, the full journal module comes into play — issue management and early publication included.

What the two profiles share is this: the engine of the decision is not “platform dissatisfaction” but a need for scope. Institutions that can draw this distinction put the right piece in the right place without the pain of a migration.

Three questions for the decision

You can reduce “Is DergiPark enough, or do we need an additional system?” to these three questions for your own institution:

1. How much of our publishing activity is non-journal (books, chapters, sales, royalties)? If that share is large, the need already sits outside the journal-platform debate.
2. Do our journal processes have needs beyond what the platform offers (institution-specific flows and forms, internal reporting, an ISSN-bearing storefront integration)?
3. Do we want institutional memory in one place, or is a life split across two or three systems acceptable?

If you would like to work through the answers together, write to us; in a demo we can show both the “journal outside, everything else inside” setup and the fully integrated one. Our aim is not to “move” you from one place to another; it is to give the ownerless parts of your publishing life an owner.