There is no reason why the NetVST technology, or something very similar, should not be deployed commercially. This page presents some ideas about how to do just that.

In the following, the term “NetVST company” is used in a generic sense, to mean “any profit-oriented company offering NetVST itself, or broadly equivalent technology”.

Companies can often achieve things that grassroots efforts cannot. There are two main reasons:

1. A profit-seeking company can afford to pay professional developers.
2. A profitable company has a better chance of success in the VST market.

Further to #1, professional developers can bring many benefits to a development effort:

• Because they can work full-time, they can usually achieve results more quickly.
• A good salary will attract the most talented/experienced developers.
• Paid developers can be compelled to work on important but tedious aspects of a project.

Further to #2, there is a very real commercial VST market, populated with profit-oriented companies seeking to sell plugins, DAWs, etc. This has several consequences:

• Success of a NetVST company depends on the support of VST suppliers. Inability to work with even one major VSTi will most likely lead to failure.
• Big companies prefer to do business with other big companies. They are ill-equipped to deal with small niche players, let alone grassroots projects.
• A profitable business can reasonably be expected to survive and remain active for longer than a non-profit organization.

To succeed, a NetVST company must be seen as a friend to other companies in the VST/DAW market. If not, they will boycott, and the NetVST effort will fail.

The number-one concern of every profit-making company is preserving profitability. Therefore, the NetVST company's product must not facilitate piracy, i.e., allow people to use commercial VSTs without paying.

In the VST/DAW software market, this obsession with piracy leads companies to expend enormous effort on copy-protection techniques such as licensing schemes and hardware dongles—fundamentally wasteful effort they would prefer to avoid. The ideal NetVST implementation should therefore enforce its own form of VST copy-protection.

The number-two concern of every company is expanding their market, i.e. reaching new customers. The recent trend toward heavy discounting of VSTs shows the importance of this concern. After every customer who can afford your €500 VST has already bought it, you may have to drop the price to €250 or less to attract more buyers, at the risk of offending those “best customers” who bought at the higher price. This is one reason why companies are beginning to experiment with subscription pricing models. The ideal NetVST implementation should support multiple pricing options.

The number-three concern of all software companies is technical support, which most see as another wasteful effort and a drain on profits. Actually it is even worse, because support requirements are notoriously hard to predict, so even a successful product could actually become a net loss if it proves too difficult for customers to install, use, or manage. The ideal NetVST implementation should therefore make installation/use/management of VSTs easier for the customer.

The final major concern shared by all companies is the cost and complexity of distribution. In software markets, the Internet has been a huge boon, as companies are able to distribute their products direct to customers, but this is not without cost. Companies find themselves becoming online merchants, which may be well outside their core competence, and failure to perform well may lead to embarrassing public criticism. The ideal NetVST implementation, therefore, should include an integrated online store, managed by the NetVST company.

To summarize, the NetVST company should provide:

• Integrated VST copy-protection
• Support for multiple VST pricing/payment options, including subscription or pay-per-use pricing
• Simplified VST installation, use, and management
• An integrated “VST store” to also simplify VST purchasing

Each of these items is discussed below in its own section. But first, we briefly consider various options for deployment of the NetVST implementation itself.

Options for how a NetVST system is deployed can be characterized according to the distance between the host program (e.g. DAW) and the VSTs:

1. In a VST wrapper/bridge implementation, host and VSTs live on the same computer.
   • A special case of this would be wrapper/bridge software deployed in the form of a library or module which could be linked directly into a DAW or other VST host.
2. In a LAN implementation, VSTs live on one or more server computers, and are accessed from host programs on other computers on the same local-area network.
   • Most NetVST development to date has focused on this case.
   • Vienna Ensemble Pro is an established commercial product of this kind.
3. In a Cloud-hosted implementation, VSTs live on servers, and are accessed across the Internet.
   1. try-sound is a pioneering system of this kind.

Substantially all of the considerations below apply equally to all three NetVST deployment options.

VST plugins are vulnerable to piracy (unauthorized copying and use) because they are just software files, which implement well-defined, publicly-known APIs to connect to host programs. To eliminate this vulnerability, some VST companies use various kinds of “copy-protection” technologies, all of which are based on the notion of locking.

A locking technique renders a plugin (or program) inoperable unless some licensing condition is met, e.g.

