Message 04986 [Homepage] [Navigation]
Thread: oxenT04940 Message: 5/8 L3 [In index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

Re: [ox-en] Free <something>

Dear Michael,

On Mon, Sep 08, 2008 at 09:27:56AM [PHONE NUMBER REMOVED], Michel Bauwens wrote:

any chance you would write a little investigative note on this for our p2p

Sorry, no:

- Generally, because I already write too many fugacious texts, and I
  hope to have been propagating free software and its underlying 
  principles with my best effort in the past 15 years (still encounting 
  :-) ).

- Particularly, as this is merely a single example how F/OSS-licenses 
  can be utilised in many very different ways:

0. "Just take it"
Grab F/OSS-stuff at your choice and utilise it internally for whatever 
you like to: Just use it // Enhance it // Found a project/product upon 
All BSD-style licenses allow for that (e.g. MIT-,, the three
classical BSD-licenses), but you are not going to tell anybody, anyway.
Hence other F/OSS-licenses are basically O.K., too, as long as you take 
care that nobody finds out what is inside of your product (try
obfuscating that fact a bit).  And if somebody really finds out and
pulls you to court, a settlement of a few 1000 $ is usually sufficient
to silence those F/OSS enthusiasts.
Examples: CISCO IOS, some small parts in Micosoft Windows, etc.

1. "Marketing only"
Develop in a closed manner, without any chance for others to contribute, 
Set up a nice web site, mailing-list(s), wiki to create the "right" 
impression of your "F/OSS"-project, and generate some traffic / content
there, but nothing too significant.  If you did it right, after a while 
some people will automatically show up and perpetually generate traffic / 
insignificant content without much ado from your side.
"Release late, release rarely": significantly delay the release of the 
sources (at least 6 months) after releasing a compiled version (potentially, 
but not necessarily only available for money), and take your time for a
source release (at least 15 months past the last).  Reasons to name:
Preparation of the source "to be ready for the public", sorting out
licensing issues, "Our feature driven development aims at timely product 
delivery to our customers, not at the source releases for the interested
public, you must understand", etc..
Extra evilness: Prove that you perfectly understand to play with F/OSS-
licenses by releasing only the fragments of the source you definitly have 
to, licensewise.  Argue that the other portions are not derived work and
contain pieces which are licensed (proprietory) from third parties or are 
patent protected.  Hence nobody will be able to rebuild and re-release 
your "F/OSS"-product in its completeness.
Examples: Microsoft WiX, potentially ODG, etc..

