Opening LabVIEW source code

[LAVA 1.0 Content]

Hi,

This year LabVIEW celebrates its 20th birthday. A development environment that started from a virtual instrument development tool has grown into an outstanding general purpose visual programming language. Troughout LabVIEW history it has beeen debated if LabVIEW is a general purpose programming language or not. It defenitely is a general purpose programming language but maybe not as general as it could be. Every LabVIEW power user knows that even though LabVIEW has very many outstanding features, it also have very many shortcomings not present in the main stream programming languages and development environments.

Requirements for LabVIEW functionality keep raising as the number of LabVIEW users constantly grows. During the history of programming we have seen that it indeed is quite challenging to develop an excellent programming language. All the most popular languages are developed as a joint effort of the computer science community. This ensures that the design decissions made are in agreement with the state-of-the-art techniques of the present time and that all the possible shortcomings are considered when these design decissions are made.

LabVIEW as a proprietary programming language doesn't have the power of the computer science community. It may be extremely hard to recruit the best minds of the community to work exclusively for National Instruments already for purely geographical reasons. As a result NI presumably cannot keep up with the pace required to keep LabVIEW a high quality general purpose programming language. Until now NI has had central pantets protecting graphical design of LabVIEW. The most central ones of these patents have expired or are soon to expire leaving the field of graphical programming languages open for competition.

From this perspective it would be very wise move from National Instruments to open the source code for LabVIEW programming language and releasing the patents protecting the language for the use of the community helping to develop LabVIEW. National Instruments should see this more as an opportunity than a threat.

Opening the source for LabVIEW would gather new free-of-cost developers for developing LabVIEW. LabVIEW would improve and gain more reputation as a general purpose programming language. Students and computer scientists arount the world would get acquainted with LabVIEW as the barrier of expensive licenses wouldn't be there. LabVIEW has many features that are expected to be in a future general purpose programming language as natural support for multithreading. However it lacks many features that are required from a future general purpose programming language. As an open source language, LabVIEW could develop towards a generally accepted programming language of the next decade.

As the LabVIEW user community grows, also NI could take advantage of its expertise in LabVIEW integration. The growth of LabVIEW user community means that the number of pontential customers for National Instruments measurement and automation products grows and NI can take full business benfit from it. NI can still sell proprietary Measurement and Automation software and hardware for integrating the NI hardware with LabVIEW, managing measurement data and managing other measurement and automation related tasks. Only LabVIEW as a general purpose programming language would no longer be a source of income. Still NI could go on selling development environment for LabVIEW.

Open LabVIEW would also open new opportunities to NI. It could benefit from its expertise of software and hardware integration in the field of embedded computing. The embedded computing is growing fast as every device around us gains a microprocessor. If LabVIEW would be used as a general and most popular programming language for embedded computing, it would allow NI to sell number of new products and solutions to this embedded computing industry.

As an addition if LabVIEW source was opened, NI could still keep the source closed for LabVIEW data acquisition and automation modules. This way NI could go on selling LabVIEW for the majority of the present customer base who are measurement and automation professionals and to whom the open source LabVIEW didn't offer enough properties.

Of course there is also a risk that other measurement and automation industry companies can take advantage of open source LabVIEW. If however LabVIEW is released under both commercial and GPL license, NI can very well protect against competition in the field of measurement and automation. GPL license guarantees that if an other company in the industry integrates their software with LabVIEW, this other software immediately becomes GPL licensed software and open source as such. .

Open soruce LabVIEW is an opportunity for the LabVIEW community, for the computer science community in general and last but not least for National Instruments. LabVIEW community get improved general purpose programming language with all the state of the art techniques and functionality. Computer science community gets the opportunity to start developing programming techniques and paradigms for visual programming and this way solving the shortcomings of text-based programming languages bringing the programming for everyone. National Instruments would gain major advantages from LabVIEW becoming generally accepted programming language. The increasing user base would get NI a number of new potential customers and opportunity to start selling new kinds of products and solutions. On the other hand, if NI will not open LabVIEW source and tries to keep its monopoly, I predict that it may be hard to keep up with the recent developments in programming language technology. General purpose programming languages will evetually offer all the benefits of LabVIEW and much more. NI will lose it's position not only in LabVIEW but also as a provider of measurement and automation hardware.

