I’ve built a few successful products and looking back on their success, I think that the mantra that drove product development is what separated our products from the rest of the market: “products built from pain.” All of the products we’ve built were done so to relieve acute pain. Not pain we researched; pain we experienced. We built products and changed the world of software because our lives sucked.
Photograph by AlexRK I’ve read a lot of books lately on new ways of running organizations and different methods of motivating people and many of them focus on studies around jobs that require a tremendous amount of creativity or “thought workers.
Peaches and pecans on vanilla ice cream is a wonderful thing, but get some perspective on how you came to enjoy it. I have heard (and have told others), “life is too short to do something you don’t enjoy,” but the truth is there is no way to revel in everything you do at every moment; not even the most ambitious and determined hedonist can achieve this. While I don’t think he was right about everything, I feel confident Sigmund Freud nailed this one: “We are so made, that we can only derive intense enjoyment from a contrast and only very little from a state of things.
And this is it … OmniOS.
I’ve been using these computer things for a while. I’ve written what is now over 100k lines of production C code and many thousands of lines of code in a variety of other languages. I’ve seen my software run and I’ve run other people software. One thing they all have in common is their propensity to break under unforeseen circumstances. Shit happens.
On my laptop, I don’t care much. I want nice, I want convenient, I want new and pretty and productive.
My opinion is that the only reason the big enterprise storage vendors have gotten away with network block storage for the last decade is that they can afford to over-engineer the hell out of them and have the luxury of running enterprise workloads, which is a code phrase for “consolidated idle workloads.” When the going gets tough in enterprise storage systems, you do capacity planning and make sure your hot apps are on dedicated spindles, controllers, and network ports.
At OmniTI, I’ve been a part of writing a lot of open source software, my fair share of closed source software. Some of it has been shipped and some of it has been operated as a service. While it is possible (and quite useful) to take what one learns in one scenario and apply it to another, some things simply translate poorly.
I do a lot of consulting with traditional software companies that are looking to make a transition to the new world of SaaS.
I’m flying back from a wonderful event: Strata.
I gave a talk there called “Esperwhispering” that seemed to pique many people’s interest. This is the stuff you do when a database just doesn’t have the horsepower to answer your questions fast enough.
Esper is an excellent, open-source CEP tool. It’s a shame its GPL, but hey… you can’t win ‘em all.
We use esper to power many things internally at OmniTI and our clients and Esper is the code CEP engine we use to make sure Circonus custsomers know when “things go wrong.
