Should LabVIEW be open source? Give your opinion in on-line poll


A balanced scale between open community and closed secure environment. Created with DALL-E3 Edited with GIMP
A balanced scale between open community and closed secure environment. Created with DALL-E3 Edited with GIMP

The LabVIEW Open – Close Conflict Cloud



The recent acquisition of National Instruments (NI) by Emerson has sent ripples through the industry, particularly regarding the future of LabVIEW. LabVIEW, the flagship product of NI, has been a lighthouse in test and measurement applications for decades. Its unique graphical programming interface and wide range of applications have garnered a dedicated and passionate user base and significant market presence. However, the acquisition raises crucial questions about its future direction. Only recently NI/Emerson officially declared something about the topic ( ), although the message remains very open and a clear direction is not immediately defined.

Central to the discourse is a pivotal dilemma: Should Emerson transition LabVIEW to an open-source model? This question is not just about software architecture; it is about the core of business strategy, the community engagement, and the capability to innovate. Emerson now holds the reins to decide the path forward for this influential software. The open-source model, celebrated for fostering innovation and community collaboration, stands in stark contrast to the proprietary model, which has traditionally been the choice for controlled development and commercial stability.

As we explore this complex scenario, it’s essential to consider various facets: the implications for LabVIEW’s long-standing user community, the potential impact on Emerson’s business strategy, and the broader repercussions in the test and measurement industry. The decision to open-source LabVIEW could be a game-changer, offering a fresh burst of innovation or it could challenge the established norms of software development and commercialization in this niche sector.

In this article, we will explore these dimensions, using the Goldratt Conflict Cloud model as a framework to dissect the pros and cons, assumptions, and potential resolutions of this pivotal decision.

Goldratt Conflict Cloud Analysis

Define the Conflict

Desire D (Keeping LabVIEW Proprietary): Emerson’s acquisition of NI, including LabVIEW, represents an opportunity to bolster its position in the automation and test measurement industry. Keeping LabVIEW proprietary aligns with a traditional business model, ensuring controlled development, exclusive rights to innovations, and revenue generation through licensing. This approach can leverage Emerson’s established market presence to potentially enhance LabVIEW’s capabilities, offering a competitive edge in the market where proprietary software have an edge in terms of integration and support. It should be noted though that both integration and support comes with significant costs as well.

– Desire D’ (Open-Sourcing LabVIEW): The idea of open-sourcing LabVIEW represents a transformative approach, tapping into the collective intelligence and innovation of a global community. This could accelerate development, diversify applications, and democratize access, potentially expanding LabVIEW’s user base. Open source models have been successful in various sectors, driving innovation and community engagement, which could rejuvenate LabVIEW and align it with contemporary software trends.

The core conflict diagram

Identify the Needs

Need behind Desire B: Emerson needs to protect its investment, maximize ROI, and maintain a competitive edge. Proprietary software allows for a controlled environment to develop unique features, provide robust support, and ensure software quality, crucial for maintaining customer trust and loyalty, especially in industrial settings.

– Need behind Desire C: The need here is to foster innovation, reduce R&D costs, and enhance community engagement, make the user base the broadest possible. Open sourcing could lead to broader adoption, increased versatility of applications, and potentially position LabVIEW as a more adaptable and future-proof tool in the rapidly evolving tech landscape.

The needs supported by D and D’ that are clearly in conflict

Understanding the common Goal

Finding a Common Goal (A): The unified vision could be maximizing LabVIEW’s potential as a versatile and robust tool in automation and test measurement, accommodating both rapid innovation and reliable industrial application, and generating the maximum throughput margin from this investment.   Let’s keep in mind this might involve a hybrid model, maintaining core proprietary aspects while open-sourcing certain elements to harness community innovation. But the idea of breaking the conflict cloud is not looking for a compromise between two OR but finding the false assumption and reaching the genius of the AND where both need A and B are satisfied and D and D’ have been merged in a non-conflicting set of actions.

The Whole Cloud

Assumptions Analysis

Assumptions behind link Need B – Desire D: The assumption is that maintaining proprietary control over LabVIEW will lead to better profits and market positioning. It presumes that exclusive rights to development will result in superior quality and functionality, critical in industrial applications. Another set of assumptions is probably behind the concept that a product must be able to generate revenue on his own to be sustainable.

Assumptions behind link Need C – Desire D’: This perspective assumes that open-sourcing LabVIEW will automatically lead to community-driven growth and innovation. It presumes that an open-source model is inherently more adaptable and future-proof, and that the community will actively participate in its development and expansion.

To break assumption is often useful to state them in absolute terms. This helps finding the area that have possible flawed logic behind and are ripe for breaking.

In the link B-D we could say

1.      Proprietary control always lead to better market positioning.

2.      Proprietary control always lead to superior quality and functionality.

3.      Any product of an ecosystem must be able to financially justify itself for ensuring maximum value of the ecosystem is reached.

Here we think the assumption that is more ripe for breaking is 3. Not that 1 or 2 aren’t challengeable but 3 is utterly false. In an ecosystem of products some may have 0 or even negative margin to maximize the overall value. Here the critical concept is that in systems the best solution is never the sums of local optima but the search of a global optimum.

In the link C-D’ we could say

1.      Community innovation is always better and more thriving that closed innovation.

2.      Open-Source is always more adaptable and future proof than closed proprietary model

3.      Community will rally up automatically behind the product and provide effort behind its expansion for free.