I'd like to hear what you, the community, think of this issue.

-jimi-

[bsvingen]

I think this would be great. But what would happen is probably this: NI will still be making their compiler and sell it. They will probably only support exactly the features they want that suits their hardware. So there will be two versions of LV, the NI version, a commercial compiler specially targeted for NI hardware, and the open version. Then, who will be the users of the open version?

[Mike Ashe]

I think this would be great. But what would happen is probably this: NI will still be making their compiler and sell it. They will probably only support exactly the features they want that suits their hardware. So there will be two versions of LV, the NI version, a commercial compiler specially targeted for NI hardware, and the open version. Then, who will be the users of the open version?

This doesn't seem to be much different from the current situation with C/C++/C# in that you can get both free, open source compilers, tools and IDE's and you can also get several variations of commercial products.

The norm in any market eventually tends towards a dominate player that controls about 80% of the market and everyone else splitting up the remaining 20%. There are lots of exceptions to this, but in general it is a pretty good rule of thumb. I would love to see NI release the source code for the basic G language, along with documentation and to have them sponsor or take the lead in a community effort to create "ANSI/IEEE Std G", but I will be pleasantly surprised if they do so any time within the next few years. Whether they do, or whether Open Source G is developed completely independent of NI, I am sure they will be the dominant version of G for a long time to come.

Interesting questions to ask at NIWeek 2007 ...

[JDave]

Interesting and certainly provocative. I think that an your idea of open source LabVIEW would be very interesting for the CS community and many "Power Users" of LabVIEW.

Requirements for LabVIEW functionality keep raising as the number of LabVIEW users constantly grows. During the history of programming we have seen that it indeed is quite challenging to develop an excellent programming language.

It is also quite difficult to have excellent customer support for a language. Who do you call for project support when developing an application in C++ or C#? One of the things that impresses me about NI is they have wonderful customer support. You can't support something you don't have control over.

Also I don't agree with the following

On the other hand, if NI will not open LabVIEW source and tries to keep its monopoly, I predict that it may be hard to keep up with the recent developments in programming language technology. General purpose programming languages will evetually offer all the benefits of LabVIEW and much more. NI will lose it's position not only in LabVIEW but also as a provider of measurement and automation hardware.

nor do I see how it matches up with this

The thing is that no single development environment or programming language never can cover all the programming problems. The general purpose programming languages like C, C++ and Java are quite close to how wide an audience a single programming language can reach.

Still I am sure that an open source G will be developed and it will be an important process.

David

[LAVA 1.0 Content]

I think all of you who follow this topic may find this essay The Care and Feeding of FOSS interesting.

/Lars-G

[crelf]

