This post hasn't been updated in over 2 years.
So the other week one of our users did a bit of wondering out loud in the comments, wondering what exactly so many developers do with all their time working on the Envato Marketplace. We were a little hurt that someone thought we only exist to jack up rates
Still, we can’t really blame him, we’ve never _really_ explained what goes on behind the scenes at Envato. I’m expecting we’re going to drag this out over a few posts over the next couple of weeks. In this post, I just wanted to briefly explain some of the hidden complexity behind the Envato Marketplaces. In many ways, the marketplace (that’s what we devs call it, “the marketplace”, all lower caps because we’re lazy typists) is like an iceberg. What the end customers see is just a shiny little protrusion popping out the top of the water, the really dangerous bits are submerged, ready to take a giant chunk out of your unsinkable ship, and much later be turned into a teen heart-throb type of movie. I may have taken that a little too far.
One thing that not everyone realises is that all of the Marketplaces come out of the same codebase, and are served out of the one server farm. Thanks to the power of Ruby meta-programming, we have a special marketplace language for defining our Marketplace’s internal structure, and all the file meta-data, and post processing, etc with the minimum of hassle.
At the Chicago staff meetup in early September, I also to give the remote staff a bit of an explanation of what’s involved in the structuring of the marketplace. One of the metaphors I used was that of a tree. I drew a pretty bitchin’ tree on the whiteboard there at the time, but didn’t take a photo of it, so I’ve whipped up a little replica.
The tree metaphor works really well for us, because in one way, it’s not even a metaphor. It’s how we built it! At it’s core, the marketplace is one huge object tree. A long time ago, our founding developer Ryan wrote a ruby library to construct object trees called Lumberjack. Our tree starts with a “Marketplace” object, and from there fans out to each of the specific marketplaces, and then “Categories”, and then I can’t tell you any more…. because that would be telling.
It’s a model that gives us both strengths and weaknesses. In some cases it speeds up development, as we’ve got a fairly refined stock media marketplace code base on our hands. In others, it slows it down, as every decision made while coding needs to be weighed up in the greater context of a network of marketplaces, rather than in one site alone.
Of our (at time of writing) roughly half million users, there are three rough categories. We have Staff, Authors, and Buyers. As you can imagine, not a lot of them are staff. There’s a fair few more users that fall into the Author category, but the vast majority are Buyers. This makes for a neat little pyramid type triangle thingo, which I’ve sketched below.
If you’re a user in one of the different slices on the pyramid, the odds are that if you’re not seeing rapid improvement in your slice, it’s because we’re hard at work on one of the others. In general, we on the dev team (I can’t speak for the rest of the company) assume that each level is concentrating the most on pleasing the next level down. We know the buyers are after good quality content, but we don’t make content, so we obviously leave all of that to the authors. We also don’t know how to attract and keep authors, we leave that to the site managers and their respective teams. We do know how to write software, and it turns out that’s exactly what the site managers need! So while the dev team are outside of the pyramid, we work hardest in supporting the site managers in their work so they can support you in yours.
For every feature a user interacts with at the bottom of the pyramid, there’s a few more further up that allow all the support, community, and site management staff administer it. You can’t have item sales, without a system for receiving money, tracking earnings, and for issuing refunds, and allowing downloads, and for analysing sales data, and so on.
You then multiply those features by 8, to handle all the nuances of the different marketplaces, then multiply it by another half million for weight of all the users it must support, and then you multiply all that by some random number, because when your CEO is a graphic designer – everything needs to be pretty
So I’m hoping with all of that, you guys will have a much better idea of what’s involved behind the scenes. In a few follow up posts I want to introduce you to the current team, and share with you some of the other technical and project manage-y stuff we do within the team to fill out the rest of the picture.