В статье "Profiting from open source - without selling out" рассмотрены восемь бизнес-моделей развития открытых проектов, в различной степени балансирующих между открытостью проекта и возможностью получения прибыли.

1. Развитие проекта в среде единомышленников, проект создается профессионалами для профессионалов и развивается в свободное от работы время с целью оптимизации выполнения собственных задач. Часто такие проекты имеют недостаточно подробную документацию и могут быть излишне усложненными для начинающих пользователей. Способы заработка как правило связаны с построением по запросу клиента или работодателя дополнительных продуктов на базе свободных решений или предоставлении связанных с проектом сервисов, без непосредственной продажи кода.
2. Развитие проекта в среде коллег. От первой модели данный подход отличается в основном тем, что над проектом работают трудоустроенные профессиональные разработчики и из разных компаний, решающие сообща общие для их области деятельности задачи. В качестве примера приводится работа над http-сервером Apache, в создании которого принимают участие разработчики из компаний, заинтересованных в предоставлении качественных услуг хостинга или поддерживающие собственные крупные web-проекты.
3. Финансирование за счет продажи документации. Некоторые проекты намеренно ограничивают доступ к подробной документации, используя в качестве источника дохода продажу документации на проект, или отдельно выставляют на продажу пояснения подробностей работы программной начинки проекта. Например, свободный пакет iText (лицензия AGPL), представляющий коллекцию Java-классов для обработки PDF-файлов, имеет довольно скудную общедоступную документацию, но за отдельные деньги разработчикам предлагается купить книгу.
4. Продажа услуг по оказанию технической поддержки и сопровождению решений на базе СПО. Кроме непосредственно организации подписки на тех. поддержку по телефону или email, к данной категории можно отнести услуги по оказание помощи в установке программ и модель, основанную на доработке определенных свободных продуктов по запросу заказчика. Например, проект MariaDB готов произвести изменения или добавить дополнительную функциональность в MySQL и обеспечить дальнейшее сопровождение созданных улучшений. Следует отметить, что продажа расширенных коммерческих версий, основанных на открытой кодовой базе, например компания SpringSources (подразделение Vmware) продающая tcServer на базе свободного Apache Tomcat или компания Red Hat с Red Hat Network, не подпадают в данную категорию.
5. Продажа оборудования. Некоторые компании развивают в виде свободных проектов начинку для своего оборудования, например, таким образом поступают некоторые производители серверов, маршрутизаторов, медиа-центров, нетбуков, телефонов. В частности к такой модели склонилось в свое время компания Sun Microsystems.
6. Продажа результата использования свободного ПО. Яркий пример данной категории компания Google, вся инфраструктура которой построена на базе СПО, но зарабатывает компания за счет показа рекламы пользователям на созданных при использовании СПО сервисах. В данную категорию попадают также компании, продвигающие системы облачных вычислений, продажи ПО как сервиса и даже обычные web-сайты, работа которых основана на открытом ПО.
7. Продажа лицензий для коммерческого использования. Несмотря на то, что большинство свободных лицензий не делают различий между коммерческим и не коммерческим использованием программ, некоторые производители строят свой бизнес на продаже аналогичных по функциональности версий своих открытых продуктов для коммерческого использования, позиционируя бесплатную версию только для некоммерческого применения. Такие компании утверждают, что приобретение коммерческой лицензии избавит пользователя от каких-либо правовых забот и даст возможность получить техническую поддержку продукта.
8. Продажа расширенных коммерческий версий продуктов. Главное отличие от предыдущей модели в том, что коммерческая версия отличается наличием дополнительных возможностей, которые недоступны пользователям свободно-распространяемых версий - часть кода в таких проектах остается закрытой. Иногда улучшения просто не включается в community-релизы, но присутствует в репозиториях исходных текстов, что часто приводит к появлению независимых сборок.