read

Magento extension development can be hard work but rewarding! Want to know what life is really like as a Magento extension developer? Read on.

Let's start by tackling the stereotype head on. Magento extension developers - you know the type. They write a piece of code once and sell it forever as a digital product. Updates are minimal. Support (if any) is outsourced for pennies on the dollar. The ideas aren’t even that innovative - tons of extensions have at least 10 competitors and sometimes, it’s hard to tell them apart.

All that’s really left to do is for extension developers to sit on their golden thrones (lined with plush red velvet of course) and watch the money roll in. Day after day. Year after year. Not bad for a couple of hours work 5 years ago coding a simple plugin, right?

If only.

I wanted to share my experience of nearly 8 years in the Magento extension development world. I’ve been in this game full-time since 2009 (what!?). It’s an awesome job that I wouldn’t trade for anything in the world. But let me tell you - like most jobs, this requires hard work.

I thought it would be fun to break down the top 5 myths about extension developers. Sorry if I shatter anyone’s fantasy.

Here goes:

Myth 1: Extension developers write code once then watch the money roll in (the passive income myth)

I can see why some people might assume the Magento extension development business is a passive income model. In my experience, this is pretty far from the truth. While it’s true you’re not trading your time directly for money (one hour worked = payment of $X), it’s seriously a full-time job to maintain and support an extension once you’ve released version 1. I consider it a form of leveraged income.

Let’s leave skill level aside for now (like many developers I have put in literally thousands of hours learning Magento 1 and Magento 2, participating in hackathons, completing training etc). This is simply a prerequisite to calling yourself a Magento developer.

Let’s also leave aside the many hundreds of hours it takes to create and road-test a decent Magento extension (when you look at an extension, you see what I call the ‘nice code’. You don’t see the countless iterations of messy trial and error that was necessary to create the ‘nice code’ breakthrough). Any product worth its salt has had serious development time invested in it.

Here’s where it gets hard. Extensions are a culmination of multiple years of continuous development. Client feedback and feature requests align the extension development with actual client needs. And then there’s support (more about this under myth 2).

Maintaining compatibility is a big part of the job, and can seem like a never-ending task. These are the release versions for Magento 1.9 alone (this doesn’t include 10 major versions that came before, Enterprise Edition or Magento 2, nor any of the myriad of patches):

While I don’t create an extension release for every single minor update, I do try to aim for most of them. Each new compatibility release needs to be fully tested. Over the years I’ve built some automated tests to reduce the time I’m spending on this task. Most don’t show up any issues and can be released as a new compatible version. Every now and again, something has been changed in default Magento which means I need to re-write part of our extension, test, and then release. This time adds up.

Magento security patches occur from time to time and require urgent attention and extensive testing.

And then there’s the elephant in the room - Magento 2. This has been such a massive change in technical architecture from Magento 1. I basically spent half of 2015 and all of 2016 (in between support and Magento 1 compatibility maintenance) re-writing Fooman’s Magento 1 extensions from the ground up, to release as Magento 2 extensions. That’s an entire year and a half to get our extension portfolio about 75% of where is was pre-Magento 2. Some were easier than others. For others, we had to go back to the drawing board because literally nothing was the same in Magento 2. The extension name is about all the Magento 2 version has in common with the Magento 1 version!

I’m not telling you this to winge. Magento developers in all types of roles are in a similar situation - having to re-learn an almost completely different platform to continue calling themselves a ‘Magento developer’ - even though the market for Magento 2 is only just starting to appear.

The point is that extensions need continual maintenance and investment to stay functional and relevant. It’s certainly not a ‘write once, sell forever’ scenario.

What I will say is that having a business built on a leveraged income model has great perks - mainly time flexibility.

I can work from anywhere with a decent internet connection. My wife and I spent most of 2012-2013 in Europe and South America, living out of a suitcase and loving the laptop lifestyle. We also clocked up a massive amount of work time building up the business, often working until midnight most days of the week to fit in the work.

Back in New Zealand, my current routine is that each morning I take care of my daughter and take her to nursery school. I also try to spend an hour with her in the afternoon if not too many support tickets came in that day. But this time has to be made up somewhere, and in my case it’s nights and weekends. I’d like to change this in the future, but for now the only realistic way to get the work done is by putting in 50+ hour weeks. I work my butt off to keep Fooman offering quality extensions and having the best support - and don’t see this changing anytime soon.

Myth 2: Support isn’t that important - just outsource and forget it

