Me and OSGi

OSGi is much like a religion. I’ve even come up with the ten commandments of OSGi:
1. the OSGi way is the only way
2. all 3rd party code that you touch must be OSGi compliant
3. everything must be an OSGi bundle
4. every bundle must have a public part (api)
5. every bundle must keep its private parts covered
6. thou may not rely on the start order of your bundles
7. thou may not rely on a service being present
8. other bundles may be loaded and unloaded at any time
9. thou shall use OSGi in every project
10. thou shall bring the ways of OSGi upon the non-believers

Okay, it’s a bit of a stretch, I admit it. What I’m saying though about it being like a religion, is that it demands of you to follow certain rules. But if you look around you, very few people actually follow them. And if you try to follow them, you’ll find it very difficult.

Why is that? You can do your project the OSGi way, but you will use 3rd party code. Which may or may not be OSGi compliant. If it’s not, you’ll have to bundle it yourself. You can use bnd to do so automatically, but that doesn’t always work, especially for larger projects with lots of dependencies. So sooner or later you’ll find yourself spending 1-2 days trying to coerce some library into OSGi form. With maven it would be a 30 second job, but you’re doing OSGi so you’re stuck with that.

That begs the question: why do OSGi? It was initially conceived for embedded systems, which needed 100% uptime and the possibility of updating modules independently of one another, without stopping the system. Is your project about that? Then you have a valid case for OSGi. You aren’t likely to run into the problems I mentioned, since you’ll likely restrict your use of 3rd party code for reasons of size and performance.

However, most of us work on plain old Java applications. Is modularity good? Well yes! Do you need to update modules without restarting the application? No, you don’t. Do you replace service implementations at runtime? No, you don’t. Do you load and unload modules dynamically at runtime? No, you don’t.
That means for most projects the only gain is modularity, for which you pay a hefty price in the complexity of managing dependencies. There are simpler ways to ensure proper modularization.

Some web applications will need to update without downtime, but for those OSGi is not the answer either. If you need high availability, you’ll already have a cluster or a bunch of servers behind a load-balancer, which you can update without taking the application down.

Conclusion: OSGi is good for what it was originally intended for, but a real pain for most other projects.

Free vs commercial Tools

I’ve seen a few software companies where it’s important that the tools they use are free, or at least as cheap as possible. By tools I mean IDE, File Manager, Document management, Issue Tracker and so on.

These are tools that you, as a developer, use every day, 8 hours a day, 5 days a week.

When it comes to this kind of tools, I want to have the best there is. Most of the times, getting the best will cost money (not always though, sometimes free tools are better than commercial ones). However, even tiny improvements in efficiency will pay off the cost of the tool very quickly, given that you use it so often. Or oppositely, small annoyances from bad tools add up very quickly, and you become frustrated and unproductive. Instead of solving the problem at hand, you’re fighting the tools you must use. That’s a lose-lose situation.

Your company may say – hey, the tool you want costs $1000 per year, that’s a lot of money. For 100 developers, thats $100k per year! But let’s look at it another way. What does a day’s work of a developer cost? Let’s take $1000 a day. That means even a 5% improvement in efficiency will pay itself off in a month! A 1% improvement will make up for the investment in 5 months, so it’s still very much worth it. As a bonus you get happy developers, which means productive developers.

So, do the math, and get the best tools out there for your developers, no matter if they are free or not!