Activation Toolkit Feedback

[johnny_icon]

Dear NI,

This post includes some positive and negative feedback. I'll try to make it a positive, negative, positive  sandwich in order to be constructive rather than critical. As a topic that's near and dear to my heart, I hope It's taken in the right spirit. Sorry for the long post.

We were encouraged to learn that your development for third part licensing and activation has matured over the past year and a half since I learned of it, and that you are planning on shipping it in 2010. This saves myself and another developer a lot of work.

Now on to the negative feedback

We've been an Alliance partner for several years, and I've been LabVIEW developer for about 18. We've met and discussed with key people at NI that we were planning on releasing a similar product. In fact, We've had about a dozen inquiries from NI employees, and another dozen or so from end users who would like the solution, and even a few more in just the last month. Not staggering numbers, but interest nonetheless.

Our solution isn't shipping yet. As an Alliance Partner, our bread and butter is doing systems integration, so our toolkit has been a long and delayed project. We've recently rewritten the client side as pure LabVIEW, implemented as Native LabVIEW Classes. We, in 2008, in fact asked NI to evaluate what we  had already developed. After some consideration of that, NI declined to sign our NDA, and declined to purchase any of our Intellectual Property. Shortly thereafter informing us that "we're developing a similar solution, but not for executables, just add-on toolkits", and also mentioning that they may be interested in inviting us to consult on their solution, or least be involved in recommending requirements. In other words an informal collaborative effort. We in fact would prefer that NI had this solution long ago, and only embarked on developing it to fulfill our own needs.

Here's an articulated list of our issues:

1) We were never invited to participate in any requirements, consultation, or evaluation of this product. In fact, we only found out about this private group through another Alliance Partner colleague. NI never invited us until we requested invitation.

2) NI informed us that they were not solving the executable licensing, just add-on toolkits. We continued our development efforts based on this information. Apparently, executables are now part of this licensing feature.

3) Several key people at NI were aware the Giawerx was developing a similar product. We would have gladly halted our efforts in the interest of a common solution shipped by NI, and now we've wasted effort. Simple communication could have prevented that. Also, we'd never been aware tha NI was developing such a solution until after we requested NI to sign our NDA, and disclosed simple workflow documentation. I wouldn't be so bold as to claim any infringement here, since our product isn't yet shipping and activation is a common, and generally un-patentable notion. Nonetheless, NI's product name and concept seem quite similar to what we disclosed, an are continuing to develop.

4) The solution is not a pure LabVIEW solution. There are 3rd party DLLs involved from Protection Plus I'm not sure how much NI researched this issue, but this is precisely why we began to develop our own solution. Non Native LabVIEW code is simply not an acceptable solution. How would one deploy to cRIO, Linux, Mac or other platforms seamlessly? More importantly, how would one deploy to Windows Mobile? This is one of our spin-off companys primary objectives; deploying LabVIEW executables on Windows Mobile targets.

5) Surely NI is aware of the massive success of the iPhone app market. It could be equally lucrative on the Windows Mobile Platform. Yes the revenues per license are small, and the profits are likely thin unless an app gets traction, but once it does, there is money to be made. Once brand recognition is developed and a suite of apps are available, that's a viable business model. It's almost as if NI completely missed that point. A special DLL will need to be developed for Windows Mobile, and then a stub DLL will need to be developed, and so on. There are several threads in the forum about this, and truth be told, many LabVIEW developers simply don't have the skill required to develop a stub DLL that is required to develop Mobile apps on the desktop.

Also, there has never been a good installer for Mobile executables in LabVIEW, and we've had to resort to creating our own using NSIS, but that is another matter. In short, NI's 3rd party licensing and activation toolkit still will not allow one to develop and License Windows Mobile applications, which means we must continue the daunting task of developing our own solution. This is undesirable for us, and probably for NI and the end user developer. Again simple communication and collaboration could have sorted out these types of requirements early in the development process.

6) In preparation for this product, we have developed, released, and obtained the "Compatible with LabVIEW certification" of our Mobile Registry VI Library. Registry functions aren't implemented on the LabVIEW Mobile platform, so we solved the problem ourselves as a companion product to our Product Activation Toolkit.

7) How is it that internal NI employees are contacting Giawerx (not frequently, but occasionally) about our solution and know nothing about NI's current effort? This seems like another mistake in not communicating and informing internal (and external) stakeholders about current but unreleased development efforts.

😎 While protection Plus may be an adequate solution, this toolkit could have been architected in such a way as to accommodate various activation providers in the future (Nalpeiron, Logic Protect, Homegrown PHP/.NET/Java, or others). If Protection Plus goes out of business, this model is now broken. The homegrown PHP, .NET or Java reference implementation would give the developer a starting place to develop and modify their own implementation, and solve the issue of being dependent on a sole source. In other words, A developer could choose to self host the activation service given a good server side reference implementation.

