Лекция 2

Университетская модель

  1. Группы ученых
  2. Регулярная разработка
  3. Лицензии

Закрытая модель

  1. Закрытая разработка (достаточное количество изолированной разработки)
  2. Правовая защита (запрет распространения)
  3. Продажа копий
  4. Существует единственный правообладатель, который управляет правовой защитой и определяет правила распространения копий (сводится к тому что распространять копии нельзя)
  5. Сокрытие информации

Существование правообладателя — лолерский пункт, нужный для организации работы программистов. Вызвал нешуточные возмущения, потому что это были те же самые бородатые хакеры, работавшие по той же схеме и получавшие удовольствие, но к которым приходит дядя в галстуке и говорит: «это не твой код, он даже не мой, он их» - того самого правообладателя. По-другому нельзя организовать бизнес.

У человека, который за деньги занимается созданием творческих продуктов есть право на имя (он может предъявлять претензии, если кто-то другой назовется им) но больше прав нет, ибо в договоре он подписал это сам. По факту отношения работодателя и работника: в России есть тема на то что и ты можешь распространять свой товар, и работодатель может, если ты не подписал договор, отрицающий это.

Ричард Меттью Столлман (RMS, работавший над лисп-машинами) обнаружил, что весь код, который он написал, не принадлежит ему, ибо он получал ЗП за это и не может ни продать товарищу, ни опубликовать; нельзя ни посмотреть, ни поправить, ибо придет конкурент и сам поправит и сделает больше. Ричард, нажившись на лисп-машине, забегал, засуетился и стал думать - что делать, когда ты все-таки хочешь, чтобы университетские отношения сохранились в дальнейшем. Пришла идея, что если есть запретительная система (вид договора), то должна быть и лицензия, разрешающая распространять, изменять и т. д. Заметим заслуги Столлмана по формированию понятия свободного ПО.

Бизнес модель ясна.

Как развить академическую разработку, дабы выдерживать натиск бизнеса и сохранить отношения.

Открытая разработка

1. «В разработке может участвовать любой» — надо сохранить эту фишку. Мы должны сделать так, чтобы в процессе разработки мог принимать как можно более широкий круг участников.

2. Первое означает две вещи. Во-первых, в отличие от бизнеса процесс распространения строго регламентирован: мы заинтересованы в том, чтобы наше творение распространялось как можно более широко. Распространение необходимо. Чем больше народу встретится, тем больше найдется народу, который сможет что-то там доделать.

3. Во-вторых, в идеале надо привлечь к разработке вообще всех, которые могут и хотят разрабатывать. Надо таких в наш клуб обязательно. Спасибо интернету — это возможно. Получаем информационную открытость. Нет проблемы «ах они у нас все украли». В случае с закрытой разработкой нужна конфиденциальность, ибо придет конкурент и сделает лучше чем у нас. Но дабы продавать basic, надо рассказать систему команд. В случае открытой информации получаем из-за широкого круга участников здоровую конкуренцию. Информация распространяется еще лучше и привлекает еще больше людей.

4. Что делать с копирайтом? Перебивка.

Что из 1-4 следует? Сосредотачивать разработку в единых руках неправильно не из-за того, что человек бывает плохим или хорошим в плане манипуляций копирайтом, а потому что в принципе манипуляция копирайтом не нужна.

Немножко на пальцах поговорим о том, что бизнес, связанный с продажей программ и приравненный к продажам горшков, является читерством.

Представим горшечника. Пошел в овраг накопал глины на 1 горшок, сделал из нее 1 горшок: 1глина + 1 работа = 1 горшок. Продал и получил оплату. Что будет для 100 горшков: 100 глины + 100 горшков = 100 горшков. В итоге горшечник имеет в виду одно и то же что для 1 горшка, что для 100 горшков, даже если сам процесс немного меняется (например начал человека для копаний 100 глины, а работу вообще только он может сделать).

