Marketplace software: self-hosted open source classifieds, compared

The word marketplace covers two very different obligations. One is self-hosted classifieds software — a noticeboard: listings, categories, a contact form, and the two parties settle it between themselves. The other sits in the middle of the transaction, takes the payment, holds it, releases it, and answers for it when something goes wrong. The software looks similar. The operator's life does not.

Self-hosted classifieds software answers the first obligation and is the smaller commitment by a wide margin. An open source marketplace platform that carries the money answers the second, and brings payment handling, dispute resolution and a regulatory surface with it. Both are marketplace software; only one of them makes you a party to the sale.

The 7 entries catalogued here split along exactly that line — 2 are classifieds, 2 carry the transaction, 2 are commerce cores you assemble a marketplace on top of, and one is a member network that ends up doing listings because that is where its users took it.

Self-hosted classifieds software is the answer more often than it is chosen

Osclass and Yclas do the noticeboard job. A seller posts, a buyer sees it, a message goes between them, and the software's involvement ends there. No checkout, no escrow, no payout schedule, no chargeback.

That restraint is the feature. A classifieds operator has no financial relationship with either party, which removes almost the entire compliance surface at a stroke — no money transmission, no holding client funds, no dispute process that has to exist because you took the payment. Revenue comes from the listing rather than the trade: paid placements, featured slots, a fee to post in a commercial category. Both of these platforms have that model built in because it is the one that fits.

The usual objection is that the platform captures no share of the transaction value. True, and it also captures none of the risk. For a regional site, a hobby niche or anything under real volume, listing revenue on a system nobody has to babysit beats a percentage of trades that are not happening yet.

Carrying the transaction changes what you are

Sharetribe and Cocorico both put the platform in the middle. A booking or an order is created, payment is taken, the platform holds it until the service is delivered, then pays the provider less its commission. That is the model every marketplace pitch deck describes, and it is a genuinely good business when the volume exists.

What arrives with it: onboarding sellers as payment recipients, which means identity checks; a payout schedule and the reconciliation that goes with it; a dispute process, because somebody will say the thing never arrived; refunds and chargebacks, which land on the platform rather than the seller; and tax treatment that depends on whether you are the merchant of record or an agent. None of this is exotic. All of it is work that exists every week, forever, and none of it is visible in a feature comparison.

The practical consequence is that transactional platforms couple you tightly to a payment provider, because that provider is doing the seller onboarding and the split payouts. Changing it later is not a settings change; it is a migration of every seller's payment relationship. Choose it as carefully as the software.

Cocorico's particular shape is worth naming: it is built around availability and time slots rather than stock. If what is being sold is an hour, a room or a piece of equipment for a weekend, a calendar-shaped marketplace fits and a stock-shaped one has to be bent into place.

Commerce cores: open source marketplace platform as a starting point

Medusa and Saleor are not marketplaces. They are commerce engines — products, carts, orders, payments — with an API and no opinion about the storefront. People build marketplaces on them by adding the multi-seller layer themselves.

The distinction cuts the catalogue in half. Self-hosted classifieds software starts from the listing and adds payment only if you ask; an open source marketplace platform built on a commerce core starts from the order and has to be persuaded that a listing is not a product. Neither direction is wrong, and retrofitting either one into the other is where the open source projects here most often disappoint people.

That is the right choice in one situation and the wrong one in most: right when the requirement is genuinely unusual and the team can carry a custom application, wrong when somebody read that headless is modern. The cost is not the core, which is good software. The cost is that a storefront, an admin experience and a seller portal are now yours to build and keep, and the marketplace-specific parts — commissions, payouts, seller onboarding — are the part nobody estimates correctly.

HumHub sits oddly in this category and earns its place honestly. It is a social network for members, not a shop, and organisations keep pressing it into service as a directory with listings because the membership and permissions already exist. If the requirement is really "our members should be able to offer things to each other", that is a smaller problem than a marketplace and a member network solves it.

Listings have a lifecycle and it needs a policy

Every marketplace acquires dead listings. The item sold elsewhere, the seller lost interest, the service stopped being offered. Nothing about this is technically hard and it is the most reliable way for a site to feel abandoned while still being maintained.

The three mechanisms are expiry, renewal and reporting: listings age out after a set period, the seller is prompted to renew, and buyers can flag something that is no longer available. Classifieds software generally has all three because the model depends on them. Transactional platforms often assume the transaction closes the listing, which is true for goods and false for services.

The related decision is what happens to the address afterwards. An expired listing that returns a not-found page throws away whatever search traffic it earned. Keeping the page, marking it clearly as no longer available, and pointing at the category is better for everybody, including the seller who might list again.

Search and filters are the interface, not a feature

On a forum, people read. On a marketplace, people filter. Location, price band, category, condition, availability — a buyer arrives with constraints and the software's job is to subtract everything that does not meet them. A marketplace where that is slow or imprecise gets browsed once.

This is where classifieds software earns its category. Osclass and Yclas both build the listing model around structured attributes per category, so a car listing has mileage and a flat listing has floor area, and both become filters without custom work. Commerce cores approach it from product variants instead, which fits stock and fits a used-goods noticeboard poorly.

Location deserves particular attention because it is the filter most marketplaces need and the one most often bolted on. Radius search requires coordinates, a geocoding step at listing time, and an index that can answer distance queries. Platforms that have it built in save a genuinely awkward piece of work; platforms that treat location as a text field produce a site where "near me" does not exist.

Photographs are the listing

Nobody reads the description first. A marketplace lives or dies on whether sellers upload usable images, and the software influences that more than it appears to — an upload flow that rejects a phone photograph for being too large loses the listing entirely, because the seller does not go and resize it.

What to look for is server-side handling: accept what the phone produces, resize and re-encode on arrival, generate the thumbnails, strip the location metadata. That last one matters more than it sounds. A photograph taken at home carries the coordinates of the home, and a marketplace that republishes them has quietly published a seller's address.

Marketplace software earns trust through the boring features

Reviews, verified identities, transaction history, response times. None of it is interesting to build and all of it is what makes a stranger willing to send money. A marketplace without any trust signal competes only on price, which is a race it will lose to whoever is willing to be careless.

Sharetribe ships reviews as part of the transaction flow, which is the correct coupling — a review means something when it is attached to a completed trade and very little when anyone can leave one. Classifieds platforms typically have no review layer at all, because there is no transaction to attach it to. That is a fair reason to move up to a transactional platform, and a much better one than wanting the commission.

Messaging, and why it usually has to stay on the platform

Every marketplace has to connect two strangers, and the tempting shortcut is to publish an email address or a phone number. It works, it is free, and it hands the relationship away along with any ability to see what happened.

On-platform messaging costs more to build and returns three things a direct address cannot: a record when a dispute arrives, a spam filter that protects sellers from harvesters, and the basic knowledge of whether listings are generating conversations at all. A marketplace that cannot tell the difference between a dead listing and a busy one is guessing about its own health.

Both classifieds platforms here relay contact through a form rather than exposing the seller, which is the minimum. The transactional platforms carry a proper thread attached to the booking, which is the version that survives a disagreement.

Choosing between the three shapes

Start with what happens after two people agree. If they arrange it themselves, you want classifieds and you can be running this month. If the platform takes the money, you want a transactional marketplace and you should budget for the compliance work before the software. If neither fits because the model is genuinely unusual, a commerce core plus a build is the honest path, and it is a project rather than an installation.

The order that fails is the reverse one — adopting transaction software because payments are on the roadmap, then spending the first year maintaining a checkout that has processed eleven orders.