Last week, I opened the 2nd Annual OSGi Survey. The survey concluded early Tuesday, with more than 250 developers taking the survey (last year, 64 took the survey). The survey was not scientific, and it was clear that the majority of folks taking the survey were already using OSGi. But the results were interesting nonetheless, and offers some insight to how OSGi is perceived and used. Here are the results!
The Questions and Answers
Let’s analyze the results, question by question. Then, we’ll offer up some analysis, with possibly more to come later. If you’re interested in last year’s results, I posted a summary of the results on my site with some detail on the APS Burton Group blog.
Question #1 - Are you familiar with the OSGi Service Platform?
92% (241) have heard of OSGi, as compared to 89.1% (57) last year.
Question #2 - Are you currently developing systems to be deployed to an OSGi runtime?
70.9% (185) were using OSGi as compared to 50% (32) last year.
Question #3 - Do you have plans to develop systems that are to be deployed to an OSGi runtime within the next 6 – 12 months?
82.7% (215) are planning to use it in the next 6 - 12 months as compared to 79.7% (51) last year.
Question #4 - Are you familiar with the available OSGi products and services?
83.5% (217) were familar with OSGi products and services as compared to 67.2% (43) last year.
Question #5 - Which OSGi implementations are you currently using or evaluating?
This was a freeform question, and in both categories (Using and Evaluating), Equinox was the clear leader, garnering more than 100 responses, with Felix coming in second. Other notables mentioned include dm Server, ProSyst mBedded Server, and Paremus Service Fabric.
Question #6 - Which of the following types of systems are you planning to deploy within an OSGi runtime?
Respondents were able to select more than one answer, resulting in a total that exceeds the number of folks taking the survey. So it’s obvious we are leveraging OSGi for different types of applications (click image for summary). In total 64.8% (162) (65.1% last year) said they were developing web apps, 17.2% (41) (11.1 % last year) were using it for embedded development, 15.6% (39) (12.7% last year) on mobile development, 50.4% (126) (39.7% last year) for rich clients, and 13.6% (34) (17.5% last year) said they weren’t using OSGi at all.
Question # 7 - What are the benefits you hope to achieve using OSGi?
Again, respondents were able to select more than one answer for this question (click image for summary). In total, 83.9% (214) (82.5% last year) wanted greater modularity, 56.6% (144) (63.5% last year) wanted hot deployment, 51.4% (131) (54% last year) wanted a more manageable runtime environment, 68.6% (175) (71.4% from last year) wanted better dependency management, 57.3% (146) (63.5% from last year) wanted bundle versioning, 63.5% (162) (65.1% last year) wanted a plugin architecture, while 10.2% (26) (14.3% from last year) abstained.
Question #8 - What are your greatest technical challenges in using OSGi?
The clear challenge in using OSGi (click image for summary), cited by 63.8% (157) (63.5% last year) of respondents, is how to use OSGi most effectively. Following a rather distant second place at 40.2% (99) (38.1% last year) was finding valid OSGi bundles. It tailed off pretty sharply after that with testing at 30.9% (76) (19% last year), debugging at 22.4% (55) (25.4% last year), and the remaining coming in each close to 11%. These were each down from last year.
Question #9 - If your application server provided an OSGi runtime container, would you consider deploying your software as modules/bundles?
87.5% (223) (88.7% last year) said they would deploy their software as modules if their platform supported it. 8.2% (21) (9.75% last year) said no they would not. 4.3% (11) (1.6% last year) said the weren’t sure what an OSGi bundle was. In total, 7 people skipped the question.
Question #10 - What obstacles must OSGi overcome to achieve widespread adoption within the enterprise?
Since this was a free form text entry field, I took the liberty of classifying the various responses. While not everyone chose to offer input, for those who did, the following obstacles were cited by the respondents as being most significant:
- 51 cited lack of tooling
- 28 cited a migration path from Java EE to OSGi, including a lack of platform support as an issue
- 23 cited a lack of good education material
- 10 cited lack of available bundles
There were myriad other responses, as well. Some stated that complexity was an obstacle, which Hal Hildebrand refers to as the “cognitive burden” of OSGi. Another respondent pointed out that the availability of an OSGi-based “killer application” that wasn’t an IDE would also increase the visibility of OSGi. Yet another respondent pointed out that OSGi is an over-engineered solution that actually causes more problems (due to its complexity) than it solves.
What might be most interesting is that there is little significant difference from last year’s results. The results hover around the same numbers as last year, with only Question #2 and Question #4 seeing the most significance differences. There were a few aspects of the survey that struck me as particularly interesting. Tooling, a migration path, and educational material surrounding how to use OSGi most effectively continues to be a significant issue for developers, even though roughly 15% more of this year’s respondents claimed familiarity with OSGi products and tools. In other words, they’re familiar with the technology, but still recognize the need for better tools, etc. Clearly this is supported given the responses to Question #8, where the greatest challenge in using OSGi is understanding how to use it most effectively.
Last year, 50% said they were using OSGi while close to 80% said they planned to use it in the next 6 - 12 months. The response to Question #2 indicates we saw a 20% growth in adoption…somewhat close to the 30% indicated.
Developers again indicated that they want their application platforms to expose OSGi for building web applications, with almost 90% saying they’d develop web applications today using OSGi if the platform allowed them too.
Finally, the majority of folks currently using or evaluating OSGi are doing so at the framework level, not the platform level. Given that most people are planning to develop web applications using OSGi, I really would have thought that platform use and evaluation (such as dm Server or Infiniflow) would have been higher. It’s possible the way I worded Question #5 influenced how respondents answered the question.
Platform support for OSGi is coming. Well, at the very least, platform support for modularity is coming. However, once the platform does support modularity, and a rich suite of tools is available, there is still the nasty little problem surrounding how we effectively design modular software. It appears we’re on the right track, but we still have a ways to go.