В программах нет особых материальных источников но электричество устраивает в копировании: 1 электричество (дециватт, дециватт/час, джоуль, кофе: нужна энергия) + 1 работа = 1 программа. В итоге для 100 программ ничего не меняется: 100 энергии + 1 работа = 100 программ. Творческий продукт обладает свойством «безущербного» копирования. Если у горшечника вандалы разобьют 99 из 100 горшков, то он лишается 99 глины и 99 работы. Если у программиста 99 копий одной и той же программы сотрут, то ничего не поменяется.

Вам смешно, а у картины идут очень далеко идущие последствия. Схема разработки в бизнесе означает схему горшков. Дядя Вильям плакал, что 4к долларов потратили на ваш basic, а вы тратите только энергию на копирование за деньги. Человечество разрабатывало систему, что 1 объект имеет 1 цену, а объекты всегда имели свойство ущербного копирования.

Является ли Билл Гейтс посланником дьявола, а Майкрософт - его орудием? По сути Гейтс гениальный игрок на рынке (близкий к гениальному, а Джобс гениальный). Почувствовал щель между 1 работ и 100 работ, засунул 1 доллар, а получил 100.

Вопросы: что приносится в жертву при горшечной схеме программирования и как это не приносить в жертву, но продолжать разработку.

Влезаю в тонкую область не из программирования. Попробую разобраться, почему мне не нравится горшечная схема и нравится вторая в плане программирования. На сайте есть ссылка на лекцию 2007 года, где я проводил параллели между свободным сообществом и конфуцианской моралью. Сейчас я отказываюсь о своих слов. Конфуцианство — соблюдение традиций. Чем лучше чтишь, тем ты более великий.

Есть работа, которая называется «Природа и культура», где разбирается понятие парциальной культуры и парциальной личности (по сути партийной, но вызывает определенный ассоциации, потому называют парциальной). С очень давних времен существует организация, где существует отношение, что интересы партии (племени) выше интересов личных. Пионеров учат что рука выше головы, ибо интересы общества выше интереса личности. Но потом до меня стало доходить, что в общем это неестественно для человеческого индивидуума. Ты берешь на веру, что я рассказываю про общество и тот факт что ты считаешь хорошим/плохим есть твои личные проблемы, а хорошее и плохое есть то что выгодно партии. Это парциальная мораль.

Почему я завел об этом разговор. Потому что главное, как мне кажется, с чем приходится бороться (любой тимбилдер вам расскажет, когда вы работаете с корпоративным сектором) - это смена целеполагания. В обществе людям нравится работать, потому что им нравится, что они делают. У них это получается, а окружающие получают от этого пользу. При закрытом образе корпорации мы вынуждены не тех людей брать, которые хотят и могут работать, а тех, кто согласен работать на этих людей за эти условия. Получаем работу ради денег. Я сам не против работать ради денег. Вопрос в том, кого мы будем иметь, если это будет единственным видом мотивации. Есть хороший пример, показывающий и мощь, и недостаток этого подхода — ИНДУСтриальное программирование. Нанимаешь верного прогера, которому все равно, что он будет делать. Такие условные индусы («быдлокодеры» в народе) очень хороши, когда они есть машиники по разработке одноразового кода, и плохо, что он это сам осознает, и значит никакого творческого процесса, и у человека нет поводов радоваться своей работе. Задача - не создать, а получить деньги и забыть про это навсегда. Это происходит из-за способа ведения бизнеса, я не придираюсь.

Какие следствия

Приходит менеджер и говорит: «Твоя прога плохо работает, меняй». А ты считаешь, что он злодей, который заставляет тебя работать еще больше. Люди не пользуются результатами своего труда (отчуждение). Человеку фиолетеово на результат, он для другого в этом процессе. Накодил и «до свидания». Не пришел менеджер и не наругал — отлично, годный код. Иначе поправим. Тогда давайте наймем тестировщиков, которые будут делать то же самое. Но вот изъяны отчуждения.