Anyone can decide to code a Magento extension and release it for the world to download. The hard part is backing up your extension with genuinely good support. Extension providers can live or die by the support they provide. Word gets around quickly when support sucks - and for good reason.

I have two awesome people who help me with support - Michael and Martha. They’ve been with Fooman for years, they really know their stuff, and I am so thankful to them.

But it surprises many people to learn that Fooman extension support is still a major part of my day-to-day job. The fact is - I wrote the code, so I know it best, so I do investigate on the occasion that something goes wrong and fix it. I don’t see this changing.

No one likes having to contact support - it’s a total pain. People have enough to worry about in their jobs without having to stress over extension support. We all want things to work out-of-the-box the first time. The majority of the time they do - but in the rare case where they don’t, then it’s my job to make sure people get the best solution in the shortest number of responses.

Add then there are common scenarios like this:

  • Pre-sale questions - we encourage these as everyone likes to be assured that a product does what they need it to before buying
  • Someone’s had your extension running happily for half a year but then installed another extension which caused a problem - totally happy to investigate these
  • A developer wants to extend the extension for a custom client requirement - so we'll point them in the right direction about the best place and approach to hook into our code
  • Someone contacts you a couple of years after their initial purchase and wants to know about updating to the latest version - happy to help
  • The list goes on...

Providing quality support (not the superficial crappy auto-responder kind) costs a surprising amount of money and time. But it’s SO important in living up to our promise that customers can rely on our extensions and get the most out of them. It's what I expect when I'm a customer and it's a huge priority for quality extension businesses.

Myth 3: Extension developers are raking in the cash

Sorry to disappoint you, but this one’s also busted.

For every extension you code that sells really well, there’s usually another one that doesn’t. Some extensions might only get a single sale each month.

Let's consider the direct cost of sale of each extension:

  • Payment processing fees
  • 'Finders fee' - whether this is a marketplace commission (Magento charges 30%), per-click advertising costs, or affiliate payouts (15-50% - we generally don’t do this but a lot of extensions are sold this way)
  • Average support cost

After this the rest goes towards covering:

  • Initial time to write the extension, documentation etc
  • New extension releases, bug fixes, new features…
  • Business running costs - office, website, marketing, general advertising…
  • Giving back to the community - development and support of our free extensions, blog posts, open-source code contributions, conference presentations ...

Averaged out over the year, I’d say I work about 50 hours a week. Salary-wise, I earn roughly the same as if I was employed as a Magento developer in a digital agency where I live in Auckland. Comfortable, yes. But certainly not a license to print money, and nowhere near the wild riches the internet would have you believe that selling digital products produces!

Being your own boss comes with risk. As I’m writing this, it’s early 2017 and the future of Magento 2 is still uncertain - how soon it will take off, how many users it will attract, and how much the target audience will change. I made a consious decision in 2015 to be an early adopter of Magento 2 and have invested a lot of time and money into Magento 2 extension development since then. As most developers and agencies know, the market for Magento 2 is only just starting to emerge while the market for Magento 1 is slowly tapering off. Going all in on Magento 2 is certainly not a quick win, but I'm confident that this decision will pay off in the long term.

Myth 4: I don’t really need to buy a new license each time I use the extension (extension developers make enough sales already)...

First up: This is not a comfortable topic to talk about, but I wanted to raise it briefly because it's important. Thankfully the vast majority of the Magento community are honest, awesome people to deal with and it’s not usually an issue.

Except for a few bigger companies, most extension developers either work alone or are very small businesses. In other words - extension piracy and theft hits the little guys much harder.

The reason extensions are able to be priced low is because of the high(ish) volume sold. As a business model this is pretty standard. But what happens when people decide they don’t need to pay and honour the license agreement?

I’ll never forget the first time that a merchant contacted me for support and it turned out their (now ex) developer charged them for our extension (as a line item on the invoice and everything), but never paid us. My stomach sank and I was devastated. It turns out this developer did this multiple times. Or sometimes it’s a big agency that buys a license for one project. They love our extension so want to use it again on future client builds - that’s awesome. What’s not awesome is charging a client thousands of dollars to build a custom site, but (accidently or not accidently) forgetting to pay $150 for using our extension which saved their client from 10-100+ hours coding time.

(By the way - the main reason extension developers charge per license is due to 1) support cost and the logistics of overseeing updates and fixes, and 2) it's standard practice that developers charge their end clients per project).

