Понятно, что откаты нужно отдельно программировать. Минимально, что можно сделать автоматически, это запустить процесс с прежней точки и попросить пользователей подтвердить свое прежнее решение.
Не совсем понятно, что делать, если кто-то не подтвердит свое прежнее решение.
Впрочем, и с точками отката тоже не все ясно — ошибочный процесс мог поменять что-то вне своих локальных переменных — как это откатить?
Для таких случаев было введено понятие «Компенсация». Если на этапе разработки бизнес-процесса для узла-действия известно, что после выполнения этого действия может быть откат, то с ним связывается цепочка действий, которая должна быть выполнена в случае отката (В нотации BPMN соединяется специальной пунктирной линией).
Например, если бизнес-процесс связан с оформлением турпоездки, то при изменении клиентом уже частично оформленного варианта может потребоваться отменить бронирование гостиницы, сдать билеты и т.п.
Но было бы интересно увидеть конкретные примеры с вашей стороны. В реальном решении, на сколько сложны бизнес-процессы?
Я стараюсь использовать простые процессы. Часто вместо большого и сложного бизнес-процесса можно сделать набор относительно простых процессов, взаимодействующих друг с другом через данные или сообщения. Наиболее сложные процессы, которые я разрабатывал, содержали порядка ста элементов, разнесенных по четырем уровням вложенности подпроцессов. На одной схеме «промежуточного» процесса было два-три вызова подпроцессов.
1) Реальный процесс получался из десятков задач. Диаграмма занимала несколько экранов, ходила петлями и змейками — жуть.
Обычно путем декомпозиции, вынося участки схемы в подпроцессы, можно существенно улучшить понимаемость схем процессов. Если, например, бизнес-процесс состоит из 7 шагов, каждый из которых является подпроцессом, то на диаграмме процесса будет всего 7 элементов. Однако, при клике на любой из этих элементов, BPMS откроет схему этого подпроцесса. В случае четырех уровней вложенности для подпроцессов из 7 элементов, 4-ый уровень будет содержать 2401 задачу, при этом каждая схема будет состоять только из 7 элементов.
Для реальных бизнес-процессов, конечно, все не так просто. При декомпозиции надо учитывать не только количество элементов, но и бизнес-логику процесса. Но, в целом, путем декомпозиции понимаемость схем можно существенно улучшить.
2) Все проблемы с переиспользованием и версионированием, о которых в коментах уже говорили.
Эти проблемы пока не решены. Приходится иногда использовать дублирование, которого, конечно, хотелось бы избежать.
3) Если на каком-то шаге возникала программная ошибка, то процесс падал и без участия программиста не оживал. Ну как пример: пользователь вбил адрес в каком-то новом формате, о котором аналитики не подумали. Код свалился с ошибкой, процесс остановился — ждем программиста. В результате пара человек просто сидела на поддержке 100% времени, разбирая целыми днями эти ошибки.
Если такая ошибка связана с неправильно введенными данными, то многие BPMS позволяют исправить ее без программиста. — Администратор системы может изменить значение переменной конкретного экземпляра бизнес-процесса, при этом в историю действий с экземпляром процесса будет добавлена соответствующая запись.
Но самый большой гвоздь в крышку гроба был забит, когда пришел очередной заказчик, и выдвинул такие требования:
— Хочу, чтобы некоторые задачи в некотором конкретном процессе можно было отменять.
Для таких действий предусмотрен элемент «Бизнес-Исключение»
— А еще некоторые задачи мне хочется менять местами — опять же, в конкретном инстансе конкретного процесса. Ну вот попался такой особый случай — менеджер должен иметь возможность кое-что перепланировать
— А еще бывает, что менеджеру хочется в некотором конкретном случае добавить несколько дополнительных задач.
Это классическому процессному подходу не очень хорошо соответствует. Все же процессный подход появился как аналог конвейера. Во многих BPMS сделать такие изменения бизнес-процессов можно, но делать их будет неудобно и выглядеть они будут неестественно.
Для таких операций был придуман Adaptive Case Management, но он отличается от традиционного процессного подхода.
Самое ужасное, что эти требования — нормальные, если речь идет о длительном процессе…
В случае длительных процессов есть методы перевода экземпляров бизнес-процесса на новую версию определения бизнес-процесса. При этом в новый экземпляр бизнес-процесса переносятся данные и точки управления из старого экземпляра. Если версии не очень сильно отличаются, такое преобразование тоже можно сделать без участия программиста.
Представьте, что вы автоматизируете бизнес строительной компании, которая строит коттеджи по уникальным проектам. Для каждого участка строительства надо предусмотреть разное количество задач. Если эти задачи еще и делаются в параллели, то средствами BPMS это не решается никак.
Процессный подход не предназначен для решения таких задач. Для таких задач надо применять управление проектами. Для этого разработан другой класс программного обеспечения. Бизнес-процессы предполагают многократное выполнение одних и тех же цепочек действий. Проект предполагает однократное выполнение, контроль ресурсов, возможность существенного отличия фактических действий от плановых и т.п.
В проектном подходе можно использовать процессное управление как вспомогательное направление для автоматизации использующихся во многих проектах одних и тех же рутинных процедур. Но основным в этом случае все равно должно быть проектное управление.
В итоге сейчас в нашей компании есть средство, которому эта задача «по зубам». Я не знаю, до какой степени об этом можно рассказывать. В википедии навскидку похожего не нашел. Скажу только, что конкретный вид процесса каждый раз генерируется автоматически.
Если кому-то интересно — попробую сделать статью об этом и опубликовать через корпоративный блог.
Я смотрю на это гораздо более оптимистично. За 15 лет ситуация в данной области все-таки заметно улучшилась. Начиналось все с проприетарных систем, а сейчас уже есть OpenSource системы, которые можно реально использовать на предприятиях.
Проблема BPMS в том, что разработчики процессного подхода пытаются повторить путь разработчиков информационных систем. Т.е. основателям BPMS нужно было бы изначально изучить Computer Science и уже затем бизнес.
Это — не простой вопрос. Можно придумать разные интересные и полезные технологии, которые никто не будет использовать в силу сложности их освоения. Данная технология предназначена для управленцев и разрабатывали ее тоже управленцы (менеджеры), поэтому она соответствует их мышлению и менеджеры, хотя и с трудом, готовы ей пользоваться. Похоже, что таким не «прямым» путем, постепенно улучшая и, с течением времени, заимствуя решения из Computer Science, можно широко внедрить этот подход в практику и сделать реально эффективным.
А если изначально сделать все «как надо», то менеджеры не поймут, изучать-использовать откажутся и все это будет не востребовано.
Слишком много народу паразитирует на этих системах.
Да. Это, к сожалению, имеет место.
BPMN действительно мало применимы, пока. Все красивые интерфейсы как правило на работают в стоке и требуют длительного и мучительного допиливания. То что красиво на картинке и в презентации превращается в ад, для разработчиков.
Технология эта пока не совершенна. Работать в рамках этой технологии непривычно и тяжело как специалистам предметной области, так и программистам. Но эффект от ее применения есть. В ее основе лежит здравый подход. Не страшно, что пока «шелухи» разной вокруг нее очень много. С течением времени все это должно «рассосаться», текущие проблемы будут решены, технология должна стать широко используемой в бизнесе.
Да. Надо стараться, чтобы схема любого подпроцесса свободно умещалась на экране компьютера. То есть, если элементов много и что-то не умещается, надо какие-то части схемы переносить в подпроцессы.
Процессный подход — это не только графическая нотация. Для исполнимых бизнес-процессов нужно еще определить механизм назначения исполнителей на роли, задать структуры данных и т.д.
BPMN — не единственная возможная нотация, применяющаяся в процессном подходе. Например, я иногда использую UML (Activity Diagramm), есть и другие «процессные» нотации. Но BPMN «продвигает» очень активная команда. Вполне возможно, что чисто «маркетинговыми» приемами остальные нотации будут вытеснены ей на периферию предметной области.
ещё не разу не встретился бизнес-аналитик который описывая какую-нибудь ситуацию не приводил бы аналогию с мерседесом :)
Я при объяснении процессного подхода часто привожу аналогию с велосипедом :)
представленная схема не сколько сложна, сколько плохо описана и перегружена, отчего неочевидна и кажется сложной
Данную схему имеет смысл разбить на несколько подпроцессов (т.е. на несколько вложенных друг в друга схем). Тогда восприниматься она будет легче. Я не стал этого делать, т.к. при наличии подпроцессов трудно все объяснить или показать на одном скриншоте.
Но, в любом случае, схемы алгоритмов принятия решений в этом бизнес-процессе достаточно сложные по сравнению со схемами обычных бизнес-процессов. Эта сложность объективна, она останется даже, если разбить все на подпроцессы.
Языки описания бизнес-процессов пока все-таки не позиционируются как полноценные языки программирования. К ним нельзя предъявлять такие высокие требования. Но существует ли какая-то другая технология, не имеющая описанных выше сложностей, позволяющая специалисту предметной области, не знакомому с программированием, быстро и гибко модифицировать бизнес-логику и структуру приложения?
А такая возможность может существенно улучшать финансовые результаты автоматизируемого предприятия.
Многие широко используемые в настоящее время технологии сначала были несовершенны. Главное, чтобы здравая идея в технологии была. В новой технологии сложности обязательно будут. Но, если идея хорошая, с течением времени сложности будут преодолены.
процессы это плохой вид повторно используемого компонента
С повторным использованием бывают сложности. Оно возможно, в частности, подпроцессы стараются разрабатывать так, чтобы они могли быть использованы в большом количестве процессов. В какой-то степени это напоминает процедурное программирование с повторно используемыми процедурами. А аналог объектной модели в бизнес-процессы пока еще не получилось интегрировать. Это приводит к необходимости дублировать часть функциональности в разных бизнес-процессах.
Но, несмотря на определенные сложности, процессный подход может принести качественные преимущества бизнесу. Например, специалисту, хорошо разбирающемуся в том, как при помощи изменения тарифных планов и предоставления скидок разным категориям клиентов повышать продажи, это дает возможность очень быстро управлять продажами, немедленно реагируя на изменения на рынке при помощи оперативной модификации находящиеся в эксплуатации бизнес-процессов. — Не надо каждый раз «дергать» программиста, можно самостоятельно видоизменить схему и параметры. К программисту в этом случае надо обращаться редко, для создания новых элементов бизнес-процессов.
Можете привести примеры кейсов из вашей практики, процессная реализация которых была неудачной?
созданные для аналитиков системы для рисования диаграмм программистам как правило категорически неудобны, а без программистов все это не работает
В данном случае возможно взаимодействие аналитика с программистом. Это проверено на практике:
Аналитик «заказывает» у программиста нужные ему компоненты- графические элементы форм заданий, коннекторы к внешним хранилищам и т.п. — Программист реализует их и устанавливает в палитру среды разработки. После этого аналитик использует их в своих бизнес-процессах.
в реальной жизни автоматизации хорошо поддаются только довольно примитивные (с точки зрения человека) процессы
Большинство автоматизируемых бизнес-процессов, действительно, простые. Однако, это не мешает получению финансового эффекта. На конвейере часто тоже простые операции выполняются, а финансовый эффект от конвейера — значительный.
Бинарными отношениями выражается как связанное с бизнес-процессами подмножество организационной структуры предприятия, так и не имеющие прямое отношение к организационной структуре связи между сотрудниками, влияющие на назначение исполнителей заданий на роли бизнес-процессов.
Если в организации есть компьютерная система, автоматизирующая работу с оргструктурой, то решение на основе бинарных отношений действительно будет дублировать часть данных этой системы. Однако, это будет небольшая часть данных, ее можно рассматривать как кеш некоторых элементов оргструктуры в системе управления бизнес-процессами.
1. Назначение ролей может вообще не относиться к оргструктуре. Например, сотрудник отдела кадров, ответственный за адаптацию принятого на работу сотрудника. — У каждого сотрудника, находящегося на испытательном сроке, может быть свой куратор из отдела кадров, при этом он не является начальником сотрудника, а отдел, в котором работает сотрудник, организационно независим от отдела кадров.
2. Организационная структура предприятия — это достаточно сложная сущность. Есть разные типы оргструктур: линейная, дивизионная, штабная… Позиции сотрудников могут быть постоянными или временными. Договора сотрудников могут быть штатными, гражданско-правовыми и т.д. Полномочия многих работников определяются наличием соответствующих доверенностей. Есть еще документы, связанные с материальной ответственностью, документы (сертификаты/дипломы) необходимые для допуска к выполнению определенных работ (назначения на должность). Сложность компьютерной системы, автоматизирующей работу с оргструктурой среднего предприятия сравнима со сложностью самой системы управления бизнес-процессами.
В случае использования бинарных отношений все это не требуется «затягивать» внутрь системы. Можно задать только необходимые для назначения на роли связи между сотрудниками предприятия.
Необходимость того, чтобы кто-то заплатил первым, сильно затрудняет кооперацию. Эти инвестиции могут не иметь финансовой отдачи, поэтому, во многих случаях, на платной основе кооперации не возникнет, а при бесплатном вложении своего труда разными участниками она может быть.
Например, проекты, аналогичные wikipedia.org, теоретически можно было бы развивать и на платной основе, но в реальности так и не появилось «платного» аналога такого масштаба
> Вы, видимо, не в курсе того, что в «нормальном» процессе разработки «придумывают» не программиств, а аналитики.
Конечно. Однако в «нормальном» процессе разработки они это делают не бесплатно, а получают за это зарплату.
> И нет, вы так и не объяснили, почему в пропьетарном ПО невозможна кооперация авторов идей (заказчиков и аналитиков) и разработчиков.
Она возможна, но, как правило, носит коммерческий характер. В этом случае кому-то все-равно придется заплатить (по крайней мере, конечному пользователю софта).
В свободных проектах достаточно широко распространено такое понятие, как donation (добровольное пожертвование). Часто это выполняемые бесплатно работы по локализации, документированию, или программированию. Те, кто таким образом помогает свободному проекту, могут получать от этого личную пользу, например, локализовать приложение на «свой» язык, а потом пользоваться локализацией в следующих версиях
Передача интересной идеи свободному проекту также может быть видом такого добровольного пожертвования, а человек, который это сделал, тоже может получить от этого личную пользу. В этом случае это будет «чистая» кооперация — всем будет полезно и никто не будет никому платить.
Имеется в виду идея реализации механизма замещения пользователей на основе упорядоченного набора правил замещения, «привязанного» к пользователю?
Это пример «небольшой» оригинальной идеи, которая была реализована в свободном ПО. — В других аналогичных системах такого решения нет. Эта идея не очень сложна в реализации, но самим программистам трудно придумать такое решение, т.к. они по-другому думают, заняты в значительной степени вопросами программных решений.
В случае интересной оригинальной идеи автор идеи может захотеть распространить ее бесплатно, или за символическую плату. Программист тоже может быть готов реализовать интересную идею бесплатно, или за небольшие деньги. Однако только СПО позволяет свободно распросранять результат их совместных усилий.
Если они даже бесплатно реализуют такое решение в проприетарном ПО, то конечным пользователям все равно придется покупать инструмент для того, чтобы пользоваться тем, что было бесплатно сделано.
В обычной заказной разработке другой принцип. Либо Заказчик платит программистам за реализацию своих идей и получает права собственности на разработанный софт, либо программистская компания нанимает консультанта, которому платит деньги.
В обоих случаях мало вероятно, чтобы разработанное таким образом ПО было бесплатным и доступным всем желающим.
Не совсем понятно, что делать, если кто-то не подтвердит свое прежнее решение.
Для таких случаев было введено понятие «Компенсация». Если на этапе разработки бизнес-процесса для узла-действия известно, что после выполнения этого действия может быть откат, то с ним связывается цепочка действий, которая должна быть выполнена в случае отката (В нотации BPMN соединяется специальной пунктирной линией).
Например, если бизнес-процесс связан с оформлением турпоездки, то при изменении клиентом уже частично оформленного варианта может потребоваться отменить бронирование гостиницы, сдать билеты и т.п.
Я стараюсь использовать простые процессы. Часто вместо большого и сложного бизнес-процесса можно сделать набор относительно простых процессов, взаимодействующих друг с другом через данные или сообщения. Наиболее сложные процессы, которые я разрабатывал, содержали порядка ста элементов, разнесенных по четырем уровням вложенности подпроцессов. На одной схеме «промежуточного» процесса было два-три вызова подпроцессов.
Обычно путем декомпозиции, вынося участки схемы в подпроцессы, можно существенно улучшить понимаемость схем процессов. Если, например, бизнес-процесс состоит из 7 шагов, каждый из которых является подпроцессом, то на диаграмме процесса будет всего 7 элементов. Однако, при клике на любой из этих элементов, BPMS откроет схему этого подпроцесса. В случае четырех уровней вложенности для подпроцессов из 7 элементов, 4-ый уровень будет содержать 2401 задачу, при этом каждая схема будет состоять только из 7 элементов.
Для реальных бизнес-процессов, конечно, все не так просто. При декомпозиции надо учитывать не только количество элементов, но и бизнес-логику процесса. Но, в целом, путем декомпозиции понимаемость схем можно существенно улучшить.
Эти проблемы пока не решены. Приходится иногда использовать дублирование, которого, конечно, хотелось бы избежать.
Если такая ошибка связана с неправильно введенными данными, то многие BPMS позволяют исправить ее без программиста. — Администратор системы может изменить значение переменной конкретного экземпляра бизнес-процесса, при этом в историю действий с экземпляром процесса будет добавлена соответствующая запись.
Для таких действий предусмотрен элемент «Бизнес-Исключение»
Это классическому процессному подходу не очень хорошо соответствует. Все же процессный подход появился как аналог конвейера. Во многих BPMS сделать такие изменения бизнес-процессов можно, но делать их будет неудобно и выглядеть они будут неестественно.
Для таких операций был придуман Adaptive Case Management, но он отличается от традиционного процессного подхода.
В случае длительных процессов есть методы перевода экземпляров бизнес-процесса на новую версию определения бизнес-процесса. При этом в новый экземпляр бизнес-процесса переносятся данные и точки управления из старого экземпляра. Если версии не очень сильно отличаются, такое преобразование тоже можно сделать без участия программиста.
Процессный подход не предназначен для решения таких задач. Для таких задач надо применять управление проектами. Для этого разработан другой класс программного обеспечения. Бизнес-процессы предполагают многократное выполнение одних и тех же цепочек действий. Проект предполагает однократное выполнение, контроль ресурсов, возможность существенного отличия фактических действий от плановых и т.п.
В проектном подходе можно использовать процессное управление как вспомогательное направление для автоматизации использующихся во многих проектах одних и тех же рутинных процедур. Но основным в этом случае все равно должно быть проектное управление.
Интересно. Поместите ссылку на блог.
Это — не простой вопрос. Можно придумать разные интересные и полезные технологии, которые никто не будет использовать в силу сложности их освоения. Данная технология предназначена для управленцев и разрабатывали ее тоже управленцы (менеджеры), поэтому она соответствует их мышлению и менеджеры, хотя и с трудом, готовы ей пользоваться. Похоже, что таким не «прямым» путем, постепенно улучшая и, с течением времени, заимствуя решения из Computer Science, можно широко внедрить этот подход в практику и сделать реально эффективным.
А если изначально сделать все «как надо», то менеджеры не поймут, изучать-использовать откажутся и все это будет не востребовано.
Да. Это, к сожалению, имеет место.
Технология эта пока не совершенна. Работать в рамках этой технологии непривычно и тяжело как специалистам предметной области, так и программистам. Но эффект от ее применения есть. В ее основе лежит здравый подход. Не страшно, что пока «шелухи» разной вокруг нее очень много. С течением времени все это должно «рассосаться», текущие проблемы будут решены, технология должна стать широко используемой в бизнесе.
BPMN — не единственная возможная нотация, применяющаяся в процессном подходе. Например, я иногда использую UML (Activity Diagramm), есть и другие «процессные» нотации. Но BPMN «продвигает» очень активная команда. Вполне возможно, что чисто «маркетинговыми» приемами остальные нотации будут вытеснены ей на периферию предметной области.
Я при объяснении процессного подхода часто привожу аналогию с велосипедом :)
Данную схему имеет смысл разбить на несколько подпроцессов (т.е. на несколько вложенных друг в друга схем). Тогда восприниматься она будет легче. Я не стал этого делать, т.к. при наличии подпроцессов трудно все объяснить или показать на одном скриншоте.
Но, в любом случае, схемы алгоритмов принятия решений в этом бизнес-процессе достаточно сложные по сравнению со схемами обычных бизнес-процессов. Эта сложность объективна, она останется даже, если разбить все на подпроцессы.
А такая возможность может существенно улучшать финансовые результаты автоматизируемого предприятия.
Многие широко используемые в настоящее время технологии сначала были несовершенны. Главное, чтобы здравая идея в технологии была. В новой технологии сложности обязательно будут. Но, если идея хорошая, с течением времени сложности будут преодолены.
С повторным использованием бывают сложности. Оно возможно, в частности, подпроцессы стараются разрабатывать так, чтобы они могли быть использованы в большом количестве процессов. В какой-то степени это напоминает процедурное программирование с повторно используемыми процедурами. А аналог объектной модели в бизнес-процессы пока еще не получилось интегрировать. Это приводит к необходимости дублировать часть функциональности в разных бизнес-процессах.
Но, несмотря на определенные сложности, процессный подход может принести качественные преимущества бизнесу. Например, специалисту, хорошо разбирающемуся в том, как при помощи изменения тарифных планов и предоставления скидок разным категориям клиентов повышать продажи, это дает возможность очень быстро управлять продажами, немедленно реагируя на изменения на рынке при помощи оперативной модификации находящиеся в эксплуатации бизнес-процессов. — Не надо каждый раз «дергать» программиста, можно самостоятельно видоизменить схему и параметры. К программисту в этом случае надо обращаться редко, для создания новых элементов бизнес-процессов.
Можете привести примеры кейсов из вашей практики, процессная реализация которых была неудачной?
В данном случае возможно взаимодействие аналитика с программистом. Это проверено на практике:
Аналитик «заказывает» у программиста нужные ему компоненты- графические элементы форм заданий, коннекторы к внешним хранилищам и т.п. — Программист реализует их и устанавливает в палитру среды разработки. После этого аналитик использует их в своих бизнес-процессах.
Большинство автоматизируемых бизнес-процессов, действительно, простые. Однако, это не мешает получению финансового эффекта. На конвейере часто тоже простые операции выполняются, а финансовый эффект от конвейера — значительный.
Вообще бывают, хотя их и не много,
Если в организации есть компьютерная система, автоматизирующая работу с оргструктурой, то решение на основе бинарных отношений действительно будет дублировать часть данных этой системы. Однако, это будет небольшая часть данных, ее можно рассматривать как кеш некоторых элементов оргструктуры в системе управления бизнес-процессами.
1. Назначение ролей может вообще не относиться к оргструктуре. Например, сотрудник отдела кадров, ответственный за адаптацию принятого на работу сотрудника. — У каждого сотрудника, находящегося на испытательном сроке, может быть свой куратор из отдела кадров, при этом он не является начальником сотрудника, а отдел, в котором работает сотрудник, организационно независим от отдела кадров.
2. Организационная структура предприятия — это достаточно сложная сущность. Есть разные типы оргструктур: линейная, дивизионная, штабная… Позиции сотрудников могут быть постоянными или временными. Договора сотрудников могут быть штатными, гражданско-правовыми и т.д. Полномочия многих работников определяются наличием соответствующих доверенностей. Есть еще документы, связанные с материальной ответственностью, документы (сертификаты/дипломы) необходимые для допуска к выполнению определенных работ (назначения на должность). Сложность компьютерной системы, автоматизирующей работу с оргструктурой среднего предприятия сравнима со сложностью самой системы управления бизнес-процессами.
В случае использования бинарных отношений все это не требуется «затягивать» внутрь системы. Можно задать только необходимые для назначения на роли связи между сотрудниками предприятия.
Например, проекты, аналогичные wikipedia.org, теоретически можно было бы развивать и на платной основе, но в реальности так и не появилось «платного» аналога такого масштаба
Конечно. Однако в «нормальном» процессе разработки они это делают не бесплатно, а получают за это зарплату.
> И нет, вы так и не объяснили, почему в пропьетарном ПО невозможна кооперация авторов идей (заказчиков и аналитиков) и разработчиков.
Она возможна, но, как правило, носит коммерческий характер. В этом случае кому-то все-равно придется заплатить (по крайней мере, конечному пользователю софта).
В свободных проектах достаточно широко распространено такое понятие, как donation (добровольное пожертвование). Часто это выполняемые бесплатно работы по локализации, документированию, или программированию. Те, кто таким образом помогает свободному проекту, могут получать от этого личную пользу, например, локализовать приложение на «свой» язык, а потом пользоваться локализацией в следующих версиях
Передача интересной идеи свободному проекту также может быть видом такого добровольного пожертвования, а человек, который это сделал, тоже может получить от этого личную пользу. В этом случае это будет «чистая» кооперация — всем будет полезно и никто не будет никому платить.
Это пример «небольшой» оригинальной идеи, которая была реализована в свободном ПО. — В других аналогичных системах такого решения нет. Эта идея не очень сложна в реализации, но самим программистам трудно придумать такое решение, т.к. они по-другому думают, заняты в значительной степени вопросами программных решений.
В случае интересной оригинальной идеи автор идеи может захотеть распространить ее бесплатно, или за символическую плату. Программист тоже может быть готов реализовать интересную идею бесплатно, или за небольшие деньги. Однако только СПО позволяет свободно распросранять результат их совместных усилий.
Если они даже бесплатно реализуют такое решение в проприетарном ПО, то конечным пользователям все равно придется покупать инструмент для того, чтобы пользоваться тем, что было бесплатно сделано.
В обоих случаях мало вероятно, чтобы разработанное таким образом ПО было бесплатным и доступным всем желающим.