This section was suggested by Orest Zborowski <orestz@eskimo.com>; it is still under construction.
It is meant to help potential commercial software developers to market their products. There are several caveats to watch when doing this, e.g. the GNU General Public License (GPL) and the GNU Library General Public License (GLPL).
I'd appreciate anyone who wants to share her experience with Linux-specific marketing issues to send me some lines (see questionaire below).
Please make sure that people interested in more specific items can contact you via EMail or fax.
Here is a questionaire which I ask you to fill out and send me. Answers will be handled anonymously, and I will only disclose facts, no names. The facts you tell me will be of great value to get an idea how the commercial Linux market looks like. If you do not market your application in a native Linux version, please tell my why. If not stated otherwise, ``application'' stands for ``native Linux version of your application''.
Porting to Linux simply means recompiling in many,
many cases. Sometimes some #include tweaking may
be necessary. If you develop your apps using GNU C/C++
which is very useful sometimes, there should be
virtually no further work to do.
One big advantage with Linux is that all the source code of the operating system is freely available. Experienced programmers can easily spot the locations where problems occur and contact the "responsible" developer for assistance. I never encountered anyone being impolite -- just make sure you read the respective documentation first...
The persons responsible for the Linux port should know where to get vital information in case of problems. The Linux Documentation Project offers plenty information about all and everything and the kitchen sink. The Linux INFO-SHEET is a good place to start with for beginners.
The key to success with your Linux port is Internet access, particularly FTP access to the big Linux FTP servers such as sunsite.unc.edu or tsx-11.mit.edu and their legion mirrors.
It appears that one big problem is after-sales
support. If you do market your software for Linux, you
should consider to employ someone who knows whom and
where to ask in case of problems with the OS itself. On
the other hand, you may expect problems with Linux to
be solved much faster than problems with
commercial Unix variants. For example, the
/bin/login bug allowing people to log onto
Unix hosts as root without entering a password
(known publicly in September 1994) was solved in a
fortnight under Linux, whereas IBM shipped AIX with the
broken /bin/login for another couple of
months (and didn't tell customers although there was a
fix available via FTP).
After-sales support for Linux, on the other hand, can be a good opportunity for small companies and startups. If you want to sell a Linux version of your product you might want to find such a company to outsource the after-sales support (see respective section). They might even help you with the porting.
Some companies selling big and expensive software packages offer completely installed systems, i.e. the hardware, the OS and their specific software. In the contract, you can restrict your warranty to specific kernel/library versions so that problems are unlikely to occur at a later time.
The GNU General Public License (GPL) and the GNU Library General Public License (GLPL) contain no restriction in terms of marketing products developed with GNU tools as the GNU C/C++ compiler. Anyway, the legal strength of the GPL was never checked at court -- I doubt it can be enforced outside the U.S.A. If you violate the GPL, you may expect being sued by the FSF and being bashed publicly by the Linux community -- the GPL has a strong ethic value. In case of doubts, you might want to contact the Free Software Foundation. A very comprehensive interpretation in German is printed in section 1.7 of Kai Petzke's book "Unix fuer jedermann -- Einfuehrung in Linux", Bernd-Michael Paschke Verlag, Berlin 1995, ISBN 3-929711-07-9.
In short terms: The GNU copyleft doesn't affect your software development and marketing at all. Feel free to sell your products without source code and everything, just as with every other piece of commercial software. The GNU Public License says, if you put a piece of software under the GPL, or if you receive it as a piece of GPL'd software, you have to offer your customers the same rights concerning that software that you have (i.e. hand them the source code, or offer to deliver the source code for the cost of distribution for three years after delivery of the binary). The GPL does not force you to put all your software under the GPL, irrespective of whether the operating system it's been written for is GPL'd itself. In this HOWTO, you'll find an entire bunch of commercial software products none of which is GPL'd.
Pricing: There are three major philosophies. Some companies offer a full or limited version for a very low fee or even for free. Others consider the Linux version as valuable as those for other OS's and offer it at a reasonable discount. Third, the price is equal to that of, say, the Solaris or the HP/UX version. Finding a reasonable price for your product may be somewhat more difficult than for other Unixes because there are many Linux users expecting to get everything for free. Others (seriously interested customers, i.e. business people and decision makers) know that nothing is for free. You'll have to decide for the target customer.
A word concerning fast version shifts. This is clearly a prejudice. From the view of a software vendor, this is clearly not true. Linux is no moving target. It is true that Linus Torvalds <torvalds@cs.helsinki.fi> sometimes releases two or more kernel patches per week (or even more) in the hackers' corner (odd minor kernel release numbers). However, if you found a kernel doing what it's designed to do (version 2.0 being a good choice as of this writing), there's no reason to upgrade. Leave everything as it is and limit your warranty to certain kernel releases. Selling complete systems helps here, too, because you can ensure the respective kernel and its device drivers work in perfect harmony with the computer, its peripherals and your application.
You might consider offering a statically linked Linux version too (as it is very popular for SCO due to some nasty bugs in several SCO runtime libraries) but please tell your customer about the additional memory requirement. However, it is important to mention that a dynamically linked application automatically satisfies all the requirements of any LGPL libraries that it uses, but a statically linked application does not. A statically linked application must be available in some relinkable form to satisfy the LGPL.
If you intend to offer a shrink-wrapped systems (i.e. a complete hardware/software installation) please avoid IDE harddisks. Those disks are a perfect performance bottleneck for a real-world multitasking OS if it comes to serious work. If some day EIDE offers busmaster DMA, this rule may change, though.
Two killer applications are needed under Linux: a good text processing system and a good spread sheet.
Copy protection is virtually impossible under
Linux. Because the kernel and all the associated tools
are available as source code, any experienced hacker
can hook dongle or key card ioctl() calls. On a
PC, you don't have a machine/CPU id available. You
don't want to build a specialized kernel for a certain
(and given) hardware configuration, not disclosing the
corresponding source code; such a kernel would be a
``derived work'' according to the GPL, and doing so would
clearly violate the GPL.
Last not least, don't forget that university and college students who are the decision makers of tomorrow. If you offer them a reasonably priced product for their beloved operating system today (think of campus licenses), there's little question which application they will choose tomorrow.