Open Source strategy at

Just this week we made a tough call between a fairly proven commercial solution and a mix of new, fun, exciting and (fairly) unproven open source for messaging and last mile push technology. We went for the latter. Why?

To be honest, it came down to a gut-feeling decision. Would I prefer working for a company that used proven, stable commercial software – or would I prefer a company that thought it could get a competitive edge by using something new (and cool)?

I believe that in order to attract talent, we need to use cool, open source, technology.

On the way to work this morning I felt I should put my thoughts around our architectural strategy in writing. Here is what I came up with:

We will always favor free, open source software (FOSS) as components in our architecture.

Free as in “freedom of speech”
While we do not mind paying for consultancy services and quality support, it is important for us to avoid vendor lock-in, and any software we use should have a right-to-use license without any cost attached.

Open source software and open standards should always be our first choice.

Commercial, propriatary software need to show exceptional business value (over Free solutions) in order to be considered.

We will strive to contribute to the community by buying support from a company backing a FOSS solution or paying for product improvements that will also benefit the community.

These are the guiding principles for all software used at Unibet.

I’ll close with a quote:

Unibet has the most exciting, up-to-date architecture I have ever seen at any company.
— Jonas Bonér

Divide and Conquerer

I listened to Randy Shoup at QCon. Randy works in the architecture team at eBay. The thing that I was impressed by with his presentation was the “just-the-facts-and-nothing-but-the-facts” approach and the complete lack of buzzwords and product talk. It was like listening to a really good and concise O’Reilly book. Although I didn’t learn anything new from listening to Randy, it’s always good to get a distilled and well-presented summary of what really works regardless of technology fads.

Partition everything! Partition your system (“functional split”) and your data (“horizontal split”). It doesn’t matter what tool or technology you use. If you can’t split it you can’t scale it. Simple as that. Regardless if you’re using a fancy grid solution or just multiple databases.

Use asynchronous processing everywhere! If you have synchronous coupled systems they scale together and fail together. The least scalable system will limit scalability and the least available system will limit your uptime. If you use asynchronous, decoupled, systems then the system can scale independently of each other.

Would you want to live in your code?

I’ve had many discussions with developers on if their code is considered to be “good”, “maintainable” or “effective”. Starting today I’ll ask them if their code is habitable.

Any (building) architect would likely want to live in a house that they found had good architecture. It should be solid, functional and effective. The last thing you want is to live in a maze of abstract rooms or to open five doors to get into the kitchen.

To me great code has the following qualities:

  1. It solves the business problem, and only that.
  2. It maximizes communication. This is really key. Your code should be easy to parse and understand for humans. People are not telepathic so please write code that people can read without having to solve a puzzle or slide into a hell of recursive roller coasters. Is writing documentation often boring? Yes. Does great code need much documentation? No.
  3. It minimizes “accidental” complexity introduced by crappy frameworks (remember EJB 2.1?) or old code patterns. Keep it simple. Focus on the business problem.
  4. Great code does not take into consideration what might happen at a future date. No one can see into the future, so please just don’t try to as you are adding complexity and impacting time to market and project budget.

A great developer understands that business value provided per dollar spent is what counts.