A substantial rift exists between user and developer of mass spec software.

There is no doubt about mass spectrometry (MS) being a powerful life-science tool that enhances the understanding of molecular structure. Challenges with data analysis remain, however.

A study was conducted to understand the limitations of the software that involved interviewing 100 MS professionals, both academia and industry, across the United States (Smith 2018). The polar opposite results were divided sharply between user and developer, but respondents’ suggestions could improve state of the art.

Options and Quality

Mass spec data processing platforms are continuously being introduced. Forget about trying them all, or even a handful; many scientists barely know what is available. Even if they got their hands on a few of such packages, often a challenging installation and an unfriendly user interface constitute a significant impediment against a fair and broad evaluation. Some scientists went beyond what was locally available but were often limited by software’s poor performance, difficulty in operation, and lack of the functionalities they had grown using. It should not be a surprise that not all “popular” tools have been effectively evaluated, and some attain attention just by branding.

“a big-name researcher helped develop it, a big-name vendor supports it, and a spin-up company handles it.”  -One interviewee of the study

The two most common complaints made were lack of user-friendly software and technical support. No user would want to spend significant time learning new software to be disappointed in the end, especially when customer responsiveness isn’t reliable. It is critical to evaluate the current methods and integrate the existing algorithms. It would control the circulation of every booming software and namesake adoption, thus working in favor of practitioners to be updated with state of the art.

Free Isn’t Really Free

Free software is like adopting a free puppy – it isn’t free once it’s home. You might not spend money on these tools, but it substantially costs you your time and energy. Users have an overabundance of potential solutions, but not one quick fix to satisfy every need. Extensive time costs related to ergonomics of such interfaces would also waste time manually tuning the software to their specific requirements.

For the software to develop, charges might incur to purchase updates or unlock capabilities. This implies the software has been tested, validated, and does what it says it can do. Otherwise, with limited capacities, it may miss identifications and produce incorrect data. It stands to reason that good software requires a significant amount of effort to develop, and that effort has a price. Similarly, bridging gaps between a user’s demand and implementing the software's critical feature has a cost. If not, there might be a need mismatch and proliferation of platforms executing the developer’s perception of what is needed.

Users Versus Developers

Given some of the barriers mentioned above and the lack of communication or shared experience between user and developer, a chasm has grown between the users who report multiple problems and developers who are uninformed of the unaddressed issues. Simultaneously, developers may be writing brilliant code and elegantly solving computational challenges- but if these are not the solutions the user needs or don’t know they need them, dissatisfaction will continue.

According to the study, the scientists were unaware of tools that provided the functionality they sought, and also, the vendors just promoted popular solutions to save on high developmental costs. The discrepancy between the majority of users believing there are major unaddressed problems in mass spectrometry data processing, while a supermajority of developers feel that the unaddressed issues were minor.

To Share or Not to Share

There is often a guarded culture around code, especially in industry, around internally developed applications, especially when it is believed that secrecy is needed to maintain a competitive advantage. Here the assumption (probably buffered by hubris) is that there is more to be lost than gained by sharing. This limits more generalizable development of more universal platforms built off of the input of the whole community.

It takes time to develop trusted relationships between the developer (even for internal developers!) and users that limit the ability of developers to keep up with demand. The guard tends to be lower in academia. As a result, commercial operations are more likely to come up with a potpourri of one-off, ad hoc in-house solutions to particular and small-scale problems. These solutions are limited to further development and a user interface that a few highly trained individuals can only navigate. Given the success that open-sourcing has had in other arenas, sharing code freely between academia and industries has promised to promote the quality and utility of mass spectroscopy software significantly.

Conclusion

Barriers exist between developers and users. Better communication and shared experiences between user and developer are essential to improve the mass spec data processing. At the same time, it is worth challenging the culture/business of shielding proprietary internal closed-source fixes from the broader scientific community. While no software platform is likely to solve all the unique challenges faced by all users, no one developer team would likely provide permanent fixes for their users.

Reference

Smith R. (2018). Conversations with 100 Scientists in the Field Reveal a Bifurcated Perception of the State of Mass Spectrometry Software. Journal of Proteome Research, 17 (4), 1335-1339