Механизм начинает работать более эффективно, когда в людях поощрается парциальная мораль (принадлежность к клану). Это есть на любом тимбилдингском мероприятии. Есть известные примеры, когда человек пускал слезу, что так любит компанию, а через год ушел. Мотивация должна быть сторонней: тебя хорошо кормят, у тебя престижная должность и компания, корпоративный дух в тебе и так далее. Поощрение клановости.

В закрытом сообществе (поскольку тебя нету) механизмы информации страшно дороги, и мы не можем взять и уволить начальника, ибо он идиот, потому что все подразделение станет плохоуправляемым. Реформация закрытых сообществ - страшно дорогая штука, и они принимают вид иерархии статической (как назначили так и держится). Причины, по которым эта иерархия держится: ты работаешь хорошо и тебя назначают десятником, и потом ты еще работаешь лучше, и ты так далее становишься начальником отдела. Программируешь ты уже в свободное от работы время и ты уже не кодер, ты взаимодействуешь с людьми. Но ты получаешь в два раза больше чем прогер и потому лишь плачешь и ругаешь эту должность. Цель корпорации — повышенная управляемость.

Моя речь не абсолютно беспристрастна. Хочу сказать, что технологии диктуют мораль. По сути, это нормально - подсидеть человека выше со своего места и получить его место. Это добро с точки зрения корпоративной морали. Вот такие дела.

Google борется с этим вот как: принцип 20 на 80. 80 процентов работаешь на google, 20 процентов работаешь на что хочешь около Google. В итоге, ты получаешь и закрытую разработку со следствиями, и получаешь приятную работу. Климат в Google шикарный, в Яндексе раньше тоже был шикарный. Проблема одна — следствия работы ради денег.

Пробуем изобрести альтернативу.

Произрастает она не из плохих или хороших людей. У нас просто другая технологическая основа, потому у нас есть больше свобод в плане реализации человеческой а не корпоративной морали.

Сначала нарисуем картинку.

У нас есть некоторое ядро (костяк) 1-20 человек. Вокруг ядра нарисуем разработчиков (актив). Ядро принимает стратегические решения. Как-то так получилось, что они вносят очень большой вклад в общее дело. А разработчикам это все не нужно – им нужно быть грамотными, однако можно и в ядро попасть. Есть третий уровень вокруг всего (аура) — пользователи. С точки зрения свободного сообщества это такие пользователи, которые так или иначе вошли во взаимодействие с разработчиками и ядром.

FreeSoftCommunity.png

Актив вдесятеро больше костяка, аура вдесятеро+ больше катива. Получаем широкий круг участников.

Распространение информации получается с помощью интернета: форумы и сайты.

Требования к информационному пространству — связность (пока интернетов не было, закрытая разработка жила и побеждала, а теперь мы можем обеспечивать прохождение информации за секунды и вообще автоматизировать процессы с ПО с помощью гитхаба и т.д.), дисциплина (дисциплина в закрытой разработке плохая, ибо единственное условие - не распространять, а в открытой разработке, когда разработчики по всему миру, дисциплина очень важна, ибо без структуризации разработки никто к вам не придет). Связность - она же доступность.

Вспоминаем дистрибутивы.

Начну с конца.

1. Динамическая иерархия — в свободном сообществе не тот является главным, кого поставили, а того кто отвечает за многое и успешно с этим справляется. Как только он забивает, то главным становится другой. Чем больше ты задач решаешь эффективно тем больше у тебя прав.

2. Сетевая форма социальных отношений. Даже если ты работаешь в корпорации или в ядре Linux, то ты сидишь себе на попе и пишешь драйвер, потом ты отправляешь его в хранилище ядра и приходит человек (отвечающий за эти дрова), который смотрит на твой код, и если он хороший (годный), то он пушит его в то место, где лежит плод его труда - слияние подобных шероховатостей. Именно он это делает, ибо он разбирается в этом лучше, чем ты. Дальше приходят титаны, которые смотрят тысячи строк кода от дядек пониже. А дальше приходит Линус и смотрит на весь код, а дальше матом. Однажды Линус извинялся перед сообществом из-за баги. Не потому что его уволит начальник, а потому что его быстро уволит сообщество автоматически.