I’ve also discovered extension pirates stealing our code (sometimes even a whole extension AND marketing description) to sell at a much lower price. Magento is slowly cracking down on these cowboys but I suppose with any digital product, this is an unfortunate reality. The real shame is that customers who buy won’t be covered for any support or updates, because the con-artists have no idea about the code behind the product so can't update or support what they’re selling.

The alternative to protect against extension privacy is of course to use encrypted code. But this is such a pain for customers to deal with and makes it impossible for developers to judge code quality or easily further customise our code. It's not respectful to the end user and is fundamentally not something I believe in doing. But I will say this - if a developer is taking this path and not encrypting their code, then the extension user's end of the bargain is to make sure they abide by the correct license terms. Unfortunately it's one of those things where if the problem of piracy gets worse, then more and more extensions are going to become encrypted in the future. I'd hate to see it but that's one reality if things get worse.

The moral of the story - even though an extension is a digital product, please respect the developer and purchase the correct license. It’s usually a relatively small cost compared to the rest of the project and can make the difference of an extension developer operating a sustainable business that supports their family, or not.

Rant over - I promise!

Myth 5: Extension developers are lazy and don't do enough testing

Sometimes this is true. In the Magento extension development world, there are some developers who put out crappy extensions before they're ready and the code is plagued with bug after bug. I'd be mad too if I'd been sold rubbish like this.

A reputable developer won't do that, period.

But this doesn't mean that the best extension by the best developer in the world:

  • Will support every single version of Magento (patched or unpatched), AND
  • Is compatible with every single Magento extension ever released (10,000+ publically available extensions ranging in quality from terrible to awesome, plus in-house extensions coded by developers and agencies for internal use that are effectively 'hidden' as they're never publically released), AND
  • Is tested on every imaginable (and unimaginable) server set-up in the world, AND
  • Is tested with every combination of settings (both default Magento and extension-specific), AND
  • Won't ever develop a bug related to just one of the above variables

I wanted to do a geeky calculation of how many scenarios the above circumstances would produce, but there are literally infinite combinations.

So let's break some of these things down.

I hate bugs as much as the next guy. But, as any developer knows, the occasional bug triggered by one factor in the above list is just a reality.

Just like Magento itself, plugins can develop bugs and it’s our responsibility to fix them. I’ll do everything in my power to minimise them from happening in the first place, and fix them ASAP after being able to reproduce them.

Most reported bugs I come across broadly fall into these categories:

  • Compatibility issues with other extensions
  • Magento itself not correctly set up or configured (cronjob not executing, composer not yet set up etc)
  • An issue with our code or instructions related to the specific configuration of a customer's store (the variety in commerce is huge, and while we test a LOT there are literally infinite variations)
  • Or simply where a certain functionality was assumed but not confirmed (i.e. the extension does not provide the feature than someone thought it would - that's where pre-sales questions and demos are so helpful)

It's my job to help people get to the bottom of why something is not working - and it's often not a direct issue with our extension. It's still part of the job.

The other thing I actively balance is keeping releases targeting different Magento versions to a minimum. For example, we might not make use of the latest and greatest platform feature in a new extension release if it prevents us to continuing to support merchants that use an older version of Magento (which many still do).

As most developers know, learning never stops. Like many of you, when I look at the code I wrote a year ago, there is always something that I would do "better" if I were to do it again today. Good practice is continually evolving and that's what makes working with Magento so interesting. The reality is, as extension developer I need to weigh up what actually provides value to the end user - clean, reliable code that provides helpful functionality and doesn't cause extension headaches. As much as I'm a huge advocate for code quality (there's NEVER an excuse for shoddy code, especially if you're charging for it), it's also not about writing "sexy" code that will win awards for 2017 best practice (and then 2018, then 2019 and so on...). Of course, major changes need to be kept up with - that's essential. But stable, proven code that does the job reliably usually trumps making major coding style changes and including all the 'hot features' of the current year for the sake of it.

Summary

I hope this post has given you some insight into how a Magento extension development business works. I love my job. I get to be my own boss, code my own stuff, and interact with people doing very cool things with Magento - developers, people running ecommerce agencies, and merchants that have taught themselves an impressive amount of information about how to run an online store. But the 4 hour work week, kicking back and raking in the cash myth? Sorry to say but that one's busted!

Blog Comments powered by Disqus.
Kristof Ringleff

Kristof Ringleff

Founder and Lead Developer at Fooman


Published