[lsb-discuss] ISV perspective in response to April 13 conf call

[Craig.Scott at csiro.au]

Thanks to Jeff for forwarding me the link to the weekly minutes. Now I have a better idea who and what is discussed!

I thought I'd offer some views from an ISV's perspective. For context, we are a small group within a large government scientific research organisation. That said, our activities span directly or indirectly over custom one-off packages for specific clients, plugins for mainstream commercial packages and right through to large frameworks aimed ultimately at large user bases. We also cover both open and closed software business models and for our particular group at least, all our software is platform independent (mostly thanks to our use of Qt). So while we do much of our work on linux, we also need to support Windows and Mac.

In our case, we are interested in the LSB primarily to help make supporting linux as a platform more manageable. Unless you are big, it is very hard to maintain the infrastructure needed to build specific packages for each major linux distribution and version you want to support. It's just not feasible to say something like "we only support RHEL6 and SLED11" because some of your user base will use Ubuntu, some will use older versions of RHEL and SLED, and some will use other linux flavours. Some don't have the choice to change to your supported distribution/version for various reasons. We had to accept that we simply had to deal with a variety of distributions and versions. The LSB seemed to offer "one standard to rule them all" and it is for this reason that we became interested in it. We needed a common target to aim at. One half is how to bulid your software, and the LSB provides that through the defined interfaces, etc. The other half is the guarantee that linux distributions would provide specific packages, installation and desktop integration methods, etc. We had no easy way to put things in a user's desktop menu under linux until we looked at the LSB. Same for init scripts. More recently, we've started to find real value in the LSB Navigator for working out whether we can safely use specific function calls, data types, etc. (if only the results weren't limited to 20 entries!). The app checker is also a real boost for testing our final packages against the LSB version we are aiming for.

The value for us is not in certifying our applications for the LSB, but in building our packages so that they work on an LSB compliant system. There's not really much perceived value for us in putting in the extra expense and resources to go through with certification. Consider also that on other platforms, you don't need to do this. Building your app with the right settings and tools, plus being careful with what your package uses is enough. It seems odd that a platform like linux, which is seen to be more "free" than others, would have a certification step which involves a process which looks onerous (perception or reality) and which costs. If you have an app with monthly releases/updates, for example, it's simply not feasible to go down the certification path.

The April 13th minutes show that there were discussions about how to increase the visibility of the LSB. I would contend that if you want ISV's to take notice, printer driver vendors isn't going to do it for you. I suspect that they are seen more as a system-related function, not so much as applications like ISV's would be providing. It's definitely valuable having the printer driver vendors support LSB (many apps need to print!), but perhaps you might want to consider looking for some higher profile apps to make noise about LSB. For example, why don't the likes of Adobe make their acroread package LSB compliant? What about Google Earth? Intel C++ and Fortran compilers? These come from big companies who could make their apps LSB compliant if they wanted to, so why aren't they doing so? If they were to publicly come out and state that their products were LSB certified, then maybe more ISV's would take the LSB seriously. If those vendors see LSB compliance as infeasible or too hard, then why would the rest of us bother either? At the moment, the number of certified LSB apps is so low that one can only conclude that it is not worth it. If, however, well known vendors with some very widely used packages are talking about LSB, that may change the picture. This would always be more effective than LSB-associated people/groups talking about the LSB!

That isn't to say that some promotional activities by the LF wouldn't be effective - quite the opposite. If you want ISV's to notice and seriously consider the LSB, you need to be in places where they look. Why not get involved with the Qt folks at their various conferences and events? Robert's and Kay's points about picking an industry might also work here. Find the main conferences ISV's for that industry generally attend and get involved, not necessarily as a stand on your own (people might just walk on by), but maybe instead partner with some strategic groups and get the LSB "brand" associated with their products. This may require offering some assistance in getting some of their software compliant/certified as part of the promoting process.

On the technical front, it's probably also worth flagging that we see a growing problem emerging with Ubuntu and the LSB. While Ubuntu does certify to the LSB, the package dependencies don't actually work for LSB-compliant RPM's. You can install a LSB-compliant rpm, but you have to manage the dependencies yourself. Alternatively, you can convert the RPM to .deb using something like alien, but we've found that you can lose some of the important information from the package. So while we can create LSB-compliant RPM's, we still need to provide additional instructions for Ubuntu users to handle the dependency problem. Ubuntu is not going to go away and it is unlikely to change its packaging system, so the LSB will need to work out how it can address this situation or else it risks losing its main selling point of universal binary support for all major linux distributions.

Okay, that's probably enough for one email. ;)  Hope it's useful.

-- 
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia