Schlagwort: bsd

On Private Property of Immaterial Goods

Von 16. Februar 2013 Eigentumsfragen, English, Freie Software 1 Kommentar

Make Copyright HistoryThe following excerpt is part of the longer essay »Free Property — On Social Criticism in the Form of a Software Licence« (PDF). It criticizes the wide-spread distinction between »natural« property of material and »artificial« restriction of immaterial goods due to private property regimes. The omitted second part, which I do not find so insightful, is about free software licences. Here’s the excerpt:

Intangible goods are different …

Indeed, at least some people within the [open-source/free-software] movement do seem to be bothered about property, at least where it specifically affects digital goods. Indeed, in terms of what they actually are, physical goods and so-called “intangible” goods differ.

(mehr …)

Selbstorganisierte Fülle (2): Voraussetzungen für erfolgreiche Peer-Produktion

Von 7. Juni 2010 Commons, Freie Hardware, Reichtum & Knappheit, Theorie 6 Kommentare

Eric Raymond (Autor: Russ Nelson, Lizenz: gemeinfrei)[Erster Teil]

Faustregeln für die Zusammenarbeit

Wir haben im ersten Teil gesehen, warum Leute bei Peer-Projekten mitmachen oder neue Projekte gründen, aber das erklärt noch nicht, warum und unter welchen Umständen solche Projekte langfristig erfolgreich sind. Peer-Projekte unterscheiden sich schließlich sehr von dem, was man sonst so gewöhnt ist. In Firmen gibt es Bosse, Vorgesetzte, die ihren Untergebenen sagen, was zu tun ist; als Selbständige/r geht man Verträge ein, die eine/n verpflichten, dies oder jenes zu tun; auch in Schulen, beim Militär und in anderen offiziellen Institutionen gibt es immer Leute, die den Ton angeben, und andere, die folgen müssen.

Bei Peer-Projekten gibt es solche Strukturen nicht. Es gibt keine Bosse oder Vertragspartner, die den anderen mit Entlassung oder anderen finanziellen Konsequenzen drohen könnten; es gibt auch keine Lehrer/innen oder Offiziere, die eine/n bestrafen können, wenn man ihnen nicht gehorcht. Warum und unter welchen Umständen funktioniert also die Zusammenarbeit, wenn sie nicht durch Geld oder Zwang motiviert wird?

(mehr …)

Selbstorganisierte Fülle (1): Was commonsbasierte Peer-Produktion ist und warum Leute da mitmachen

Von 31. Mai 2010 Commons, Freie Hardware, Reichtum & Knappheit, Theorie 9 Kommentare

Beitragen statt tauschenDies ist der erste Teil der schriftlichen Fassung des Vortrags, mit dem ich zur Zeit zu erklären versuche, wie Gemeingüter und Peer-Produktion zu Grundlagen einer nichtkapitalistischen Gesellschaft werden können. In diesem ersten Teil geht es neben einleitenden Überlegungen zur digitale Fülle um die Grundlagen: was Commons und Peer-Produktion sind, wo Peer-Produktion heute schon erfolgreich praktiziert wird und warum Leute da mitmachen.

Das Internet als Ort der Fülle

Ich beginne mit dem Internet – aber keine Sorge, dabei wird es nicht bleiben, das ist nur der Anfang. Man kann das Internet als Ort der Fülle betrachten, und zwar der Fülle in unterschiedlichen Bedeutungen des Wortes. Die erste Bedeutung ist Fülle im Sinne von „Überfluss“ oder „Verschwendung“. Darin ist das Internet sehr gut. Ich kann mich, wenn mir der Sinn danach steht, beispielsweise den ganzen Tag durch Fotosharing-Seiten klicken, kann mir beliebig viele Fotos zu bestimmten Leuten oder Themen angucken (zum Mount Everest beispielsweise), auch wenn sie großteils recht ähnlich sind und ich bald alles Relevante gesehen habe – ich kann trotzdem immer weiter machen.

(mehr …)

ox4 Notes IV: Case Study of a Large Free Software Project

Von 15. Mai 2009 Arbeit & Freiheit, English, Freie Software 2 Kommentare

The BSD daemonThis post finally concludes my coverage of the ox4 conference (part 1, part 2, part 3). On the third day, George Dafermos presented a case study of the FreeBSD project. He talked mainly about how the project is structured and how division of labor emerges.

The core team comprises 9 people which are elected by the committers and who, in turn, decide who gets commit rights. There are about 250 committers (who have the right to commit code to the code base) and about 5500 contributors (who have to filter their contributions through one of the committers). This confirms the 1-9-90 rule of thumb: less than 1% of participants steer the project (the core team), less than 10% contribute regularly (the committers), the rest contributes occasionally (the contributors). Officially, the core team also has the task to resolve conflicts, but there are very few conflicts, and usually the involved people resolve them by themselves.

(mehr …)