To my, and the others, defense, I also think the learning curve is partly so steep because some of the concepts:
* …
- Bad documentation (and no experts willing to to something about it unless paid lots of money).
I don’t know why I’m still trying to convince people to do something about the documentation. Maybe because after years of struggle I found out how useful OSGI concepts are and I still would like to see OSGi succeed in some way, though I know I won’t. (And I still feel that I know too little to write something beyond some “tutorial” myself, I keep being surprised about new information in discussions too often.)
OSGi dates back to 1999 (at least) and sometimes I have the impression that so do its protagonists. Look at all the nice and shiny things that you get today with all the documentation for free (because they have understood that this is the key to success).
I just come from learning kubernetes. It took me barely three month to write my first operator (and only maybe half of that time was spent with kubernetes, the other half was about concepts of the domain that it is operating). And you know what? No consultancy required. It’s all in the docs. Of course, sometimes goolgle led me to some blog or to stackoverflow. But in all cases I could find the information in the original documentation as well (and the blogs didn’t really add anything to it, they are mostly self-marketing).
Now compare this experience with this great official documentation of the bndtools resolution view. Makes you immediately want to work with this tool, right? And there’s not even somebody “blogging” about it, try this. (Not to speak of the many bnd tricks that have never been properly documented.) And please don’t tell me that everything is in the specifications. First, this does not apply to tooling and second, we all know that these specifications are not written with somebody wanting to learn about a technology in mind. The average internet RFC in its “informal parts” provides more information about the background of and the motivation for what it specifies than most of the OSGi specs do. An example of how to do documentation and specification together is Java. Did you ever need more than the JavaDoc to use its standard library? Okay, sometimes the tutorials are helpful to get the general idea of some concept. (Yes, I did need the tutorial to grasp generics.)
I understand that OSGi is a “company thing” and not a “community thing” and that every expert involved wants to make money with his knowledge. However, considering this and complaining about OSGi not being the success that it should have been is nothing but shedding crocodile tears.