Congrats, though -- Sidekiq is one of the few commercial OSS offerings that I know of doing well in the Ruby/Rails ecosystem. Most of the others just act as friendcatchers for consulting, too.
Congrats, though -- Sidekiq is one of the few commercial OSS offerings that I know of doing well in the Ruby/Rails ecosystem. Most of the others just act as friendcatchers for consulting, too.
I work at a mega corp, and I cannot echo this enough, we have tons of "maintenance" agreements for hardware and software of all sorts, $100 is not even in the noise level for some of these agreements! Software needs to be maintained, get this done upfront, it is a total pain in the but to have something fail, and then try and push through a purchase for "maintenance" after the fact. This means that I have to get a quote, get my boss to sign off, get purchasing in the loop, etc, etc. Just have this as an annual agreement and it will get processed like everything else. 10 years later, someone will ask, who uses this, and no one will know, and it will get renewed, just because they don't want something to fail ;)
http://www.joelonsoftware.com/articles/CamelsandRubberDuckie...
Enterprise sales cycle is EXPENSIVE, so, while the actual cost of your service may be much less, you have to pay for the ten airplane flights and meetings and hotel rooms before you close your sale (and add a few one afterwards for good measure).
also
http://cdixon.org/2010/02/06/selling-to-enterprises/
"Enterprise-focused VC’s sometimes refer to products priced between (roughly) $5k and $100K as falling in the “valley of death.” Above $100K, you might be able to make a profit given the cost of sales. Below $5k you might be able to market your product, hence have a very low cost of sales"
I'm not sure if all of that advice applies to a Ruby gem... big freaking enterprises don't use Ruby that much.
That said, it's a great success story :)
Somehow all that process must work for buying paper clips and pencils. Yeah, they buy those in huge amounts, but I can not conceive that they pay much of a premium. I know that governments have streamlined process for those situations. Don't corportations also have shorter procedures?
But others don't, the one I work for has a generic process for software/development tools, which must be budgeted for one year in advance.
Of course not. Ruby is slow, dynamic, and uses a ton of magic. Ruby is inherently more suited to smaller developers, who can use it to generate code, run scripts, embed it in things, and make use of the magic to be productive (things like generating C++, Fortran, or HTML).
Firstly, I am not a huge fan of Ruby, but ruby isn't magic itself, just Rails, which is a piece of crap.
Secondly, 'big enterprises' tend to employ a lot of mediocre or poor developers, and as a result have gigantic code bases to do more poorly what might be done with 1/100th as much code. You say Ruby devs use 'magic' like code generation. Big Enterprises use copy and paste.
Also, in case you woke up from a coma, it's not 1997 and everyone generates HTML. What do you think 'big enterprises' do? Type the same header into 50 million pages?
I'll agree that Rails is crap, but Ruby most definitely isn't.
There's some interesting stuff going on in the Ruby world, mostly coming out of Japanese universities and research institutes. And Ruby certainly does have bits of magic, which is why it's so easy to write DSLs and code generators... Not saying other languages can't do it, but in Ruby everything is made pretty easy.
For a while, we tried making money off support contracts for Phusion Passenger. The amount of money we made with that put us far below minimum wage. It turns out that with Phusion Passenger, nobody needs good support. Some people may have trouble setting it up (mostly people who are not familiar with Unix, and don't have money for a support contract anyway) but for the vast majority of users, Phusion Passenger just works and never stops working. By making our software stable and user friendly, we were essentially shooting ourselves in the foot revenue-wise.
We didn't want to cripple Phusion Passenger to make more money off support, so we ended up selling Phusion Passenger Enterprise which only differentiates on features, not stability. This latter model turns out to be far more successful and has skyrocketed open source development to new highs.
I've learned a lot in those 20 years that made me realize that it's not that simple, but stories like yours make me keep coming back to it.
On the other hand, how hard have you tried to market support contracts?
I noticed the really poor use of Internet systems in international development aid. More than $120 Bn is spent yearly on this, and nobody really has a clue where the money goes. There is no useful overview. So we started building tools to fix that and supply them as a paid for service.
Everything we build is open source software. We have 45+ people working on this, with paying partners such as the World Bank, UNICEF, Liberian government, Mars Chocolate and many hundreds more. It is not your ordinary business model, but it works and we are growing. You can make open source software and earn a decent living.
¹ http://www.thinkopensolutions.com/SoluçõesOpenERP/CasosdeSuc... (Portuguese)
Will be happy to hear your views though (will send you a separate mail on this).
We avoid technical implementation services, as most organisations we work with have a really low internal technical knowledge. If we then take the responsibility for implementing the technical side, we find that they don't take the ownership of the bigger issues. These are things like learning to publish open data and the changes in culture which this implies in the organisation. Then their failure to embrace the change needed in the organisation is projected as our failure to implement the technical side.
We have technical account management, but require for our partners who implement our tools to either have in-house the required technical skills or hire in the required skills. If they don't do this we don't do the projects, as they are very likely to fail.
- We brought together domain experts as equals, i.e. people working in international development, water and sanitation issues (our starting market), network organisations, computer software and services, computer software marketing and communications, to solve a problem.
- We say our team is a three legged stool. Partner team (more about that below), software team and communications team. If we don't treat all three equally the stool falls over. We go so far that we think it is imperative to not have an organisation run by the tech or the international development side, but by both sides. So we have until know had two directors of the organisation, one from each domain. Working very closely with the comms director.
- Maybe most importantly though, we have a very experienced partner team. They have worked in this market for decades. They know "everyone". We literally have connections to thousands of organisations through our networks and we understand how to talk to those organisations. Our partner team know where all the gremlins are and how the processes work. They know how to get the required startup and expansion investments as well as how to get the big organisations to use our tools.
About the partner team. We don't consider us having any customers. We treat all of the organisations that work with us as partners. They then treat us as partners too and it completely changes the relationship when you are trying to solve a problem. Of course it helps that we are a non-profit foundation. (We are also not-for-loss. We have a functional business model. This is critical.)
In a traditional company our partner team would consist of strategic sales people, account managers, project managers, consultants, trainers etc. We have a partner team that fulfils all those roles, but they are a _partner_ team. Sales are not done on a quota, no bonuses are paid (which often drive really crappy sales in a s/w company) etc.
We have no marketing and PR team. We have a communications team. Most of our staff communicate. Everyone is in fact encouraged and empowered to speak for the organisation. The communications team just supports everyone learning how to communicate well. We hardly do any PR. We may need to increase it, but it mostly does itself based on our peoples open communication.
I could write a lot more, but we are creating the Akvo Handbook, which will outline all of this, and be available under an open content license. You can read it all there then. But don't hesitate to ask any specific questions you may have.
Does it cover upgrades to work with new versions of another OS/framework/database whatever? Does it cover new functionality? Does it cover bug fixes? If so is there an SLA? Is it limited in some way? X incidents? Y hours of your time?
There are such a range of these things that if you're not careful you end up with disappointed customers when it could easily have been avoided.
That's not to say it has to be comprehensive. Corporate organisations will pay a lot for a small amount of peace of mind, but make it clear.
One is our own product that is very costly to maintain (reverse engineering third party applications) and some customers agree that they need to have this additional service.
Another one is for complex application virtualization. For example, we give the technology for virtualizing IE6 on Windows 7 and 8 but some Microsoft updates break the solution and the company needs to have an "insurance" against that.
Simple support gives a lot of headache.
Just wanted to say I love following your blog - And this is definitely something that's been engrained in my mind after reading it, and I'm glad you've reiterated here.
If anyone would like to follow him - here's a link to an arbitrary archived newsletter that he's published where you can sign up: https://training.kalzumeus.com/newsletters/archive/sources_o...