• a hardware dongle is connected, and/or
• a soft license is present, e.g. as a file or Registry entry

In either case, there is a license resource (hardware dongle and/or soft license) which satisfies some logical equation embedded in the product's executable code. Usually, this equation will have at least one other input which in some way identifies the hardware on which the product is authorized to run, such as the serial number of the main hard-disk drive, Ethernet address, or the like. The logical equation computed by the product acts like a “lock”, and the license resource a “key” which opens the lock and allows the product to run normally.

Locking schemes have many problems:

• They complicate the process of installing and running the code for paying customers–the very people whose experience should be the most convenient and seamless.
• They are vulnerable to “keygen” attacks–reverse-engineering of the locking equation
• They are also vulnerable to “patching” attacks–editing the executable code to bypass the lock

A NetVST implementation, which sits in between the VST product and the public API it presents to host programs, naturally supports two alternative copy-protection methods as follows:

1. The VST itself can be encrypted using a customer-specific key.
   • No two “copies” of the VST file(s) are identical, making simple copying ineffective
   • The executable code would be decrypted by the NetVST program when loading the plugin
2. The host-VST communication can be encrypted
   • Option 1: encryption and decryption are done by the NetVST system
   • Option 2: the VST itself presents an encrypted API, so it cannot be loaded directly by a host

The second technique imposes a run-time cost, but is vastly more secure.

If every copy of the NetVST program (the one which actually loads and executes VST plugins) is identical, even these cryptographic protections will still rely on a lock embedded in the the NetVST program itself, which will then be vulnerable to keygen or patching attacks. The solution is to apply a similar cryptographic protection to the NetVST program itself, i.e.,

• Each “copy” of the NetVST program contains an embedded decryption key, specific to the customer
• No two copies are thus alike, so file-copying is ineffective
• Decryption will only work for VSTs which have been encrypted with the same key

Of course, no copy-protection scheme is foolproof. A sufficiently determined person will always find a way to circumvent it. The key points are:

1. A NetVST company will have the motivation and resources to engineer a more secure system then VST makers, because doing so is part of the core of their business.
2. The copy-protection system does not have to be unbreakable–it just has to be hard enough to break that no one will be “sufficiently determined” to bother.
3. Encrypting software on a per-customer basis makes it very difficult for criminals to gather sufficiently many “copies” to adequately analyze how they differ.

A great many VST plugins don't implement any copy protection at all. This includes both free plugins, for which copy protection is unnecessary, as well as paid plugins from companies which don't have the resources or inclination to implement protection. Commercial NetVST products should, of course, support such plugins.

If the protection provided by the NetVST product itself is good enough, many VST makers in the “paid but not protected” category would likely be very interested in it.

Commercial NetVST products should also support plugins which use legacy dongle- or license-based copy protection schemes, for two reasons:

1. End-users will already have a substantial collection of such plugins, which they should be entitled to continue using without restriction.
2. VST makers can't be expected to switch over to newer protection technologies overnight.

If the protection provided by the NetVST product itself is good enough, VST makers will be quite strongly motivated to support it instead of their legacy schemes, because it will be simplify life for end-users and VST makers alike.

This video presents an experimental NetVST system in which both local and remote instances of a VST plugin are used, to allow the VST GUI to appear inside the user's DAW, while the heavy DSP lifting is performed by the instance on a separate NetVST server. Three comments should be made concerning copy protection in this scenario:

1. If the local VST instance only provides GUI functionality, it won't need any copy protection.
2. However, this scenario will be most flexible if the user has the option to run the DSP locally as well. Cryptographic copy protection will work nicely here, ensuring that legitimate buyers can use all aspects of the VST code, but pirate copies will be useless.
3. If the VST uses a legacy copy protection technique, e.g. a dongle, the user always has the option of simply using two dongles (one on the local DAW computer, one on the VST server), but it would be nice if the NetVST product could also implement some kind of network-based authorization technique, such as a challenge/response scheme, so no dongle is required on the local machine.

Many VST customers will continue to prefer the traditional pay-once pricing model, and as noted above, they will normally already have a substantial library of VSTs which they have already bought and paid for, and should be entitled to continue (including in the NetVST system) however they wish.

The pay-once model has serious limitations, which a commercial NetVST solution should seek to mitigate:

