Краудсорсинг как город

По статье Rick Kazman, Hong-Mei Chen The metropolis model a new logic for development of crowdsourced systems. Communications of the ACM Volume 52, Number 7 (2009), Pages 76-84 В статье дан подробный разбор характеристик или компетенций, которыми должны обладать краудсорсинговая система. Компетенции тут относятся не к отдельному человеку а ко всей системе). Авторы пытаются использовать метафору города (или метрополии) для описания принципов построения и поддержания краудсорсинговых систем. Примеры краудсорсинговой модели развития

1. OSS - open software systems - системы с открытым кодом
2. CBSS - community-based service systems - системы сервисов, основанные на сообществах

Примеры такого взаимодействия масса находятся повсеместно.

Характеристики краудсорсинговых систем:

1. Открытая команда - обычно представляется, что децентрализованные открытые команды без управления не могут быть успешны. Но, они успешны - примеры Linux, Apache, WikiPedia - все это примеры систем, где жесткого управления и единоначалия нет.
2. Мэшапность - смешиваемость. ГуглаКарты сразу были мешапом. В вики сила и состоит не в отдельных статьях, а в том, что статьи ссылаются и используются в других статьях. В открытых проектах зачастую решение находится в силу объединения и композиции нескольких программ.
3. Конфликтующие и неизвестные требования - здесь обычная практика, что требования и программам и к вики страницам постоянно изменяются - эти изменения формируются членами сообщества. Эти требования никогда до конца не известны и часто противоречивы, как и пожелания жителей города. В некоторых сообществах для разрешения конфликтов решения принимают модераторы или есть институт голосования. В некоторых сообществах различные требования просто терпят.
4. Постоянная эволюция. Поскольку требования постоянно растут и меняются, краудсорсинговая система never done - никогда не бывает закончена. Она постоянно бета.
5. Все внимание функционировании - система должна быть постоянно открыта для участия. Это такое главное свойство или главная компетентность таки систем как Amazon, Wikipedia, FaceBook, Google - ни в коем случае не выключать
6. Достаточная правильность - все не может быть сделано полностью и целиком правильно. В таких системах признается достаточная правильность. Например, Википедия никогда не объяет себя полной и безошибочной, хотя эта стратегия позволяет ей быть сравнимой по точности с Encyclopedia Britanica
7. Нестабильные ресурсы
8. Эмерджентное поведение

Логика системы

1. Ядро - архитекторы и владельцы системы, принимающие решение о направлении развития
2. Окраина - разработчики, созидатели-потребители контента
3. Массы - зрители, потребители, конечные пользователи

ОSS / CBSS отличаются по возможностям проникновения и перехода. При разработке системы с открытым кодом зритель и пользователь можт перейти в разряд разработчиков и архитекторов. В случае CBSS эти переходы практически невозможны.

Принципы

1. Вовлечение масс и уравнительное управление egalitarian management открытым командами. Город без людей - жителей и гостей - останется пуст. Управление массами, коллективным разумом толпы - главное правило модели краудсорсинага. Жители должны быть вовлечены в совместное создание ценностей. На такое вовлечение должны быть направлены все инфраструктуры города. Толпо-управление crowd-management - включает поощрение, построение иерархии жителей в зависимости от их вклада, защиту жителей от вредоносных и опасных пришельцев. Основная задача управления массами - уменьшение стоимости и повышение качества производимого продукта. При этом такое управление в открытых системах никогда не выстраивается сверху-вниз. Лидеры проекта привлекают, мотивируют и координируют действия команд. Часто в таких системах нет утвержденного сверху плана и списка работ. Есть градации участников, когда они становятся полноправными членами команды и получают статус разработчиков или редакторов. В вики никто не может административно снизить статус участника.
2. Разные требования к возможностям системы. Сервисы и возможности ядра системы, например, движок медиавики или ядро Линукса. Материалы периферии, создаваемые жителями города - приложения, шаблоны, статьи вики. При этом требования к службам ядра и службам периферии совершенно не совпадают
3. Раздвоенная архитектура системы - принципиально различные возможности для центра и окраины
4. Фрагментарное внедрение - поскольку требования и сервисы для центра и периферии заметно отличаются, ввод новых сервисов и новых строений протекает по разному. Краудсорсинг происходит только на периферии, где жители заняты созданием своих собственных объектов по своим собственным стандартам.
5. Различное и распределенное тестирование частей. Например, сам движок медиавики мал и хорошо оттестирован. При этом на базе движка крутится масса страниц, которые проверены относительно.
6. Различные типы поддержки. Центр должен быть стабилен, доступен и совместим с предыдущими версиями. Периферия, как правило, постоянно изменяется.
7. Постоянная и повсеместная доступность и работоспособность системы.