Today, I had a mostly enjoyable lunch with Peter, CEO of a company focussed on Embedded Linux, a smart and like-minded guy who works in an entirely different market as we do, but also cares a lot about open source and ethic business models. Meeting Peter is like facing a mirror when doing a speech rehearsal, his careful questions bring out the best in you, and his down-to-earth, no-nonsensical way of looking at things mixes very well with my ideas about doing business on the frontier of open source.
The theme for this lunch was his curiosity about what we do, and how we do make a living out of it. Since he's also been going through rough company periods during his time, and is prepared to speak open about it, I felt free to describe at length our past 2 years (nearly there!) of existence, and the running thread throughout our activities, AKA our business strategy. Mind you that we don't quite discern ourselves a strategic direction in much of our daily activities, but in the end, we seem to be heading somewhere, so after two years, I can now safely stand up and do the elevator pitch of Outerthought, with facts and figures to back my claims.
After lunch, there was a meeting (which Peter attended as well) with the peeps who would be organizing this new Open Source Center initiative, with the obligatory roundtable of presenting ourselves and our companies. I spoke frankly, and rather well prepared since I just had been doing the same with Peter over lunch, about the things we believe that differentiate ourselves from the rest of the pack, or should I call them our "concullegas". During the lengthy ride home, I had a phone call with someone asking whether we would be interested to do a project for his organization, and again I had to explain who we are and what we do, a polite way of saying 'no', since his enquiries didn't fit with our - ahum - business strategy.
So after several confrontations with the mirror, I'm now sitting here, and wondering why so many people apparently have issues with understanding Outerthought as a business entity, and I now feel it might be appropriate to try and jot it down, hopefully attracting some reactions.
In explaining our activities, there's two main focal points: we don't do turn-key projects for customers, and we have a very narrow technical focus.
The turn-key thing has the side-effect that we require developers to be present at the customer's side, since we will learn these internal developers how to do the job themselves, quite possibly using a toolset and/or framework that we prepared for them, accompanied by formal training or on-the-job coaching and mentoring. When Marc and I started to plan the startup of our own company, we had this presentation, which we created more for ourselves than we have ever used it for sales purposes, which had a slide quoting a very old proverb: we prefer to teach people how to fish, rather than feeding them with canned seafood. And this still very much is true, as a matter of fact it is becoming something we explain very early-on in our sales talks. As of now, having developers at the customer's side has turned into a requirement rather than a nice-to-have. This has three main reasons: 1) we suck at the business-side of things, since we are really hardcore technical geeks in our domain, so we tend to make abstractions of the business domain anyhow, 2) it is in the interest of the customer, as a radical implementation of the OnsiteCustomer practice known from XP, and it is the only guarantee they will effectively become the owner and master of the project after we quit, and 3) in order to provide our customers with deep-technical advise, we need to expose ourselves as much as possible to the communities where such knowledge is grown and cultivated (community mailing lists, open source projects, etc...)
The knowledge transfer bit we are doing really is a side-effect of the fundamental difference between business developers and technology developers. We are very much technology-driven, where as a developer sitting at the customer's side has the customer's business to support as his highest priority, eventually reducing the amount of time he can spend on exploring technological ways of addressing the business requirements.
The other thing, and my personal pet peeve, is FOCUS. There's a lot of peeps out there who carry a CV listing a gazillion of frameworks they are (vaguely) acquainted with, and plenty of companies who will support or implement every framework the customer asks for. We realized that, with the three of us, we can only focus on one technological domain, which we now shortly describe as the crossing of Java and XML used in the context of building web applications, more specifically using Apache Cocoon. Which means the list of things we don't do is very long: EJB, Struts, JMS, O/R tools, WebWork, Tapestry and many, many others. Does that mean we are dumb or lazy, compared with others? I would beg to differ, since 1) we actually are quite smart ;-) , and 2) we believe being smart is all about focus. We can confidently state that we know Cocoon inside-out, and that we are able to do many, also non-obvious things with it. We know for sure we could do the same with Struts, and we know that we are able to learn and understand EJB upto the same level, but alas, since we're only three, we prefer to be focussed and very good in one thing, than being average in lots of things. We get our versatility because of the depth of our Cocoon knowledge: while some other platform could be equally well suited (or better) for a certain task, we actually know much faster how we could implement this inside or using Cocoon. And the fact that Cocoon really is a Swiss army knife, and comes - in pure Python style - with batteries included, sure helps a lot with that. So while diversity is required to win the rat race, we believe we should look for this diversity inside our knowledge about Cocoon, rather than shifting away to another tool or framework just because it sells better. We know we can do the job, while really understanding what we are doing, better, faster and more robust using our singular framework offer. Our focus is good, also for the customer: 'better' and 'faster' are really important to him.
OK. So much for mirror-gazing tonight, I'll get some sleep and maybe add onto this later on. BTW: we are lazy, of course, but laziness is a virtue. Hm. I must be a geek, spending another 10 minutes in researching that link. But let's face it: mr. Wall has some spiritualizing ideas. If only the syntax wasn't like modem noise.
nice read. i fully agree wit u & i must say ur company's decision is a great show of bravery, risk & discipline. when i wuz in school, i decided 2 do java only cos there wuz so much u could do wit it alone. now, i am doin web development and i wished i could do javacard, j2me, etc too, but no time. a couple of us r plannin 2 start a firm soon and this blog entry has been very useful in convincing me that there is hope in doin bizness in open source java. yes, the 4 big boyz of java web mvc are Tapestry, Webwork2, Cocoon and Struts (in deliberate order:)) but i wont rest until i understand and leverage on all of them.
Thanx for the advice.