О разработке открытого ПО написано достаточно, и как считает Michael DeHaan многое из написанного дает превратное представление о том, что происходит в действительности. В своем блоге автор на основе длительного опыта работы в сообществе Fedora Linux пытается систематизировать наиболее часто встречающиеся заблуждения, стараясь при этом разобраться в причинах их возникновения.

• Заблуждение 1: Начните проект – остальные к вам присоединятся. На самом деле, если проект нишевый и затрагивает решение специфической проблемы, то вероятность приобретения большой пользовательской базы очень мала. Добавив к этому, что из 50 или 500 пользователей только один станет вашим помощником, нужно здраво взвешивать силы и первое время рассчитывать только на себя. Далее нужно пытаться заинтересовать своими идеями других, найти единомышленников и быть как можно более контактным и открытым. Создание сообщества типа LUG станет неплохим началом для дальнейшего роста.
• Заблуждение 2: Сообщество поможет реализовать сложную функцию Х. Скорее всего вам помогут реализовать функциональность, которая не требует больших затрат времени и приносит легкий и быстрый результат. Поэтому создавайте проект как можно более модульным, чтобы добавление функционала не ставило условием изучение структуры дополнительных несвязанных компонентов.
• Заблуждение 3: Четкое понимание направления развития проекта. Весьма вероятно, что другие участники будут не менее идейными, чем вы, причем все концепции будут иметь множество положительных черт и идти в разрез одна с другой. Очевидно, что нельзя идти во взаимопротивоположных направлениях, и поддерживать несколько параллельных веток – тоже не вариант. Вывод: умейте соглашаться, идти на компромиссы, но не забывайте при этом ради чего вы все это начали.
• Заблуждение 4: Новшества - это бесплатно. На самом деле любая работа подразумевает затраты на начальное тестирование и последующее вечное поддержание работоспособности кода. В этой связи нужно весьма осторожно относиться к добавлению новой функциональности: если ваш коллега разочаруется в проекте, то всю ношу по поддержке его кода вам придется взять на себя. В результате, либо частично рабочий проект, либо десятки потраченных часов на выяснение причины неработоспособности.
• Заблуждение 5: Отлаженная коммерческая модель. Верно, но только для проектов, где действительно требуется профессиональные сервис и консультации. В противном случае очень маловероятно, что кто-то станет вам платить.
• Заблуждение 6: Все умеют читать чужой код. Для того, чтобы это было правдой, код должен быть простым, хорошо задокументированным и без ненужной «магии».
• Заблуждение 7: Полная документация. Вообще, документирование функциональной базы и последующих новшеств выглядит достаточно безынтересно. Тем не менее, упоминание о нововведениях где-либо помимо исходного кода, это необходимость, которой нельзя пренебрегать. И если среди сообщества не находится волонтеров, то автору самому придется заняться этим.
• Заблуждение 8: Все пользователи приложения Х станут вносить свой вклад в проект. Это не так. Необходимо регулярно напоминать о том, что автор не супермен и все сам делать не может. Чем больше вы просите о помощи, тем больше вероятность, что вам станут помогать.
• Заблуждение 9: Разработчики — это как сослуживцы на работе. Часто можно наблюдать такую картину, когда кто-то выкладывает сразу серию исправлений, а затем на несколько месяцев исчезает. Это нормально, так устроена система. Причиной этому может быть, например, работодатель, препятствующий работе над СПО. У разработчиков также могут быть свои первоочередные интересы. Посоветовать здесь что-либо невозможно, разве что попытаться убедить такого человека «заходить» почаще.

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