Thanks to the devot:ee Store, it has never been easier to turn a little pet add-on into a commercial profit-maker. And no doubt the prospect of earning dosh for brilliance has attracted strong talent to the EE community. But amidst this fevered gold rush, are we customers getting our money’s worth?
This is a topic I've been chewing on for a while - biting my tongue at times - struggling to formulate my thoughts into something constructive. In the two years since becoming part of the amazing EE community, a lot has changed. One particularly significant change is a swift and steady move towards commercial add-on development - a move that is starting to feel more like a greed-fueled money-grab, than an indication of higher quality software.
Don't get me wrong: I am all for commercial add-ons. At our studio we lobby every day to convince clients that our time and expertise is worth the money we charge. Developers of quality software are equally deserving of fair compensation. So what I am not saying is that I will not pay for your add-on.
I will happily pay for your add-on. But as a paying customer, I will expect a certain level of product and service. I will expect to get my money's worth.
If you plan to develop commercial add-ons for ExpressionEngine, understand what you are agreeing to - understand that you are becoming part of the EE Community, and as such are expected to uphold the spirit of that community: generosity, transparency, responsibility, and professionalism. We are an incredibly eager group of talented professionals that wish to see each other succeed as much as ourselves.
In that spirit, here are 10 "DOs" and "DON'Ts" of commercial add-on development that I think we all should live by:
1. I will... Put my name on it
Take for example just a few pillars of greatness: Brandon Kelly, Leevi Graham, Ryan Masuga, Brian Litzinger (I could go on)... I inherently trust and am willing to invest in their add-ons, not simply because from experience I know them to be excellent, but because they put their name on it. They have placed their personal reputation on the line, alongside the reputation of the software they build, which demonstrates a long-term commitment to keeping their products up-to-date and feature-rich. It's also peace of mind that if something goes wrong, I will know who to turn to for help.
Marketing yourself under a clever name is totally fine, just be sure to let us know who's behind it. Lobster War Machine is an excellent (and hilarious) example - it takes just a few seconds on the website to know that Jack McDade is the LWM developer - yes, the same Jack behind the indespensible Structure (also brought to you by Travis Schmeisser).
See how much you suddenly trust that gnarly-looking crustacean?
2. I will... Register my add-on with devot:ee
I shouldn't need to mention this one, but better safe than sorry. Even if you decide to sell your add-on elsewhere, it's immensely helpful to have your add-on registered on devot:ee. And when you do put your add-on up on devot:ee, give as much information as possible: compatibility with other add-ons, hooks used, documentation links, image previews, etc.
3. I will... Provide publically-accessible support
Prior to the launch of EE2, probably 99% of all EE Community activity took place in the forums, and for many of us this remains a natural format for seeking & offering help when things go wrong. EllisLab no longer hosts 3rd party add-on support on their forums, but that's where devot:ee has once again stepped in - with every add-on submitted, a specific forum is instantly made available (whether you like it or not, which I think is brilliant).
If for some reason you don't want to use devot:ee's forums, then consider Get Satisfaction or Tender Support. But please, offer more than an email address to send to. To me that either says:
- You don't want to broadcast to the world when someone encounters a problem with your product, or
- You will probably not respond in a timely manner to my support request, but do not want evidence of your slow response time, or
- You're just lazy
4. I will... Maintain comprehensive and up-to-date documentation
This is critical, and if you do not take documentation seriously, then I will not take your product seriously. Document everything that relates to:
- pre-sales questions, such as features, screenshots, video demos, software requirements, 3rd party compatibilities
- installation, upgrades, release notes, general usage guidelines
- FAQs, common pitfalls, what to do when something goes wrong
5. I will... Charge an appropriate pricetag
At times I've considered building open-source alternatives to commercial add-ons that I didn't think were worth paying for... Clearly I'm not the only one.
Yeah, this is a tough one. With every product there is a sweet spot for pricing, and the EE market is perhaps still too fresh to know exactly how to calculate this number. And in theory yes, if your client wants the capability your add-on provides, then your client should be willing to pay for it.
Still I think it's only reasonable to be sure the pricing of your add-on fits appropriately alongside the baseline cost of EE - $300 USD. Second, consider that sometimes your add-on is as much for the person building the site, as it is for the client requesting a particular feature (Low Variables is a good example). In which case a lower price point might gain a higher sales volume, making you more money in the long run.
I can't help but feel some #eecms commercial addons are just taking the piss charging.
@leevigraham via twitter, about 30 seconds ago
If your add-on adds considerable capability to a site, such as e-commerce options BrilliantRetail and CartThrob, then you are more justified in charging a higher amount. Again, look to EE for a guide - the Discussion Module for EE is $100 USD.
However if your add-on simply scratches an itch or does something very specific, I'd price it very carefully - personally anything above $25 USD and I will start to seriously hold your feet to the fire on this entire list.
6. I will not... Build it once and never update it again
Strangely, when I see a commercial add-on staying at or near a "version 1.0" release for ages, it tells me the developer has checked out. Either that, or it was such a simple add-on to begin with that there's nothing else to do to make it better. Perhaps then I can just build it myself in a day or two (or an hour or two).
7. I will not... Release something utterly broken
Sounds absurd, right? You'd be surprised - just last week I purchased an add-on that straight out-of-the-box didn't work. It was missing an important file, which is a simple mistake but potentially costly - and more importantly not professional. The developer behind the add-on was extremely swift in resolving the issue (and even went so far as to give me a free preview to another of their commercial add-ons), but it still stung. It will take a lot to regain my trust in that developer.
8. I will not... Charge you for an add-on that I developed for a client
Update: community feedback has challenged this one quite a bit. The general consensus agrees that if the client is aware of your plans to release a commercial product off the back of a job, then fair is fair. Again, the overall message of this is about ensuring the spirit of the commercial venture is pure. Jump to the comments for more.
I realise this is possibly contentious, but it plain seems a bit cheeky to be paid by a client to develop a bespoke plugin, and then turn around and charge us as well. It reminds me of the Costanza's double dip fiasco:
You dipped the chip, you took a bite, and you dipped again... that's like putting your whole mouth in the dip!!
Here's the thing: when you were paid by your client to build that bespoke plugin, I'm 100% certain that at some point, you got help from the community at large - either by pulling apart someone else's add-on, sending out a tweet, or getting help in a forum. With that help, you delivered a product to your client and were paid (handsomely I hope) for it. And as thanks to us, you turn around and charge us money to use it? Come on.
The possible exception to this is if you promise to obey the #6 I will not... rule and commit to making the add-on better and better over time.
9. I will not... Encrypt my software with IonCube or similar
Not everyone will agree with me on this one either, but encrypting PHP code that I paid for sucks. It seems to go completely against the spirit of PHP in general, but certainly against the spirit of the EE community. If nothing else, it ties my hands to investigate potential bugs or issues with the purchased software - I am out of luck to help myself, at the mercy of the developer to (hopefully) provide me with an update.
10. And if you won't...
Well, I don't think you should be selling your add-on. Look, I'm not trying to shut the door on anyone, but I worry about our collective future successes. Change is afoot in the EE universe, and I think it's only prudent that we do what we can to ensure we are changing in the right direction, and for the right reasons. Pure, unadulterated profit should not be one of them. And in fairness, the above should apply to any commercial software product, and shouldn't be unique to ExpressionEngine.
Have your say...