Someone pointed me at a TED talk from Simon Sinek that explains why it is so easy to forget to communicate the why when you try to evangelize a technology. Why have I been working hard these last 13 years, traveling a million miles, to develop and promote a technology like OSGi? Tirelessly explaining how OSGi works for sometimes skeptical mainstream developers?
The why lies buried in my youthful encounter with objects in the early eighties. Discovering objects was like an epiphany, suddenly a lot of the techniques I had found to work well were put in a framework and got names. The excitement of reading the 1981 Byte issue on Smalltalk was immense. Objects were exactly what I wanted for my software development! In that excited mode I convinced my manager that we should switch to objects as soon as possible because it would save us so much in the future. I painted a rosy picture in the sky about how software could be developed in the future of reusable classes. Developing an application would largely consist of picking the right classes, and voilá! I got the budget easily.
Objects did provide a significant benefit and 10-15 years after the Byte issue on Smalltalk they had therefore become mainstream. Though it is still easy to point out how out industry is struggling with complexity I do believe objects provided a significant value in allowing us to handle much more complex problems. However, the vision of assembling an application out of components never happened. What happened instead is that most large object oriented programs turn into a big ball of mud that is so entangled that it becomes impossible to find reusable components in the haystack.
Thirty years after the Byte issue on Smalltalk the world looks very different. Open source software has fundamentally changed the nature of software. Open source seems to have achieved the quest of reusable components because today these open source projects are reused on a grand scale.
However, when I struggle with integrating different software packages and their myriad of dependencies I am not so sure anymore. Badly documented, missing crucial metadata, extremely sensitive to their environment, complex configuration, incompatible versions, avalanches of logging, tons of XML, and mysterious crashes, then I know we're not there yet, it is still way too hard. There should be a better way! How can we better leverage open source projects so that these projects are easier to use together?
The model we envisioned in the eighties was plug an play, the way we can go to the department store and get drills, nuts, fasteners, and bolts from different vendors that work together because they use standards so they work together. This is the dream that kept me going for the past decade. OSGi is the only software standard that provides a substrate on which reusable components can flourish. Though OSGi has not reached the grail, it is arguably closer than anything else.
I am convinced that the next big step in software is the OSGi model: bundles collaborating through substitutable services. However, just like the mainstream procedural developers had to adjust their ways to take advantage of objects, today's mainstream developers have to adjust their software to take advantage of OSGi (and not run head first against the enforced module boundaries). Some developers reject OSGi because they deem it too complex but what is not too complex if you do not understand the why? Procedural developers also felt that objects were way too complex and wasteful. An investment in a technology is always required to get its benefits.
After thirty years the vision of reusable components has come tantalizing close with OSGi. However, to go that last mile we need your help to make OSGi the rock-solid foundation for the mainstream software developers.
P.S. As always, these are my personal opinions and are not necessarily aligned with the OSGi Alliance