The flaw in LabVIEW Tools Network: VI Package Manager

[MichaelAivaliotis · Accepted solution]

As one of the lead developers of VIPM, I can clarify a few things.

Some facts:

• By building packages with VIPM 2010 community edition, you are not "forced" to give your tool away for free. You can most certainly charge money for it and hopefully make some.
• VIPM 2010 Community edition supports the third-party licensing/activation feature in LabVIEW. So, yes, you can sell licensed packages with the community edition. Library license binding is performed using NI's free licensing wizard. VIPM community just performs the packaging.
• VIPM 2010 Professional edition adds certain additional features to licensing/activation which make your life easier. The term "integrates fully", should be expanded to state: VIPM Professional performs dynamic license binding to your library at build time. This allows you to keep your original source unlocked after the build. This also removes the need to use NI's licensing wizard. So the whole process is more streamlined.

So our marketing message needs to be cleared up a bit. VIPM 2010 Community edition can package licensed libraries. VIPM 2010 Professional takes your raw source and performs the licensing and library binding at build time.

More info is in our docs.

[josborne]

Thanks, everyone.

It appears I was confused.  I'll now eat my words:  munch munch. 

Though, perhaps my confusion was understandable, as Michael points out above.  The text around licensing and the different VIPM versions is a bit confusing.

Btw: I never meant to put down VIPM.  Its a great tool (kudos, JKI!).  My frustration was really focused on the cost... which was incorrect.

[rex1030]

I'm very excited to hear that I can create packages for free now! Amazing and thank you. There are still many valuable reasons to purchase a professional copy so I will continue to push for it.

I am looking forward to the development of the LabView Tools network. Its definately not object oriented programming if you have to reinvent the wheel every time. I am looking forward to contributing.

[Jervin Justin]

Hi Rex,

Glad to hear your excited about contributing add-ons to the LabVIEW Tools Network, we're excited as well to foster this ecosystem, and we've seen a lot of initial success.

Here's a link with more information for when you are ready to submit an add-on to the LabVIEW Tools Network:

http://sine.ni.com/np/app/culdesac/p/ap/lvtn/lang/en/pg/1/sn/n21:28/docid/tut-11642

[rolfk]

---

@josborne wrote:

Technically, you are right.  VIPM is not 100% required for distributing via the Tools Network.  That is why I wrote that VIPM is "(essentially)" required. 

A developer could always package their code into an MSI installer or something and still distribute via the Tools Network.  But if you want to use VIPM to build a package for re-sale, you need to pay $999 (see here for comparison of VIPM versions). 

By "essentially", I mean that it puts a developer at a serious disadvantage if they don't use VIPM to package their code (IMHO).  And you'd think that NI would want to open the doors a bit to developers. 

I guess that fact that developers don't really need to use VIPM diminished my point.  But NI is really pushing the use of VIPM for add-ons.  This page is a good example:

http://sine.ni.com/np/app/culdesac/p/ap/lvtn/lang/en/pg/1/sn/n21:28/docid/tut-11903

They add a little disclaimer at the bottom, of course:

• Note that some Add-ons on the LabVIEW Tools Network do not use VI Package Manager, for example, those requiring a full EXE installer. (Download and install those Add-Ons manually.)

I guess I am complaining because I want to build my own add-on and sell it on the Tools Network, and I'm annoyed that I really should pay $999 if I want to do it properly and get the most sales.

And I am still curious why NI is using VIPM at all.  I wouldn't be surprised if they built their own VIPM capabilities into LabVIEW at some point soon.  So I hope JKI has a good contract and copyright on their material!

---

Actually you are wrong here. The JKI package manager is based in parts on the OpenG package manager and that software can in large parts create the same kind of packages. Is it as convenient and feature ladden as the JKI Package Manager? No of course not! I would estimate that JKI has put anything from around 1 man year to possible several, into making their package manager what it is now. And that does not even account for the fact that large parts of the OpenG package manager were in fact contributed by the same nice folks that have worked later on the JKI package manager.

Should NI create their own? Well they have a track record of canabalizing Alliance Member products by either buying them or simply creating their own version of it, but that does not mean that they should do so with everything. I can't see how you would come up to this conclusion other than from frustration.

I would guess that if there are a few people who would be willing to spend some time on the OpenG package manager they could come up with something that would also work albeit maybe not as comfortable as the JKI one. But and this is a real big BUT, someone would have to drag his ass from the comfortable lazy chair and do something about it. Just demanding that the world is free and all happy doesn't work.