\documentclass{slides}
\begin{document}

% not sure raggedbottom does anything with slides
% That is why there is a vfill at the bottom of each one
\raggedbottom
\raggedright
\sloppy

\begin{slide}
\begin{center}
Free Software Business Models

Jim Kingdon, Cyclic Software

{\ttfamily http://www.cyclic.com}

{\ttfamily kingdon@cyclic.com}
\end{center}
\vfill
\end{slide}

\begin{slide}
\begin{center}
Free Software Funding Examples
\end{center}

In addition to volunteers and users, free software has been written
by professionals, such as:

\begin{description}
\item[X consortium]
About 25 employees in 1996. X windows.

\item[Free Software Foundation]
8 employees in 1996.  GCC, GDB, emacs, and other GNU programs.

\item[Cygnus Support]
Over 50 employees in 1996.  GCC, GDB, binutils, etc.
\end{description}
\vfill
\end{slide}

\begin{slide}
\begin{center}
What people will pay for
\end{center}

\begin{itemize}
\item
Ports and new features (Cygnus, Cyclic).  Quote a price for each
enhancement.

\item
Bugfixing Support Contracts (Cygnus, Cyclic).  Fixed yearly price.
Generally too expensive for many users.

\item
Support per-minute or per-call (Yggdrasil).  Probably less profitable
than the more expensive support, but should be viable.

\item
Training (numerous examples).

\item
Consulting/customization (ditto).
\end{itemize}

\vfill
\end{slide}

\begin{slide}
\begin{center}
What people (usually) will not pay for
\end{center}

\begin{itemize}
\item
Internal code cleanups.  One can include these in pricing ports and
new features, but the customers will only pay so much.

\item
Documentation (with a few exceptions).
\end{itemize}

So these can be funded as overhead.

\vfill
\end{slide}

\begin{slide}
\begin{center}
Funding major projects
\end{center}

How to fund a project which is too expensive (relative to the benefits
for each user) for a single customer to fund?

\begin{description}
\item[Yourself]
Plan to sell enough support and future development deals to
make back the investment (Cygnus GDB GUI).

\item[Line up a bunch of small funders]
The problem here is getting enough people all interested in the same
thing at the same time (Cygnus Solaris port).

\item[Outside free software businesses]
A businesses can build upon existing software (perhaps arising from a
research lab, a different business, or a volunteer effort).
\end{description}

\vfill
\end{slide}

\begin{slide}
\begin{center}
Relationship with developers---Why?
\end{center}

By developers I mean people working on the same software that you
support, but not being paid by you.

\begin{itemize}
\item
Developers contribute bugfixes, features, and ideas that your customers
want.

\item
If developers create their own branches of the software, then
customers complain that you lack the features from those branches.
\end{itemize}

\vfill
\end{slide}

\begin{slide}
\begin{center}
Relationship with developers--How?
\end{center}

\begin{itemize}
\item
Offer checkin access to the master sources (avoid the
overworked maintainer problem).  Do require people to submit at least
one and preferably several good quality changes before being offered
checkin access, to weed out people who never get around to writing
any code and people who write poor quality code.

\item
A mailing list to discuss changes.  Focus it on concrete improvements
which someone has offered to implement, not on pipe dreams.
\end{itemize}

\vfill
\end{slide}

\begin{slide}
\begin{center}
Wide distribution of software
\end{center}

Reasons to encourage the wide availability of sources, binaries, and
printed manuals:

\begin{description}
\item[Revenue]
from the distribution service itself (Red Hat, Free
Software Foundation).

\item[Pre-purchase evaluation]
So people can try out the software before
signing up for an expensive support contract.

\item[Word of mouth marketing]
Software users may know people who are potential
customers.
\end{description}

And a caveat: people may use the software and have a bad
experience.  Therefore, publicize the fact that the software itself
does not come with support.

\vfill
\end{slide}

\begin{slide}
\begin{center}
Redistribution of support
\end{center}

One cannot support all of a customer's customers for the same price as
the customer alone, but redistributor arrangements (for example, a
hardware vendor supplying it with their hardware) are important.  Two
solutions:

\begin{itemize}

\item

Redistributor sells support contracts, and passes along difficult
problems (SGI and Ada Core Technologies).  The revenue would be
divided according to a percentage or some such arrangement.

\item

Redistributor provides minimal support (for example, installation
support), and refers people if they want a greater level of support
(Cygnus and Hitachi).

\end{itemize}

\vfill
\end{slide}

\begin{slide}
\begin{center}
Conclusion
\end{center}

\begin{itemize}
\item
One can make money from free software.

\item
% This is not last; that would skew the Q&A too much
Using one of the various models, free software can work for most or all
kinds of software, not just software for hackers.

\item
Having a community of developers and users who take a more active role
than merely as customers does not inhibit free software businesses; it
synergizes with them.
\end{itemize}
\vfill
\end{slide}
\end{document}
