PRE-FOSS section

dosp-survey.ltx

@@ -190,31 +190,57 @@ see from later projects, this is the most common use of DOSP.
 
 \numberedsection{Scheduled Relicensing}\label{scheduled}
 
-\subsection{Motivations}\label{motivations}
+\subsection{Proprietary Ramp-up, Eventually FOSS (PRE-FOSS)}\label{motivations}
 
-DOSP is usually described as protecting commercial interests of a software
-developer by maintaining a window of time during which some users might be
-incentivized to pay for licenses that they might not need if the software
-were released as open source.
+DOSP is usually adopted as an ongoing commercial strategy. It reserves a window
+of time for a company to sell the latest features before they become available
+to all under open license.  In addition to this common form of DOSP, we find
+open source delays occur in another notable form.
+
+In this form, projects plan to eventually be fully open but initially operate in
+a less open manner.  The plan for such projects is to become full-fledged open
+source efforts once the project has matured or stabilized. This
+\textbf{one-time} delay at the start of a new project is, to us, not DOSP, but
+it a notable form of time-delay in the open source world.
 
 % Fit into discussions about incentive/funding models
 
-We've also seen one-time delays for new projects whose developers state
-a concrete intention to convert those projects to an open source license.
-They may have non-economic reasons for those delays, such as shame about
-poor code quality, concern about security issues that may be apparent in
-unaudited source code, initial uncertainty about which license to choose,
-a need to procure permissions from other copyright holders, a desire to
-establish a community or governance structure, or a plan to incorporate
-a legal entity. They may initially publish source code with no license
-at all (which is not considered open source, because it does not grant
-users rights to modify and redistribute the code), or they may publish
-a binary-only demo version or versions. Although these scenarios involve
-an intent to publish something as open source in the future, they are
-also rather different from the cases we focus on here, for example
-with regard to whether the delay is \emph{desired} by the authors,
-whether it's \emph{predictable} to users, and whether it's expected to
-\emph{recur}.
+These projects begin development in a proprietary mode.  During this
+pre-open-source period, their practices might reflect just about any variation
+of non-open-source software. They might not publish any code.  Or release their
+code under non-FOSS license or no license at all.  They might only release
+binaries or release nothing. They might not accept outside contributions.  In
+short, these projects range from wholly, traditionally proprietary in nature to
+public collaborations that stop just short of a FOSS license.
+
+Usually, these projects explain that they plan to become open, explain why it
+hasn't happened yet, and describe the conditions (sometimes vaguely) that will
+trigger a re-licensing toward open source.
+
+There are many possible reasons why a project might start out with some public
+visibility but not yet ship open source code.  The ones we have observed:\footnote{CITE everything in this list}
+
+
+\begin{itemize}
+  \item shame about poor code quality
+  \item concern about security issues that may be apparent in
+unaudited source code
+  \item initial uncertainty about which license to choose
+  \item a need to procure permissions from other copyright holders
+  \item a desire to establish a community, governance, or a legal entity
+\end{itemize}
+
+Although these scenarios involve an intent to publish something as open source
+in the future, they are also rather different from the DOSP cases we focus on in
+the rest of this document.  They differ, for example with regard to whether the
+delay is \emph{desired} by the authors, whether it's \emph{predictable} to
+users, and whether it's expected to \emph{recur}.  Projects that start out
+proprietary with a stated plan to go open eventually are not practicing DOSP as
+a business model. While one might usefully consider the question of when to
+deviate from the principle of "be open from day one",\footnote{See
+\otsurl{http://archive.civiccommons.org/2011/01/be-open-from-day-one/index.html}
+for more about this principle.} the commercially interesting tradeoffs are
+mostly found in projects that opt for an ongoing DOSP strategy.
 
 % The BUSL AUGs also seem to show (especially among database developers?)
 % a desire to prohibit direct competition with the original developer's