Subject: Re: How to run an FSB R&D lab (maybe)
From: Tom Lord <lord@regexps.com>
Date: Thu, 21 Mar 2002 19:03:05 -0800 (PST)



   From: "Brian J. Fox" <bfox@ua.com>

      Date: Thu, 21 Mar 2002 17:46:04 -0800 (PST)
      From: Tom Lord <lord@regexps.com>

	      But by itself, I just don't see how an endeavour like this can be
	      self-sustaining.

      By itself it can't.  It needs complementary tactical business units
      that can be customers or sibling divisions.

   Please help me to understand.

   Are you proposing something different than Bell, Xerox, et al?  If so,
   what exactly is the difference?


A few key differences (there may be others):


	1) Orientation towards products that fit (and help to improve)
	   open source processes and FSB scale

	   When Sun Research leads the world into, for example, J2EE
	   -- that's a technology whose process and scale presumptions
	   aren't a good fit for FSBs.  The lab I have in mind is
	   likely to have a more human-scale orientation, which is
	   better aimed for FSBs.  Small and tractable is good, for
	   example.  So is casually and asynchronously extensible.
	   Army-of-programmers solutions need not apply.
	   Predominantly anarchic confederation of mostly independent
	   individuals and small teams solutions are welcome.


	2) Chartered for Free Software or (when tactically useful)
           Open Source licensing

	   The labs you mentioned suffered from the presumed
	   proprietary nature of their product.  Their outcomes might
	   have been very different if that presumption hadn't gotten
	   in the way.


	3) Product, not publication emphasis  (Practical R&D)

	   I haven't re-checked the labs you mention in their current
	   form, and can't speak to their historic form, but a common
	   theme in the mission of contemporary corporate labs is
	   peer-reviewed, academic-context publication.  While I'm not
	   opposed to publication when it makes sense, it's not the
	   right metric for my lab: that's usually the wrong kind of
	   innovation to aim for and preparing good papers is a huge
	   and expensive effort.  (On the other hand, helping to boot
	   an open-source-world lab notes and hackmem series is a
	   likely goal.)


	4) Free Software/Open Source gaps orientation

	   My lab will be inclined to think about filling specific
	   gaps and shortcomings in the corpus of free software and
	   open source solutions, and leveraging the parts that
	   already exist.  Corporate labs are variously concerned
	   with fundamental breakthroughs and with leveraging their
	   host organizations' proprietary strengths.


	5) Possibilities of service-based funding

	   In ways too numerous to mention (a subset is listed my old
	   business plan if you have a cached copy), a lab such as
	   I've described can sell transfer services, attention to
	   particular business needs, and various forms of useful
	   interaction to one or more FSB or partial FSBs.


	6) Possibilities of performance-based funding

	   For interactive and performance based technologies, public
	   performances and displays can provide a basis both for cost
	   recovery and early marketing and market testing of spin-off
	   products.


	7) Lower costs

	   The labs you mention were cloistered in fairly expensive
	   facilities.


	8) Different hiring emphasis

	   Labs generally (I gather) hire for cultural compatibility.
	   Beyond that, though, the contemporary corporate labs
	   have a university-style credential criteria that reflects
	   their orientations towards publication and fundamental
	   research.  The relative weighting of those criteria are
	   reversed in my scheme and a lot of emphasis given to 
	   hacker spirit.


If you want to talk about the specific budget process game that
relates a lab to other business units, that's an interesting topic,
but one that's rather site-specific.  Probably not FSB material.


-t