4.      The LabVIEW SW Ecosystem lead naturally to open innovation.

Lot of strong and not all necessarily true assumptions here as well. The ones that are more ready to be challenged could be 3 and 4. My point here is not that the LabVIEW community is not strong, on the contrary, but that for the product to change from “Closed” to “Open” model there are non-technical and technical aspects that need to be taken care of to make the shift viable. Git integration and software engineering must be reinforced. The Capability for the community to participate to a common, shared, roadmap must be created and maintained. The question “What is in it for me?” for any participant to the collective effort must have a reasonably clear answer.

Conflict Resolution

By critically analysing the assumptions and deciding which are the ones that can, or must, be broken a clear strategy should emerge, and a set of actions be defined. In this example the “B” side should recompute the revenue and reevaluate the revenue model, accounting for the ecosystem effects basically breaking 3. Any product of an ecosystem must be able to financially justify itself for ensuring maximum value of the ecosystem is reached. But the “C” side should come up with a clear answer for 3. Community will rally up automatically behind the product and provide effort behind its expansion for free. and 4. The LabVIEW SW Ecosystem lead naturally to open innovation.


The acquisition of National Instruments by Emerson, and the subsequent question of LabVIEW’s future, particularly whether to open-source it, presents a complex and multi-faceted dilemma. Our analysis, guided by the Goldratt Conflict Cloud, has revealed a range of perspectives, needs, and assumptions that shape this decision. On one hand, the traditional proprietary model offers controlled development and stability, and appear to be aligned with Emerson’s business strategies. On the other, the open-source model promises innovation, community engagement, and alignment with current software industry trends.

The historical significance of LabVIEW, combined with the vibrant community that has grown around it, underscores the importance of this decision. The industry’s shift towards open-source models adds another layer to this complexity, suggesting potential benefits but also raising questions about consistency and support in industrial applications.

Call to Action

As we stand at this crossroad, the future of LabVIEW is clearly a decision for Emerson but  constitute a topic of interest for the entire community of users, developers, and industry observers. Your insights and perspectives are invaluable in shaping this discourse.

I invite you to participate in a poll to express your opinion on the path LabVIEW should take:

1. Keep LabVIEW Proprietary: Maintain its current model, focusing on controlled, in-house development. –> Go for B and D disregarding the other half of the cloud

2. Immediate Transition to Open Source: Make LabVIEW open source right away, for community-driven development. –> Go for C and D’ disregarding the other half of the cloud

3. Hybrid Model: Keep some core elements proprietary while open-sourcing others. –> Look for a good compromise where the need to open some aspect of the LabVIEW ecosystem to get more user base traction is still counterbalanced by keeping close the core elements that constitue a competitive edge.

4. Roadmap to Open Source: Gradually transition LabVIEW to an open-source model, ensuring a smooth shift in development and support. –> Overcome the conflict acting actively on the assumptions that keep it existing. This means a lot of work in changing the current accounting model but also creating the necessary foundations for the open source model to thrive.

Link to the Linkedin Poll

Your participation will not only contribute to a better understanding of community preferences but also help in envisioning a future that aligns with the needs and aspirations of all stakeholders involved. Let’s collaboratively explore the potential paths for LabVIEW and shape a future that harnesses the best of innovation, community strength, and industrial robustness.

Closing Statement

Please note that the opinions and analyses presented in this article are solely my own and do not represent the views or intentions of Emerson, National Instruments (NI), or any affiliated entities. This article is written from the perspective of a member of the broader community, aiming to offer insights and stimulate discussion around the future of LabVIEW post-acquisition. The content herein is intended for informational and discussion purposes only, and should not be construed as advising or dictating any specific course of action to Emerson, NI, or any related parties. My aim is to contribute to the ongoing conversation in the community, sharing perspectives based on available information and personal analysis.

Appendix: Understanding the Goldratt Conflict Cloud Model

The Goldratt Conflict Cloud is a tool used in critical thinking and conflict resolution. It helps identify and address the underlying assumptions in conflicting desires or needs. The model requires defining two conflicting desires (D and D’), the needs behind each desire (A and B), and the common goal they aim to achieve. By examining the assumptions that link these elements, the model facilitates a deeper understanding of the conflict, leading to innovative solutions that respect both parties’ needs. This approach is particularly effective in complex decision-making scenarios where traditional compromise may not be viable.

For a more detailed explanation of the Goldratt Conflict Cloud model, please refer to this external resource.

Published by



3 replies on “Should LabVIEW be open source? Give your opinion in on-line poll”

One issue I see with the question at hand is that it is precisely some of the “core” aspects of LabVIEW that would most benefit from more eyes on the problem. Year-long issues which are notoriously difficult to track down and reproduce are simply not feasible to expect a central agent to be agile enough to catch and suggest a fix. Precisely here is where I think the quality of the code base would benefit.

That would be a heck of a pendulum-swing. But the pendulum has swung way too far in the opposite direction, so it’s worth talking about. Four-figure annual licensing via labyrinthine, Rube Goldbergian contraptions is as customer-hostile as you can get, and a great way to evaporate the pool of LabVIEW users, yet here we are. Sad.

Leave a Reply

Your email address will not be published. Required fields are marked *

The maximum upload file size: 256 MB. You can upload: image, audio, video, document, spreadsheet, interactive, text, other. Links to YouTube, Facebook, Twitter and other services inserted in the comment text will be automatically embedded. Drop files here