> I still have 0 employees and don't plan to hire. I tune my business processes to run as lean as possible: Most of my customers are on credit card so their payments are automatic. The gem servers take about one day of maintenance per year. I can't really outsource much of my support work because it is so technical and specialized.
> My gem server is a $6 droplet on DigitalOcean. Because gems are just static files, that little droplet can handle millions of requests per day with just Apache. Oh, and I run three servers in parallel for failover purposes for a grand total of $18/mo.
I wonder what makes Sidekiq special? I don't imagine any equivalent product (background job processing) in the other languages is raking in that much, if making any revenue in the first place.
I'm closer to $10m than $1m in annual revenue now.
My take on Sidekiq's secret sauce: a job system is a distributed system. Most of Sidekiq's commercial features are available as OSS gems but the complexity sneaks up on you as you integrate 3-6 of those features together. Building your own almost always leads to a worse system than the mature, well-debugged system which I have curated.
- Do you have any outside hired help? I see you still have no employees, but do you contract with anyone to do customer support as an example?
- How many approx customers do you have these days? $10M revenues = 10,000 customers. Is that roughly correct, if so - wahoo, congrats.
Mike has built a system that's rock solid, and he doesn't twiddle around with it willy nilly. He keeps it super stable.
The people paying for it (I'm one of those people) are paying for the reliability, in addition to the features.
Mike's also managed to find a real sweet-spot with the features he holds out for Pro/Enterprise. The stratification is just right to nudge you up, but it always feels like you're getting a good deal when you pay.
Time, know-how, and long term dedication are the key ingredients from my perspective. Maybe he's working 10-20 hours now, but there's support and development every day for the past 11 years.
> I don't imagine any equivalent product (background job processing) in the other languages is raking in that much, if making any revenue in the first place.
I guarantee, there are background job processors in other languages making revenue.
I had no idea until someone just hinted me that this was self-referential... LOL, apologies for the now-embarrassing other comment I made LOL (I only know you as "sorentwo", whoops!)
Yeah, I had a Sidekiq question on StackOverflow and Mike Perham answered himself couple of days later.
[0] https://www.indiehackers.com/podcast/016-mike-perham-of-side...
I quit my job to go full in with EmailEngine exactly one year ago, when MRR for EmailEngine was $500, now it is $3,900 and steadily growing. I do work full time on it, but the result is async - the work I put into EmailEngine today brings me income sometime later, and the recurring income I receive today is unrelated to any effort I put into the company right now.
I googled “emailengine” and it’s wasn’t super obvious which was your business since so much paid ads exist for that search.
Do you have any concern that a customer is going to look under the covers and re-implement your product? I would guess the overwhelming majority of customers are going to be happy to just consume the API and go about their own business, but some products attract copycats, and handing out code / build artifacts makes that easier.
The tradeoff you've made makes a ton of sense if you're not concerned about copycats.
Granted, it still does kind of suck to implement even these three, but I'm sure it would likely suck less if I were part of a bigger enterprise who could afford Nylas for example, which I looked into but seemed too enterprisey for my needs.
If you're worried about copying the API design, well, the implementation is the hard part, not necessarily the API design, which the Google vs Oracle lawsuit also showed, interestingly enough.
My thinking has always been that those who try to hack the license validation stuff and replace the missing build pipeline were never going to be my customers in the first place, so every second I would spend on them is a wasted effort.
[1] https://github.com/postalsys/emailengine [2] https://imapflow.com/
Any other great ideas?
This is why I love the ruby community, so much sense :)
It doesn't have to be like this. Your community tried to be better once. Have you forgotten?
https://jasonfleetwoodboldt.com/courses/stepping-up-rails/ma...
1. When deploying a Rails app, the JS asset compilation is always the slowest part and is the most likely to break.
It doesn’t help that Rails has made a complete mess of JS assets, which I wrote about at https://fly.io/ruby-dispatch/making-sense-of-rails-assets/
2. For people who had to ship a Rails API + JS SPA, their workflow felt slow, brittle, and cumbersome. It wasn’t their imagination either—testing the stack required integration tests, which are always slow. Maintaining an HTTP API to talk to the SPA is additional effort that’s not needed, which Hotwired has demonstrated clearly.
I still think Rails has a lot of fuel left in its tank, thanks to Hotwired and the big companies behind it, but I agree the “Rails is the most productive framework” gets way overplayed. It was def “most productive” 18 years ago, but most other modern frameworks took notice, caught up, and have even surpassed Rails in a lot of ways.
The Ruby runtime leaves a lot to desire when you compare it to runtimes like Elixir/BEAM, Go, etc. I also think Rails has a terrible view layer, but most folks don’t quite understand that that means yet. This is something I’m working on at the moment.
Regardless, it's probably better if we leave room for little jokes with each other.
I wish they felt like they had some punchlines though. No one ever bothers to make the JS world laugh along. We know it's wild here (Come play! So much fun freedom!). It comes off more like a beat down.
Context also matters. Conversationally Mike's words could be an amusing wink & grin quip. I can see that. On paper, & seeing it repeated with the same reckless unnuanced antipathy, it lacks the personal connection & feels indicative of a general attitude situation that is quite prevalent.
Again I think there's plenty of valid negativities in js, but looking at the distribution of where folks fall on the alignment chart when they talk about JS issues, it concerns me how lopsidedly & with what casual acceptance folks tend towards the scariest boxes of the chart. To me we are all in the challenge of making computing better together, & we can help ourselves by helping others.
OK, maybe it's only, say, 96% of Ruby users, or 100% of Rails users at least
It costs nothing to actually put down a reason for being upset, versus having totally generic downputs. Very few things are truly rotten to the core, most bad things have some bad aspects but could be much better if ___. If something is rotten to the core the central articles of faith for why that's so should be declared.
Plenty of Ruby folks have gone on to do great friendly Rails ish JS works. Ember.js is very batteries included, tries to show that yes all the potential is there to pave a nice well integrated happy-path system. To assume misery seems unreasonable; many have done fine.
I think we have a real obligation to do better to ourselves & one another than to foster shallow prejudices. Trump in his April 11th Tucker Carlson interview was asked why he thought Dems weren't worried about nuclear weapons. "That's because they don't understand life. That's because they don't understand what it is that you have to understand." This is an irrefutable claim. There's no point to start discussing here, no possibility that the other side might change or have some nuances. Let's not do this. Let's rise to higher places where we take real appraising concerned looks at things, rather than just dismiss stuff out of hand. We don't even have to be nice, but let's at least strive to be somewhat useful.
Mike has always struck me as a great guy, really the kind of person who you're happy to know is building one of your favorite tools. In a world of starving open source contributors and mega corps throwing around weight, his success with Sidekiq stands out. It makes me very happy to see.
But for people who are interested in alternatives, I'd also suggest Good Job (runs on Postgresql).
This makes me curious about either
(a) conflict-of-interest rules at The Clymb that may or may not have governed the DTO directing the company to use his own separately-owned (commercial?) software.
(b) negotiating private ownership of software written for The Clymb.
One of those must have been relevant?
I never charged The Clymb to use the software. Previously they had been using delayed_job and were suffering badly from scale issues due to the use of MySQL as their queue store.
I've been using sidekiq now for almost a decade and had the pleasure to meet Mike at a Ruby conf many years ago.
Instead, we shell over the negligible monthly fees, spend no time thinking about it, and move on to solve real problems.
There are enough of us that it probably simply doesn’t matter.
I don't even necessarily disagree with your point that without being free those things wouldn't have taken off but we need to find a way to strike a balance in the developer community.
Sidekiq having a free version and an enterprise version walks an okay middle line imo.
So many communities across the web rely on people putting in their spare hours for free just to enjoy things. Whether it's spreadsheets in Eve, Addons and Weak Auras in WoW, forum analysis posts, or whatever goes on in the depths of pvpoke, so much free labor underpins massive parts of the world today.
I would love something that I could donate x money to per month and then based on usage, have it dole out to all the content providers with perhaps a minimum per month. It just seems daunting to do that as a) not a crypto scheme and b.) across all the various creator landscapes.
[0]https://www.polygon.com/2018/9/25/17901552/world-of-warcraft...
I don't see the problem in having that kind of business model, it still allows the community to thrive and offers entreprises a way to have premium support.
Plus it allows him to invest more time in maintaining the free version.
In sidekiq without super_fetch (a paid feature), any jobs in progress when a worker crashes are lost forever. If a worker merely encounters an exception the job will be put back on the queue and retried but a crash means the job is lost.
Again, no problem paying for Pro, but I would prefer a little more transparency on how big a gap that is.
Here's Resque literally using `lpop` which is destructive and will lose jobs.
https://github.com/resque/resque/blob/7623b8dfbdd0a07eb04b19...
No thanks.