9) NI continues to view the Mobile and PDA market as an afterthought as opposed to an emerging market, mostly due to small revenues on the Mobile toolkit. As an NI Certified Professional Instructor, I've even offered to author and teach the course. NI's response was "not interested, not enough revenue". Meanwhile the smartphone, PDA, and iPhone markets are churning out revenue. NI, when will you embrace the Mobile market as tangible and meaningful? I've always claimed LabVIEW as my language of choice, not just for Test and Instrumentation, but as a viable and worthy programming environment for any application. If one platform cries out for an activation solution, it's the Mobile platform, in any language.

Let me try to end positive here:

1) NI, we never wanted to develop this solution to begin with, we felt we had to since there was no good pure LabVIEW solution. We're happy to have you fill that market need so we can focus on application and toolkit development.

2) Would it be possible to be more included in voicing requirements to NI prior to future development efforts? We really don't want any DLLs or other non-native LabVIEW dependencies in this solution. We are also interested in choosing various (including homegrown) activation providers.

3) At this point, we would gladly turn over any source code we have developed, as well as some of the forensic and data hiding knowledge we have obtained regarding piracy anti-piracy techniques, so long as we are able to influence the outcome of the solution.

I hope this post is taken in the right spirit. I know people often rant and become abusive online. We're merely trying to express some honest and frustrating feedback regarding a solution we've been struggling with for some time, and again is near and dear to our hearts. We don't care who solves it, We just want to see it solved, and we want the solution to be pure and high quality.

Regards,

John Giannangeli

President and Principal Engineer

http://giawerx.com

[Jeff M]

Hi John,

Thanks for your very detailed feedback.  I appreciate your honesty and it's this type of feedback that is extremely critical to improving how NI works with partners. 

Let me address your points:

1.  Requirements, Evaluation of the product, and beta invitation process.  For requirements gathering, we interviewed over 25 partners in April of last year (of which Giawerx was one partner) and from feedback received, we established that there was indeed a need for a 3rd party licensing/activation feature.  Of the partners that had a need, we tried to collect further feedback on requirements through Q&A sessions and a survey. As for the product evaluation and beta, our channels of communication for trying out this feature were the following:  (a) I had a write-up in Jack Barber's Alliance Newsletter back in January about the upcoming feature so Alliance Members would hear about it, (b) since it is part of our LabVIEW 2010 public beta, when a user signs up for the beta, we have a discussion board where all features are there for people to see and instructions on how to get involved – such as finding this specialized group (c) I also had session at the CLA summit hosted at NI in February, which was an event coordinated by Kristi Hobbs and Nancy H. I thought that would get us good coverage on getting the word out, but it looks like it wasn’t sufficient so I take the blame for not extending you a personal invitation.  Our future communications about the LabVIEW Partner Program will be handled through the Add-on Dev Center (www.ni.com/addondevcenter) so please join that group if you haven’t already. 

2.  (Regarding the intent of the feature)  This was a miscommunication somehow.  You are correct in that Add-on Toolkits and specifically "edit-time" licensing of VIs was the primary intent of this feature, and was where most the engineering time was spent.  But as you know, executable licensing can already be done today without any help from NI, using off-the-shelf technologies.  It typically involves wrapping a DLL and building it into you EXE.  Or many folks have home grown solution.   The new LV 2010 feature has a G API to enable executable licensing for those who want to use the Software Key technology. It’s also necessary because for those who license both Add-ons and Executables, it makes sense to have a single vendor.  However, companies have the liberty to choose whatever technology or licensing vendor they want for their licensing/activation. 

3.  Based on partner feedback that this was a critical need, NI decided to develop this as a feature a year ago.  I communicated in summer 2009 that we would develop this feature as part of LabVIEW 2010.  During NIWeek we reached out to a number of partners who had in-house technologies to get their opinions on this, see if there was something out there already that would meet the needs, and try to come up with a good general solution for the LabVIEW community as whole.  I believe we had someone in NI R&D ping you during this time period, which may be what you are referring to with the NDA and sharing your diagrams.  We had some very good discussions and in the end determined that of the existing home-grown solutions we were aware of from various partners, there wasn't one out there that would meet our needs – at least at that point in time.

4.  You are correct in that the solution is not a pure LabVIEW solution.  We chose to go with an industry proven technology and work with a company (Concept Software) who specializes in this field.  One drawback of this approach that you correctly pointed out, is that at this time they don’t offer support for non-Windows platforms.  We do think the other platforms are important and are exploring for the LabVIEW 2011 timeframe how to achieve this.  If you have input or ideas, let's talk about those.