[quote name='Lars-G

[bsvingen]

[quote name='Lars-G

[LAVA 1.0 Content]

The document says: "Software costs virtually nothing to manufacture" - I beg to differ! The money is spent in different ways to traditional part production, but it's still spent. Otherwise companies like Microsoft and Google would have virtually no costs - and that's just not true.

Well, if you use this definition of manufacture: "The act of making something (a product) from raw

[LAVA 1.0 Content]

I just read it. Very interesting indeed. With regard to LabVIEW it seems to me that the language, G, can be open source but that this will be much more problematic for the drivers.

The article was interesting. There are very many good points raised up. The writes made also some mistakes as Crelf already mentioned. The writer is wrong when he says "software costs virtually nothing". The correct form is that additional costs of extra copy of software are virtually nothing, not the cost of the software itself. As a result the software costs virtually nothing when demand is large enough and technology is mature so there is no need for consuming 5-10% to R&D. However I don't see that this in any way affects the conclusions drawn.

Virtually all programming languages are now in this mature FOSS stage except G. This is because LabVIEW hasn't really been a programming language but rather a measurement and automation environment and has therefore followed the market evolution of this field. There is hardware involved in this field so it's not as simple a market as a pure software market. However also electronics industry is experiensing the same kind of evolution as software industry. It becomes easier and easier to manufacture commodity hardware. Hardware gets closer to software as hardware parts used in electronics get more general purpose programmable integrated circuits. Less and less users need the state of the art hardware but can do what ever they need to do with cheap bulk hardware. Bulk hardware can be controlled with FOSS software so the market evetually leads towards combination of general purpose bulk hardware and FOSS software. The mariginal cost to manufacture an additional general purpose hardware is not nothing but however very close to nothing.

In 100 years we'll see another interesting development - FOSS goods. As the manufacture process of everything develops, we'll eventually have factories that can produce anything common hard stuff from a recipe for very small cost. These recipes start behaving in much the same way as software. Evetually you can download a new recipe for your new computer from the net and you don't need Dell or HP to produce you outstanding computer recipes.

[crelf]

[quote name='Lars-G

[LAVA 1.0 Content]

Well sure - you can make anything mean anything else if you redefine the terms It's not true - "The act of making something (a product) from raw materials" still requires all those things that you mentioned and that's the fatal flaw of the document. One of the biggest natural resources used in software development is time. In a manufacturing environment, it's 100% true that time is money. I agree that the cost of duplication is low for software, but it still costs to get to the duplication phase, and essentially that's not the arguement that the document is making - it says "Software costs virtually nothing to manufacture" - so I challenge your definition of the word "manufacture"

eh, maybe I'm just getting bogged down in semantics - I'm in that sort of mood today...

Suppose I shouldn't swallow the bait, as English really isn't my language.

But, here goes; If you read the paragraph Free Open-Source Automobiles?, I think you'll see that the author only is emphasizing the difference between traditional and software businesses.

If this difference didn't exist, we wouldn't even have this discussion of Open Source LabVIEW code.

[crelf]

[quote name='Lars-G

[bsvingen]

Lets consider the article is correct, then there exist no insentive for NI to open the code. They have monopoly of this small niche of graphical programming (at least they have no competitive products to care about), and as a commercial entity they are right where they want to be, and can fully exploit the commercial synergy between LabVIEW (G) and their acquisition hardware. If I was NI I don't think i would even consider making LabVIEW a more general language, because then there would be competition, and the competition would probably initially come in areas outside the core business of DAQ.

I mean, just think about it for a second or two; if LabVIEW had a native by ref GOOP with a decent efficiency, it would become just as general purpose as for instance Java, visual basic or C#. LVOOP doesn't really make it more general purpose, but instead it enhances the dataflow paradigm by making data-objects.

I think, if we want a general purpose graphical language, we have to make it ourselves from scratch.

[crelf]

Lets consider the article is correct, then there exist no insentive for NI to open the code.

Has anyone mentioned this post yet?

[Mike Ashe]

The FOSS article was interesting to read (again) and see the various takes posters have expressed in this thread.

Right now I am doing some ATE work for a large defense contractor. Funny, but I don't think FOOS will catch on here any time soon. The reason is the legal department. They don't want engineers to use FOSS or OpenG or anything not "shrink-wrapped" with a commercial license, due to possible exposure to litigation.

The reasoning goes that if they start using a lot of open source stuff they might be sued by someone (party B) who claims that that B's code was wrongly included in the open source code and ... yadda, yadda ...

Since a lot of big litigation goes after whoever has the deepest pockets, regardless of actual fault, the big companies can be gun shy about using FOSS.

I haven't given up on trying to convince my current client to open up to open source, but it is proving to be an extreemly uphill battle.

Again, a reread ... what I found most applicable this time was this line near the end:

"And in the commercial corner is software that can never be FOSS. It might be encumbered by patents, or more likely, is sold as an adjunct to some piece of hardware, such as "embedded" software found in modern cars, printers, scanners, wrist watches, cell phones, and so forth."

Hmm, sounds amazingly like LabVIEW; protected by patents, attached to HW, etc, etc. Except that now that the patents are running out there is a chance to start into stages 5 & 6 of the FOSS cycle.

[LAVA 1.0 Content]

I'm coming a bit late in this discussion...

Yesterday at MWSF keynote, Steve Jobs cited Alan Kay :

"People who are really serious about software should make their own hardware"

I do believe NI is sticking to this catch phrase with success and hope they'll keep on this way. Those who are trying to use DAQ board on Linux based systems can tell you the time they are wasting to find drivers...

I love OpenSource, I love OpenG and dor some things I'm quite happy to pay for a "blackbox" IF IT'S WORKING.

[crelf]

Yesterday at MWSF keynote, Steve Jobs cited Alan Kay :

"People who are really serious about software should make their own hardware"

I'd like to see the context of that quote. As a throw-away line on it's own, it's only purpose is either marketing drivel or... well... I can't think of anything else.

[LAVA 1.0 Content]

I'd like to see the context of that quote. As a throw-away line on it's own, it's only purpose is either marketing drivel or... well... I can't think of anything else.

Well... announcing the iPhone, Apple's CEO explained that he came to the conclusion that installing the same OS on different phones -with different capacities- would lead to a package "phone+OS" far from optimal.

IMO, this sticks to the idea of the "numerical hub" but this is too far from the initial subject of this thread

[crelf]

Well... announcing the iPhone, Apple's CEO explained that he came to the conclusion that installing the same OS on different phones -with different capacities- would lead to a package "phone+OS" far from optimal.

Ah - I see. So marketing drivel confirmed It's almost aligning with the old MacOS Vs Windows paradigm: MacOS only needed to work on the hardware platform that Apple created, where as Windows had a slightly more difficult task. I'm not surprised that Apple is pushing even further into the consumer electronics market - that's where the quick bucks are!

[LAVA 1.0 Content]

Ah - I see. So marketing drivel confirmed Is aligning with the old MacOS Vs Windows paradigm: MacOS only needed to work on the hardware platform that Apple created, where as Windows had a slightly more difficult task.

Well, in a way it's becoming more than marketing... just have a look at the number of different version of windows...

• in the past, just one,
  
• then a "basic" one and NT,
  
• the "mormal", "pro" and server
  
• then came Media Center Edition
  
• And how many versions for Vista ? 7 ?
  

It tends to demonstrate, that the soft has to be appropriated to the hardware... Of course there is still a step to get to the above cited catch phrase

I'm not surprised that Apple is pushing even further into the consumer electronics market - that's where the quick bucks are!

this is funny, following the same idea Steve Jobs also cited a famous hockey player : " I skate to where the puck is going to be, not to where it's been." Funny M$ with their Zune...

[Ton Plomp]

Well, in a way it's becoming more than marketing... just have a look at the number of different version of windows...

• in the past, just one,
  

That was way back, if I recal correctly even Windows 3.1 had a corporate edition:

Windows for Workgroups.

Ton

[Grampa_of_Oliva_n_Eden]

Hi all,

I have not read the whole thread but I'd like to ask a hypthetical (sp?) question.

If I gave your three "magic beans" that when eaten would give you a password to any of the password protected VI's that ships with LV...

Which three VI's would you use the "beans" on?

Ben

PS I am asking this question to learn more about what I have been missing.

[Aristos Queue]

Which three VI's would you use the "beans" on?

Ben: please repost your question as a new discussion topic. I think it is worthy of being a top-level post, and it is certainly off topic for this thread. But it's a good question.

[Val Brown]

Ben: please repost your question as a new discussion topic. I think it is worthy of being a top-level post, and it is certainly off topic for this thread. But it's a good question.

Did the "beans" get moved to a new top-level?

[LAVA 1.0 Content]

Did the "beans" get moved to a new top-level?

http://forums.lavag.org/What-have-I-bean-m...k-at-t5722.html