Re: [ox-en] Free <something>
- From: "Florian v. Samson" <fsamson unix-ag.uni-kl.de>
- Date: Sat, 20 Sep 2008 17:03:35 +0200
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
blog?
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
it.
All BSD-style licenses allow for that (e.g. MIT-, X.org-, 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,
practically.
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
products.
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.
(<http://www.codeplex.com/>, <http://port25.technet.com/>) 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 <http://creativecommons.org/about/license/>.
Michael, thus you can utilise it at your free will, within the
limits of this very license.
Ciao,
Florian
On Sun, Sep 7, 2008 at 11:13 PM, Florian v. Samson <
fsamson unix-ag.uni-kl.de> wrote:
On Sun, Sep 07, 2008 at 10:35:35AM [PHONE NUMBER REMOVED], Stefan Merten wrote:
I just saw
http://wiki.opengraphics.org/
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
http://traversaltech.com/
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
advantage.)
-- http://wiki.opengraphics.org/tiki-index.php?page=AboutOpenGraphics
Well, under cover this has been selling for quite some time at as
Raptor 4000 from TechSource
<http://www.techsource.com/products/atc_gra/4000_4000e/index.asp>.
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
<
http://en.wikipedia.org/w/index.php?title=Open_Graphics_Project&oldid=223398235
it was deleted in less than 15 minutes.
Regards,
Florian
_________________________________
Web-Site: http://www.oekonux.org/
Organization: http://www.oekonux.de/projekt/
Contact: projekt oekonux.de
--
The P2P Foundation researches, documents and promotes peer to peer
alternatives.
Wiki and Encyclopedia, at http://p2pfoundation.net; Blog, at
http://blog.p2pfoundation.net; Newsletter, at
http://integralvisioning.org/index.php?topic=p2p
Basic essay at http://www.ctheory.net/articles.aspx?id=499; interview at
http://poynder.blogspot.com/2006/09/p2p-very-core-of-world-to-come.html
BEST VIDEO ON P2P:
http://video.google.com.au/videoplay?docid=4549818267592301968&hl=en-AU
KEEP UP TO DATE through our Delicious tags at http://del.icio.us/mbauwens
The work of the P2P Foundation is supported by SHIFTN,
http://www.shiftn.com/
_________________________________
Web-Site: http://www.oekonux.org/
Organization: http://www.oekonux.de/projekt/
Contact: projekt oekonux.de