Приглашаем к участию в проекте «300 ИнтелШкол-2011»

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

Материал из Letopisi.Ru — «Время вернуться домой»

Перейти к: навигация, поиск

По статье 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. Постоянная и повсеместная доступность и работоспособность системы.
Инструменты
организаторы проекта
Компания ТрансТелеКом
Корпорация Intel
PH International
www.Iteach.ru
партнер проекта

Почта России

Классный Журнал

www.centersot.org


наши друзья



Жужа. Ежедневная сказка
мы поддерживаем

Образование



Установите «Letopisi NewsReader» на свой компьютер