3. Свободный вход и выход. Никто тебя не загонял и известными тряпками не выгонял. Когда человек уходит на другу работу, ему говорят: «Спасибо, чувак, ты так много для нас сделал», а не крысой кличут.

С точки зрения сетевой морали лучше ощущается хорошее и плохое. Вот пришел человек, и мы его оцениваем по тому, как он взаимодействует с другими людьми и насколько его труды посвящены решению чужих проблем. Он убил жену — никто не заметил, пока его не посадили. Разработка никак не связана с этим. Так что, если ограничиться пространством того, чем мы занимаемся совместно, то принципы морали, на которых стоит все, очень прозрачны.

Столлман придумал, что, поскольку мы живем в мире лицензирования, мы должны описать, какими свойствами должен обладать программный продукт, чтобы он остался на плаву. После барахтания был выявлен принцип, сводящийся к четырем пунктам.

Человек, который вступает в отношения с каким то СПО, имеет

1. Право использования (законодательство вообще никак не позволяет ограничить)

2. Право изучения (применительно к программе вам должны быть доступны исходные тексты - то самое, от чего огораживаются правообладатели ПО; наша задача - привлечь всех, кто хочет и может заниматься разработкой).

3. Право вносить изменения (улучшения) (опять-таки, довольно много, особенно в 90-е годы, было таких ревнивых программистов, которые говорили: «Вот это моя программа, а значит запускайте, читайте, но не изменяйте, пожалуйста, а то будут думать, что это я написал, а если хотите, то зайдите и поклонитесь, а я разрешу вам» - это недопустимо в открытой разработке).

4. Право распространения измененной версии (улучшенной). Позволяет вам, если вы видите какую-то фишку, упущенную автором - вы можете её поправить и получать деньги. Никто не запрещает. Мы не хотим под парциальную мораль, мы хотим нормальное человеческое сообщество. Качаете программу, меняете её и выходите на рынок. Вы можете однако опасаться, что кто-то выйдет на рынок с теми же изменения. Но тут уж, извините, чистая конкуренция. Однако люди не особо конкуренты, ибо очень много всего разного, и все в своей сфере.

В этой схеме плохо то, что она очень хорошая - рассчитана на идеальное общество. Рассчитано на то, что я сделал что-то и пришел к тебе: «Смотри, какой я крутой, давай делать дальше» - полный коммунизм, а коммунизма не существует. Правила рассчитаны на честную игру, либо на мелкую ЗП тому, кто хочет что-то улучшать. Однако это все делать в условиях копирайта действительно тяжело. Для того, чтобы из этого еще и бизнес делать, нужен 5 пункт.

5. Нет права ухудшать лицензию. А значит нужно, чтобы ваша лицензия содержала все эти 5 пунктов. Могут быть еще разные пункты, но по сути остаются эти. В итоге появляется КОПИЛЕФТ. Потеряли право указывать как копировать. То есть, ваша программа все равно должна быть свободной. Нужно соединить свой бизнес с бизнесом, который у авторов. Нужно делать так, чтобы было выгодно вернуть свои изменения в ядро авторов и получить уже новое ядро.

Это лицензия GNU PUBLIC LICENSE. Копилефт вместо копирайта в пункт 4 выше по лекции.

После этого было продолжение вони вокруг копирайта, когда в данные закладывали тег, где вы соглашаетесь не распространять данные дальше. В итоге как будто купили музыку которую можно послушать 3 раза. Но схема с горшками и прогерами про воровство 99 копий похожа на те обвинения, что ты украл вагон зерна украв мешок.

LecturesCMC/Distro2016/01_FreeSoftware/Conspect (последним исправлял пользователь FrBrGeorge 2016-10-16 17:02:29)