5.  Very good points on the Windows Mobile platform.  I agree there are gaps and I'd like to talk further about this.  I'd also point out that these "gaps" are precisely the area where our partners can add value with add-ons.  As you correctly pointed out, requirements are often times missed or not well understood early in the design stages, and when a product goes to market there are things that can be improved upon. 

6.  Your Mobile Registry VI Library is a great example of an add-on that fills a gap in the LabVIEW platform. We also have new Silver and Gold levels as part of Compatible with LabVIEW, which I think your product would be a great candidate for.

7.  You mentioned poor internal communication at NI.  I plead guilty on this one.  We do have internal communication emails, wikis, etc. set up but even then, we are a big enough company that not every employee knows what's going on with LabVIEW features.  The recommendation I tell people outside NI, is that when you interact with various people at NI, CC your contacts on your interactions so you help close the loop with everyone.  Also, I recommend that all our partners set up a corporate visit to NI (separate from NIWeek) to have in-depth discussions with their contacts, align on business goals, meet face-to-face with the R&D teams, and in general build awareness and try to foster more collaborative efforts.   I would love to host you on a visit to NI headquarters and try to strengthen the partnership with Giawerx.

8. The feature we developed has indeed been architected in such a way to accommodate flexibility down the road.  If a requirement in the future is to support another vendor, and if for some reason the Concept Software technology does not meet our needs, we will consider doing so.  For LabVIEW 2010, we made the business decision to choose the best vendor that met our needs and support that integration really well in hopes of having an out-of-the-box solution, and a really good end-user experience. (As opposed to supporting a number of integrations at a lesser quality.)  We also have a lot of faith in the Concept Software solution and the company as a whole -- their team is phenomenal and they have world-class support for their customers.  In addition, we are taking extra measures to ensure the long-term viability of this solution for our Alliance Members. 

9.  I agree the Mobile market has a lot of potential.  And while it's not the core desktop application use-case, or as hyped up as areas like RT and FPGA, I wouldn't say it's an "afterthought".  It's one area, along with a lot of other areas that LabVIEW can be used in.  And it does have fewer users so there are practical considerations on whether or not there is demand to have an official training course around it.  That said, I would not discourage you if you feel compelled to write a book or training manual on the subject.  You could highlight your expertise and put it on Amazon or another site.   

To address your closing comments:

We would love to have you more involved with the feature, and you can influence the outcome. And thanks for the generous offer of sharing your best practices, code, and ideas.  As I mentioned, we would like to support non-Windows platforms in LabVIEW 2011 so this is an immediate area to discuss.  

One consideration, however, is that while we love the idea of a G based solution, we also love the idea of a commercial vendor who specializes in this area offering value that is beyond what NI can do.  NI is not in the business of licensing/activation, and as you know there is more to it than encryption and all the technical details.  Moreover, it's a key business component of software distribution so what Concept Software can provide are things like CRM capabilities to manage customers, activation metrics, and much, much, more. These are things that small/medium software business find valuable for growing their business. 

Here’s who to talk to from NI in more depth (all of us our members of this group):  Sohum Misra is the Software Developer for the feature, Herbert Engels is the Tech Lead, Jervin Justin is the owner for this beta program and a Partner Program Engineer, and I'm the Compatible with LabVIEW Program Manager and own the relationship with Concept Software.

Thanks for taking the time and effort to voice your thoughts on this topic. 

Best Regards,

Jeff Meisel

[johnny_icon]

Hi Jeff, Thanks for your thorough response.Since my last post was lengthy, I'll be brief.

First I'd like to say that your help during the certification process of our Mobile Registry VI Library was invaluable. You were very courteous and accommodating during the entire process, and even posted our toolkit in the NI News letter. Thanks for all of your great support!

Next, I'd like to say that I'm more interested in the solution here than the blame. Assigning blame is not a productive exercise. I have to accept full responsibility for not only not having our product to market yet, but for disclosing any of our development efforts while not staying fully in the loop on NI's efforts. I'm trying to give feedback on NI as a corporate entity rather than any particular individual(s). The reality is that my staff is currently involved with large integration projects with 3 fortune 500 companies, 2 government agencies, and about half a dozen smaller efforts. We're buried in the day to day running of our business, and our toolkits suffer. It's not an excuse, but a reality.

Nonetheless, I hope my message is clear. As an Alliance partner, we simply want to more involved, and earlier in the process so that we aren't duplicating effort. I realize much of that lies on our shoulders as well. While the toolkit is an adequate solution on the (Windows) desktop, the most disappointing part of the release of this toolkit is not only will it likely trump our product due to NI's widespread brand name recognition, but it also won't serve our current need (on the mobile platform, and others).

Thanks again for your follow through. I'll take any appropriate remains of this discussion offline with you and those you mentioned when they are not directly germane to the the topic of this group.