2. "Marketing & Maximise scoop up"
Prove that you well understand the F/OSS-principle "do not reinvent the
wheel", by thourougly investigating the F/OSS-landscape for components
from vivid F/OSS-projects you can utilise.  This minimises your own
implementation efforts.
Do not feed back any enhancements or bugfixes to third party components
to the upstream projects, as this can turn out to be labour intensive and 
would derogate the technical advantages of your product (actually this 
mindset turns out to completely wrong in the long run, as it usually 
causes major efforts to regulary integrate upstream enhancements and 
bugfixes in your private branch(es) of the source(s)).
Also apply all of 1. "Marketing only", but you can tone down on real
marketing, as your primary goal is to maximise the scooping!
Examples: Tom-Tom-Firmware, Google-Chrome, Apple-MacOsX (Apple is 
          slightly getting better over the years), Microsoft SfU 
	  ("Services for UNIX", which started as "UNIX services for
	  Windows NT4" in 1998), etc.

3. "Marketing, Scoop up & Feed back upstream only when necessary"
You have understood or learned the hard way that not feeding back 
anything to the upstream projects backfires sooner or later, as described 
in 2. "Marketing & Maximise scoop up".  Hence you feed back your 
enhancements and bugfixes to the upstream projects where you feel it is 
expedient and really necessary, but you still perceive this as tedious
work worth avoiding whenever possible.
Still you stick to most of the "golden rules" in 2. "Marketing &
Maximise scoop up" and therefore also to 1. "Marketing only".
Also, you may have realised that you can also scoop up labour, if you
really allow for volunteers to contribute.  Thus you may implement
practices to skim the best people and ideas in order to enhance your
Finally, you understood that a public bug-tracker gives you access to
thousands of beta-testers you can spare inhouse, a working public mailing 
list with developer-feedback provides feature-requests really fulfilling 
the users needs, and a wiki or alike significantly reduces ("auto-
fulfills") support requests.
Examples: Apple-Safari, good parts of SUNs software stack (esp.
          Java, Solaris, etc.), Microsoft CodePlex (with many projects 
	  e.g. IronPython, IronRuby, etc.), Canonical Ubuntu, Google 
	  Summer of Code ("GSOC"), etc.

4. "Developing _in_ the public, Developing _for_ upstream"
Well, the title says it; the only variable is who can contribute and how
easily.  This makes up the whole (IMHO vastly academic) debate about
extremely open ("everybody can directly contribute", e.g. Wikipedia) and 
closed ("we have a core team / maintainer who decides what goes in or not") 
development model, with many nuances in between.  "Model as it fits",
is my suggestion.
It makes life simpler, if you are maintaining / hosting projects yourself, 
so upstream is yours / inhouse.  If that is not feasible, pay / employ 
developers in upstream projects.
"Release early, release often", shortens feed-back cycles and
accelerates product development.
Examples: Debian (simply defines "upstream is always us", as if all the
          F/OSS-world would be developing for Debian), RedHat (most 
	  products), OpenSuSE, Mandriva, etc., and in small doses: 
	  SUN, SGI, Intel, Hewlett-Packard (HP), etc., etc..

This is all, but new: Cisco has taken BSD to found its IOS in the 1980ies 
and it has taken SUN three decades to go (or being pushed by commercial
failures) from 0. to 3. / 4..  Even Microsoft crouched from 0. to 3.
(<>, <>) in the last
15 years.

BTW, did I specifically adress software? Only in the examples! 

This text is licensed under "Creative Commons Attribution-Share Alike 3.0 
(CC BY-SA 3.0)" license <>.

Michael, thus you can utilise it at your free will, within the
limits of this very license.


On Sun, Sep 7, 2008 at 11:13 PM, Florian v. Samson <
fsamson> wrote:
On Sun, Sep 07, 2008 at 10:35:35AM [PHONE NUMBER REMOVED], Stefan Merten wrote:

I just saw

I'm not an expert here but AFAICS the design is based on FPGA chips
(field programmable logic arrays) which is best described as
programmable hardware. You can reconfigure the chip by software to
execute the needed functionality. At the moment this seems do be
considered a development board and they plan to design an ASIC which
is a chip which is custom designed and faster.

The project founded the company

to produce and sell the hardware based on the Free Design.

This has been around for quite some time.

From their about-us page:

  Traversal Technology LLC was founded to manage the production and
  sale of hardware based on various open designs, and to provide
  professional validation and commercial support for these products.

  Open designs and open interfaces allow Traversal Technology to
  interact with the Open Source community for mutual benefit. By
  leveraging the potential of the Open Source community, Traversal
  Technology is able to offer quality products at competitive prices.
  Conversely, users are able to use their hardware to its full
  potential on any platform, unhindered by lack of documentation, lack
  of support, or trade secrets.

One of the restrictions of the project:

  * While the hardware will be open spec, not all of it will be open
    source at first. This gives Traversal Technology the advantage it
    needs to recoup its non-recurring engineering (NRE) costs. (Edit
    by Tim: We have committed to releasing all of the RTL to the chip.
    Some of it is being developed in the open already. Some of it may
    be released at the time the ASIC is released. Some of it will be
    released after a time delay necessary for said competitive


Well, under cover this has been selling for quite some time at as
Raptor 4000 from TechSource
Hence it is questionable tho waht extent this project is inspired by
some OpenSource philosohy, rather than sticking formally to the rules to
utilise the nice label.
In contrast to the OGD, which is only available with an PCI-X connector,
(almost no regular motherboard has such a slot), the Raptor 4000 is also
available as an PCI-E card.
On the net you will not find any link between ODG/Traversaltech and
TechSource, but technically the products are identical. When I placed a
hint about that connection on the wikipedia page

it was deleted in less than 15 minutes.


Contact: projekt

The P2P Foundation researches, documents and promotes peer to peer

Wiki and Encyclopedia, at; Blog, at; Newsletter, at

Basic essay at; interview at

KEEP UP TO DATE through our Delicious tags at

The work of the P2P Foundation is supported by SHIFTN,
Contact: projekt

Thread: oxenT04940 Message: 5/8 L3 [In index]
Message 04986 [Homepage] [Navigation]