1. The pay-once price must be high enough to cover anticipated technical support and a reasonable number of free software updates, but as a result, may be high enough to turn away many prospective buyers.
2. A “reasonable number” of free updates means different things to the end-user (who would prefer that it be infinite) and the VST maker (who must limit after-sale cost liability). This leads to various upgrade pricing schemes which add complexity for both maker and end-user, with little benefit to either.
3. End-users will only willingly pay for updates which include new functionality, but the VST maker must also worry about bug-fixes, whose associated cost can be substantial and worse, unpredictable. This has led some VST makers (most (in)famously Roland) to attempt fully subscription-based pricing models, also known as software as a service (SAAS).

Commercial NetVST implementations should ideally support all kinds of pricing options, so as to be as “friendly” to VST makers as possible. Further to the three points above:

1. The usual solution to the first issue is for VST makers to provide free, limited-time “evaluation” versions for users to try. A commercial NetVST system should support this, by allowing certain VSTs to be used for a short time, after which they are automatically deleted unless purchased. See also below.
2. The upgrade issue is an aspect of VST management, discussed in detail in the next section. Commercial NetVST systems should have features to simplify all aspects of management for the benefit of end-users and VST makers alike.
3. Commercial NetVST system should always link to an online e-commerce component to facilitate handling and verification of end-user payments. This will support and simplify payments for initial purchases, upgrade purchases, and subscription payments (which are effectively pre-authorized, monthly upgrade purchases).

However, a NetVST system with adequate copy protection can go beyond even these pricing models. The NetVST program can leverage its position in the host-VST communication bottleneck to track usage of individual VSTs. The resulting data will become a valuable resource in its own right, e.g. to inform VST makers how customers are using their products, and/or to facilitate targeted marketing efforts. However, it can also be used to implement usage-based pricing options, such as:

• Plugins could be acquired for a low (even zero) initial price, then billed to the end-user on a per-second-of-audio basis. Studios would love this, because they could acquire any plugin they (or their customers) might ever want, but only pay for what they use.
• Tiered pricing would be possible: “draft quality” usage could be billed at a lower rate than “final mix quality”.
• Free evaluation versions of VSTs would no longer be necessary, as pre-purchase evaluation would simply be a special case: For a limited time, the per-second price for a plugin could simply be set to zero.

Note that any system of automatic pricing enforcement must necessarily rely on some kind of software locking mechanism as described in the previous section. Due consideration must be given to making such mechanisms cheat-proof enough that users won't be tempted to try to circumvent them.

Acquiring and using any software product imposes a burden of management on the end-user, and today's VST products are particularly bad in this respect.

• Every company's e-commerce solution is different.
• The user needs to create accounts and passwords on dozens of different systems.
• Multiple payments-processing services make it hard for users to track spending.
• Every company's pricing and upgrade schemes are different.
• Every product has a different download process.
• Every product has a different installation process.
• Every product has a different licensing/authorization process.
• Every product has a different upgrade process (which is many cases, is as complex as installation).
• In a large studio, much of the management effort is multiplied by the number of computers in use.

A commercial NetVST solution must address these issues, even if it does little else. Apple's innovative “App Store” for iOS devices provides the model to emulate:

• Single system for payments handling and authorization means no more multiple accounts/passwords.
• Single system for invoicing means easier tracking of spending.
• Integrated interactive “store” (essentially an embedded e-commerce web site) allows wares to be presented in a good light for marketing, and easily searched/browsed by prospective buyers. See next section.
• One-click download and installation is a must. This may require development of product-specific install/uninstall scripts, but the effort will pay dividends.
• Handling of licensing, upgrades, etc. should be built into the one-click process.

And finally, dear the heart of every online marketer everywhere…

• The ability to track customer purchases is pure marketing gold.

As mentioned in the previous section, a commercial NetVST system should include an integrated “VST store” modelled on Apple's fantastically successful App Stores. This is basically a standard online e-commerce web site, so an established online VST reseller would have a natural advantage in building one.

The key to “integration” of the VST store is automatic coordination between the databases of the online store and the end-user's NetVST system. When a customer completes a purchase on the store web site, the associated downloads, license codes, etc. automatically become available to their NetVST system. (Amazon's online store and Kindle app for iPad provide a useful model of how this should work.)

Other than that, there is little to say about the notion of a VST store, as it is simply one more e-commerce site on the web.