Софтуер с отворен код
Софтуер с отворен код (СОК, ) е софтуер, за който притежателят на авторските права на изходния код предоставя правата за обучение, промяна и разпространение на софтуера на всекиго и за всякакви цели (или накратко софтуер с лиценз за отворен код). Софтуерът с отворен код може да бъде разработван и по кооперативен публичен начин. Софтуерът с отворен код е най-честият пример за разработване с отворен код и често бива сравнен с потребителски генерирано съдържание (техническо определение) или движения с отворено съдържание (законово определение). 

Моделът отворен код или съвместното разработване от много независими източници генерира много по-разнообразен обхват на гледна точка на дизайна и структурата на кода, отколкото разработването му само от една фирма, което позволява оцеляването му за дълъг период от време. В доклад на Standish Group (от 2008 г.) се казва, че възприемането и използването на модела на софтуер с отворен код е довело до спестявания в размер на 60 милиарда долара на година на потребителите.

История 

През 1950-те и 1960-те компютърният опериран софтуер и компилатори са били предоставяни като част от покупки на хардуер без допълнителни такси. По това време отвореният код, формата на софтуер, която е подходяща за четене от човек се е разпространявала със софтуер, който е предоставял възможността за оправяне на грешки (бъгове) или за добавяне на нови функционалности. Университетите са използвали компютърните технологии. Много от модификациите по разработката на софтуер и писането на код са се споделяли свободно, за да се следват академичните принципи за споделянето на знания и така се появили организации, които да улесняват споделянето.

Много хора твърдят, че още от основаването на Интернет през 1969 започва и движението на отворен код докато други не правят разлика между отворен код и движението свободен софтуер.

Фондацията за свободен софтуер (ФСС) стартира 1985 г., използвайки думата „свободен“ със значение свободна дистрибуция, а не свободна от заплащане. След като голям брой свободни софтуери са били (и са все още) безплатни, такива свободни софтуери се свързват с това, че не струват нищо, което изглежда анти-търговско.

Края на 90-те: Създаването на отворен код 

През 1997 Ерик Реймънд публикува Катедралата и базарът, задълбочен анализ на обществото на хакерите и принципите на отворения код. Този труд получава голямо внимание през началото на 1998 и е един от факторите, който мотивира корпорацията Нетскейп Комюникейшън да пусне своя популярен Интернет пакет Нетскейп Къмюникатор като свободен софтуер. Този код днес е основа на Mozilla Firefox и Thunderbird.

Ходът на Netscape кара Реймънд и други да потърсят начин принципите и ползите от свободния софтуер да важат и за индустрията на комерсиален софтуер. Те счели, че социалният активизъм Фондацията за свободен софтуер (ФСС) не е привлекателен за Netscape и потърсили начин да променят движението на свободен софтуер, така че да подчертае бизнес потенциала на това да се споделя отворен код. Въвеждането на нов термин било нужно, защото старият – свободен софтуер, се оказал много объркващ за хората. За тях свободен означавало безплатен – свободен за разпространение, докато всъщност се имало предвид свободен за модификация. Новият термин разрешил този проблем и се оказал по-лесен за разбиране.

Отворен код е приет като термин едва през януари 1998 година, на сбирка на някои от поддръжниците на свободния софтуер в Пало Алто, Калифорния като реакция на обявяването на Netscape, че ще пусне Navigator като отворен код. Част от присъствалите на сбирката са Ерик Реймънд, Тод Андерсън, Сам Окмън, Джон Хол и Кристин Питърсън (която всъщност предлага израза отворен код). През следващите дни Реймънд и останалите работят върху това да популяризират новия термин. Линус Торвалдс дава много важно одобрение на следващия ден. На Фил Хюс му е предоставена възможност да публикува статия в Linux Journal. Ричард Столман, пионерът на движението за свободен софтуер, първоначално приема термина, но след това си променя мнението. Тези, които одобряват термина, използват възможността – пускането на отворения код на Navigator, за да се освободят от идеологията и конфронтиращи конотации от термина „свободен софтуер“. Netscape пуска своя програмен код с лиценза Netscape Public License и по-късно Mozilla Public License.

Терминът получава много голям тласък на събрание, организирано от издателя Тим О'Райли през април 1998 г. Оригиналното заглавие е било „Сбирка на свободния софтуер“ и по-късно е известно като „Сбирка на отворения код“. На него присъстват някои от най-известните и влиятелните сред поддръжниците на свободния софтуер като Линус Торвалдс, Лари Уол, Браян Бехлендорф, Ерик Алман, Пол Викси, Гуидо ван Росум, Майкъл Тииман, Ерик Реймънд и Джейми Завински от Nescape. На тази среща объркването, причинено от свободен софтуер, е било обсъдено. Тииман подкрепя термина „свободен“ докато Реймънд се обявява за „отворен код“. Разработчиците подложили спора на гласуване и победителят бил обявен на пресконференция по-късно през деня. Пет дена по-късно Реймънд прави първата си публична изява, в която призовава обществото на свободния софтуер да приеме новия термин. Инициативата Отворен Код е била създадена малко след това.

Въпреки това Ричард Щалман и ФСС остро възразяват срещу подхода на новообразуваната организация. Те се опасявали, че със строго ограничения фокус на отворения код Инициативата за отворен код (ИОК) заравя философските и социалните ценности на свободния софтуер и крие въпроса за свободата на компютърните потребители. Щалман продължава да поддържа тезата, че потребителите на всеки един от термините са съюзени в борбата срещу собственическия софтуер.

През август 1999 Sun Microsystems пускат StarOffice офис пакет като свободен софтуер с лиценз GNU Lesser General Public License. Свободната версия на софтуера е преименувана на OpenOffice.org, и съществува заедно с StarOffice.

Края на 90-те: Създаването на Инициативата Отворен Код 

Инициативата Отворен Код (ИОК) е основана през февруари 1998 от Ерик Реймънд and Брус Перенс, за да стимулира употребата на новия термин „отворен код“ и да „покръсти“ новите принципи на отворен код. 

Докато Инициативата Отворен Код търси да популяризира използването на новия термин, създателите на комерсиален софтуер се оказват все по-застрашени от концепцията за свободно разпространяване на софтуер и всеобщ достъп до отворения код на приложението. Говорител на Microsoft се изказва публично по този въпрос през 2002 г., че „отвореният код е унищожител на интелектуалната собственост. Не мога да си представя нещо по-лошо от това за софтуерния и интелектуалния бизнес.“ Тази гледна точка перфектно обобщава първоначалното мнение на някои софтуерни корпорации към Свободен Софтуер с Отворен Код (ССОК). Въпреки че ССОК исторически винаги е играл роля извън популярния сектор на частното разработване на софтуер, компании като Microsoft започват да развиват официално присъствието на отворен код в Интернет. IBM, Oracle, Google и State Farm са само част от компаниите с основен публичен дял в днешния конкурентен пазар на отворен код. Налице е голяма промяна в корпоративната философия, отнасяйки се до разработването на ССОК.

Движението за свободен софтуер е основано през 1983. През 1998 група от хора се застъпват, че терминът свободен софтуер трябва да бъде заменен от софтуер с отворен код СОК като изразяване, което е по-малко амбициозно и по-комфортно за корпоративния свят. Разработчиците на софтуер може да искат да публикуват своя софтуер с лиценз с отворен код, така че всеки да може също да разработи същия софтуер или да разбере неговата вътрешна функционалност. Със софтуер с отворен код основно се дава достъп на всеки да създава свои модификации, част от тях са операционни системи и архитектури на процесори, за да ги сподели с други или в някои случаи да ги пусне на пазара. Скорес Касен и Раян посочват няколко причини, основани на политиката на отворения код, в частност високата ценност на отворения код (в сравнение с повечето платени формати), в следните категории:
 Сигурност
 Достъпност
 Прозрачност
 Вечност
 Оперативна съвместимост
 Гъвкавост
 Локализация – особено в контекста на местните правителства (които вземат софтуерните решения). Касен и Раян спорят, че „правителствата имат присъща отговорност и финансова отговорност спрямо данъкоплатците“, което включва внимателните анализи на тези фактори когато се взима решение за закупуването на платен софтуер или да приложат софтуер с отворен код.

Дефиницията за Отворен Код основно представя философията на отворен код и допълнително дефинира използването на термина, модифицирането му и преразпределянето на софтуера с отворен код. Софтуерните лицензи дават права на потребители, в противен случай лицензите ще бъдат запазени по силата на закона за авторско право на притежателите на авторските права. Няколко лиценза на софтуер с отворен код са квалифицирани в рамките на Дефинициите за Отворен Код. Най-изтъкнат и популярен пример е Общ публичен лиценз на ГНУ (ОПЛ), който „позволява свободното разпространяване при условие, че бъдещите разработвания и приложения са със същия лиценз“, който също е изплатен. Докато разпространението на отворен код представя начин да предостави отворения код за публичен достъп, то лиценза с отворен код позволява на авторите начин да осигурят този достъп.

Етикетът отворен код се появява като стратегическа сесия, проведена на 7 април 1998 в Пало Алто в реакция на обявеното разпространение на Navigator (като Mozilla) с отворен код от Netscape през януари 1998. Участниците в сесията използвали пускането на Navigator с отворен код, за да изяснят потенциален конфликт, причинен от двусмислието на думата „свободен“.

За близо 20 години са събрани доказателства за разработването на затворен срещу отворен софтуер, които са предоставени от общността на разработчици в Интернет. Благодарение на тях ИОК представи случая с „отворения код“ на комерсиалния бизнес, като Netscape. ИОК се надява, че използването на етикета „отворен код“ ще елиминира неяснотата, особено за хора, които възприемат „свободния софтуер“ за анти-комерсиален. Те търсят как да дадат по-висок профил на практическите ползи от използването на свободно наличен отворен код и искат да привлекат основни софтуерни бизнес компании и други високо технологични индустрии в работата и дистрибуцията на отворен код. Перенс се опитва да регистрира „отворен код“ като търговска марка за ИОК, но този опит е бил непрактичен за стандартите на запазена марка. Междувременно поради представянето на труда на Реймънд на главния мениджър на Netscape, те пускат своя програмен код на Navigator като отворен код с благоприятни резултати. Реймънд открива за това едва когато прочита прессъобщението, като е привикан от PA на изпълнителния директор на Netscape Джим Барксдейл по-късно през деня

Дефиниции 

Организацията OSI, чийто председател за момента е Майкъл Тийман, е определила правила, по които може да се установи дали един продукт е с отворен код, или не.

Откъдето се вижда, че отворен код не означава само дадена програма да бъде с публикуван изходен код, който да е станал обществено достояние:

1. Свободно разпространение.
Лицензът, с който се разпространява програмата, не трябва по никакъв начин да забранява продажба или свободно ѝ предоставяне като компонент от друг многокомпонентен софтуер. Лицензът не може да налага плащане на роялти или други такси за авторски права, право на ползване и приходи от продажби.

2. Изходен (сорс) код.
Програмата трябва да съдържа изходния код и да позволява свободното му разпространение, вкл. в компилиран вид (ако има такъв). За случаите в някакъв вид продуктът не се разпространява заедно с кода, трябва да има инструкции откъде може да се свали безплатно от Интернет.

Сорс кодът следва да е в такъв вид, че всеки да може да го променя за своите цели и нужди. Доставянето на маскиран (обфускиран) код или на криптиран сорс код е недопустимо.

3. Допълнителни работи.
Лицензът трябва да позволява промени на кода и дописване, както и да разрешава същите да бъдат разпространявани под същия лиценз, както е на оригиналния софтуер.

4. Цялостност на авторския код.
– Лицензът може да забранява разпространение на сорс код в модифициран вид само когато лицензът позволява добавяне заедно със сорс кода на пач файлове с цел модифициране на програмата по време на изпълнение ѝ (компилиране).
– Лицензът следва още да позволява разпространение на софтуера, създаден по този начин.
– Лицензът може да изисква версия с дописания код да носи различно име или ID номер от този на оригиналния продукт.

5. Без дискриминация на лица или групи.
Лицензът не може да дискриминира хора или социални прослойки.

6. Без дискриминация на области на приложение.
Лицензът не може да ограничава ползване на програмата за определени области. Така например не може да ограничава ползването на софтуера само зао търговски дейности или само за генно инженерство напр.

7. Разпространение на лиценза.
Правата, зададени за всяка програма, следва да са задължителни за всички, които я ползват, без необходимост от допълнителни лицензи.

8. Лицензът не може да важи за определен продукт.
Правата, които предоставя лицензът, не може да зависят от това дали програмата принадлежи към определено линукс дистро, или не. Ако се извади от дистрото или се разпространява отделно, всички нейни части остават подвластни на условията от лиценза на оригиналното дистро.

9. Лицензът не може да ограничава друг софтуер.
Лицензът не следва да налага ограничения върху друг софтуер, който се разпространява заедно с лицензирания. Така например лицензът не може да изисква всички останали програми от едно дистро или пакет да бъдат също с отворен код.

10. Лицензът трябва да е технологично независим.
Никоя клауза на лиценза не може да касае конкретна технология или даден тип интерфейс.

Лицензионен режим и правна рамка 

Лицензът определя правата и задълженията, с които лицензиантите трябва да се съобразяват. Обикновено притежателите на лиценз за софтуер с отворен код имат право да копират, променят и разпространяват кода (съдържанието). Лицензът може да наложи и задължения (напр. всички промени по кода, който подлежи на разпространение, трябва указват приноса на автора им).

Авторите дават лицензи върху собствената си работа, изхождайки от принципа, че те държат авторските права върху продукта си. Давайки лиценз за копиране, промяна и разпространяване на работата им, авторите един вид отдават авторските си права. Авторът все още е носител на авторските си права, но лицензиантът има правото да ги използва, ако това не противоречи на задълженията, упоменати в лиценза. Авторът има възможността да продаде или назначи срещу лиценз изключителните си авторски права върху работата, давайки контрола върху тях на новия им собственик. Притежанието на авторското право се различава от притежанието на самия продукт – копие на код (текст, книга...) може да бъде притежаван без правото да се копира, променя или разпространява.

Участието в отворен проект (напр., Apache.org) става с изрично упоменат лиценз или подразбиращ се такъв. Някои отворени проекти използват код без наложен лиценз, но въпреки това се нуждаят от притежениято на авторските права, за да включат кода в проекта (напр., OpenOffice.org и договорката Joint Copyright Assignment).

Поставянето на код или съдържание на публично място е вид отказ на автора (собственика) от авторските му права върху тази работа. Когато съдържанието на една работа е публично достъпно, не се изисква лиценз за копиране, промяна или разпространение.

Примери за лицензи на продукти с отворен код са Apache License, BSD license, GNU General Public License, GNU Lesser General Public License, MIT License, Eclipse Public License и Mozilla Public License.

Разпространението на лицензите за отворен код е една от отрицателните страни на движението за отворен код, защото често буквичките на закона са трудно различими между различните лицензи. Наличието на повече от 180 000 проекта с отворен код и повече от 1400 уникални лиценза, води до драстично усложняване на управлението на проекти с отворен код при наличието на такива със затворен код. Някои лицензи са локални, а други са произлезли от FOSS (Free and open-source software) лицензи, като Berkeley Software Distribution (BSD), Apache, MIT-лиценз (Massachusetts Institute of Technology) или GNU General Public License (GPL). От тази гледна точка, практикуващите отворен код започват да използват класификации, които групират FOSS лицензите (обикновено въз основа на задълженията, наложени от носителя на авторските права).

През 2008 беше постигнат важен етап за движението за отворен код от правна гледна точка, когато апелативният съд на САЩ отсъжда, че лицензите на свободния софтуер са обвързани с правните норми при работа с авторско право и подлежат на регулиране от съществуващия закон за авторско право и сродните му права. В резултат на това, ако крайните потребители нарушат условията на лиценза, той се прекратява, поради нарушаване на авторското право.

Разпространение на понятието

Модел на развитие 
В своето есе от 1997 Катедралата и базарът, Ерик Реймънд предлага модел за развитие на OSS, известен като модела базар. Реймънд оприличава разработването на софтуер с традиционните методологии за строежа на катедрала, „внимателно изработени от отделни магьосници или малки групи от магове, които работят в пълна изолация“. Той предлага, целият софтуер да се развива с помощта на стила базар, който той описва като „чудесен бърборещ базар на различни програми и подходи.“ 

В традиционния модел на развитие, който той нарича модел на катедралата, развитието се извършва централизирано. Ролите са ясно дефинирани. Ролите включват хора, посветени на проектиране (архитектите), хората, отговорни за управлението на проекта, както и хора, които отговарят за изпълнението. Традиционното софтуерно инженерство следва модела на катедралата. В своята книга The Mythical Man-Month Фред Брукс застъпва този модел. Той отива по-далеч, казвайки, че за да се запази целостта на архитектурната система, проектирането на системата трябва да бъде направено от колкото е възможно по-малко архитекти.

Моделът базар, обаче, е различен. В този модел, ролите не са ясно дефинирани. Gregorio Robles показва, че софтуер, разработен по модела базар трябва да има следните модели:

Потребителите трябва да бъдат третирани като съразработчициПотребителите се третират като съразработчици и те трябва да имат достъп до изходния код на софтуера. Освен това, потребителите биват насърчавани да представят допълнения към софтуера – код поправки за софтуера, доклади за грешки, документация и т.н. увеличаването на съразработчици увеличава и скоростта, с която се развива софтуера. В закона на Линус (Linus's Law) се твърди: „Предоставяйки достатъчно очи всички грешки стават видими.“ Това означава, че ако много потребители имат достъп до изходния код, те в крайна сметка ще намерят всички грешки и да предложат как да се оправят. Трябва да се вземе предвид, че някои потребители са с напреднали програмни умения, а освен това, компютърът на всеки потребител осигурява допълнителна среда за тестване. Тази нова среда за тестване предлага способността да се намери и да определи нов „бъг“.Ранните версииПървата версия на софтуера трябва да бъде пусната възможно най-рано, така че да се увеличат шансовете за по-бързо намиране на съразработчици.Честата интеграцияПромените по кода следва да бъдат интегрирани (обединени в обща база код) възможно най-често, така че да бъде избегната необходимостта от оправянето на голям брой грешки в края на жизнения цикъл на проекта. Някои проекти с отворен код имат нощна разработка, където интегрирането се извършва автоматично на база на дневната.Няколко версииТрябва да има най-малко две версии на софтуера. Трябва да има buggier версия с повече функции и по-стабилна версия с по-малко възможности. Buggy версията (наричана също версия на разработка) е за потребители, които искат незабавното използване на най-новите функции, и са готови да приемат риска от използването на код, който все още не е старателно тестван. Потребителите могат след това да действат като съразработчици – да докладват проблеми и да осигуряват корекции за тях.Висока модуларизацияОбщата структура на софтуера трябва да бъде модулно позволяваща паралелно развитие на независими компоненти.Структура за динамично взимане на решенияНалице е необходимост от структура за вземане на решения, независимо дали формална или неформална, което прави стратегически решения зависими от променящите се потребителски изисквания и други фактори. Вж Екстремно програмиране.Данните показват, обаче, че OSS не е толкова демократична както модел на базар предполага. Анализ на пет милиарда байта безплатен / отворен код от 31 999 разработчици показва, че 74% от кода е написан от най-активните 10% от автори. Средният брой на автори, участващи в проект е 5,1, с медианата при 2.

Макар отворен код да изглежда тясно свързано понятие със света на програмирането, смисъла му и ползите от него все повече се разпростират. Наглед неразбираемите термини като култура с отворен код или журналистика с отворен код, които някои от последователите на движението налагат и развиват, добиват все повече смисъл. Разбира се налага се промяна на принципите отнасящи се пряко за софтуера, като по-скоро говорим за отворено съдържание, но основната идеология на отворения код е запазена.

Простичък пример за това са блоговете, които срещаме ежедневно. Съдържанието в тази енциклопедия също е добър пример за това що е то отворен код и колко бързо се развиват продуктите с него.

Предимства и недостатъци 

Софтуерни експерти и изследователи на софтуера с отворен код са идентифицирали няколко предимства и недостатъци. Основното предимство за бизнеса е, че отвореният код е добър начин за постигне на по-голямо проникване на пазара. Фирмите, които предлагат софтуер с отворен код, са в състояние да създадат индустриален стандарт и по този начин да спечелят конкурентно предимство. Той също така подпомага изграждането на лоялност в разработчиците, тъй като имат усещането за по-голяма власт и чувство на частична собственост от крайния продукт. 

Също така са необходими много по-малко разходи за маркетинг и логистика за такъв софтуер. Той също помага компаниите да бъдат в крак с развитието на технологиите. Добро средство е за промотирането на имиджа на кампанията, включително и на нейните търговски продукти.  Развитието на софтуера с отворен код е допринесло за бързо и с високо качество създаване на надеждни продукти, които изискват малко средства. 

Терминът „отворен код“ е бил първоначално предвиден да бъде запазена марка, но е бил определен като прекалено общ и съответно тази идея е отпаднала. Въпреки това създава потенциала за по-гъвкава технология и по-бърза иновация. Счита се за по-надежден, защото принципно има хиляди индивидуални програмисти, които тестват за проблеми и бъгове. Софтуерът е гъвкав, защото модулни системи позволяват на хората да създават най-различни интерфейси или да вкарват нови способности в програмата. Това е иновационно, тъй като програмите с отворен код са продукт на сътрудничеството между голям брой различни програмисти. Смесицата от различаващи се гледни точки и корпоративни цели, както и на лични цели ускорява иновациите. 

Освен това, свободния софтуер може да се развива в съответствие с чисто техническите изисквания. Липсва търговски натиск, който често намалява качеството на софтуера. Такъв натиск принуждава традиционните софтуерни разработчици да обръщат повече внимание на изискванията на клиентите, отколкото на изискванията за сигурност, тъй като тези функции са донякъде невидими за клиента. 

Понякога се казва, че процесът за разработването на софтуер с отворен код не може добре да бъде дефиниран, което включва и етапите в процеса на развитие, като например тестването и документацията на системата могат да бъдат пренебрегнати. Все пак това е вярно само за малки (най-вече с един програмист) проекти. По-големи, успешни проекти налагат и прилагат някакви правила, защото трябва да се направи възможна работата в екип.  В най-сложните проекти тези правила могат да бъдат толкова строги, че да налагат преглед дори на незначителна промяна от двама независими разработчици. 

Не всички инициативи за изграждане на софтуер с отворен код са били успешни, например SourceXchange и Eazel.  Софтуерни експерти и изследователи, които не са убедени в способността на отворения код да произвежда качествени системи, идентифицират като основните проблеми неясния процес, късното откриване на дефекти и липсата на емпирични доказателства.  Освен това е трудно да се изработи стабилен търговски бизнес модел около парадигмата на отворения код. Следователно, само техническите изисквания могат да бъдат изпълнени, но не и изискванията на пазара.  По отношение на сигурността, отвореният код може да позволи на хакери да разберат за слабостите или пропуските на отворения софтуера по-лесно от затворения. Има зависимост от контролни механизми, за да се създаде ефективна работа на автономни агенти, които участват във виртуални организации.

Инструменти за разработка 

В разработката на софтуер с отворен код, участниците, повечето от които са доброволци, са разпределени сред различни географски райони, така че има необходимост от инструменти, които да им помагат да си съдействат в правенето на отворен код. Често, тези инструменти също са с отворен код.

Системи за контрол на версиите като Concurrent Versions System (CVS), Subversion (SVN), Git и GNU Compiler Collection са примери за инструменти, които помагат с управлението на файловете на отворения код и с промяната на тези файлове за софтуерен проект. Тези инструменти също са софтуер с отворен код.

Средства, които автоматизират тестването, компилирането и докладването за бъгове помагат да се запази стабилност и подкрепа на софтуерни проекти, които имат множество девелъпъри, но нямат мениджъри, контрол над качеството или техническа подкрепа. Често използвани бъг тракери са Bugzilla и GNATS.

Инструменти като мейлинг листи, IRC и незабавни съобщения доставят начини за Интернет комуникация между девелъпърите. Мрежата или уебът също играе главна роля във всичките гореспоменати системи. Някои сайтове използват всичките свойства на тези инструменти като система за управление на разработка на софтуер. Такива сайтове са GNU Savannah, SourceForge и BountySource.

Проекти и организации 

Някои от „по-видните организации“ участващи в разработката на софтуер с отворен код са Apache Software Foundation, създатели на Apache уеб сървъра; Linux Foundation, неправителствена организация; Eclipse Foundation, домът на софтуерната платформа за разработка Eclipse; Debian Project, създатели на влиятелната GNU/Linux дистрибуция; Mozilla Foundation, домът на уеб браузъра Firefox; и OW2, европейско общество, което разработва мидълуер с отворен код. Новите организации са склонни да имат по-изтънчен модел на управление.

Няколко от програмите с отворен код са станали определящи записи в тяхното пространство. Такива програми са GIMP, система за редактиране на изображения; езикът за програмиране и среда, Java, на Сън Майкросистъмс; системата за база данни MySQL; Unix операционната система FreeBSD; офис пакета LibreOffice; и анализатора на мрежови протоколи Wireshark.

Разработката на софтуер с отворен код е често извършвана на живо пред публика, с помощта на безплатни услуги предлагани от Интернет, като сайтовете Launchpad и GitHub.

Open Source Software Institute е неправителствена организация, установена през 2001, която насърчава разработката и изпълнението на софтуер с отворен код в САЩ. Нейните усилия са насочени към насърчаването на приемането на софтуер с отворен код.

Open Source for America е група създадена с цел да повиши осведомеността във федерално правителство на САЩ за ползата от софтуер с отворен код. Техните обявени цели са да окуражават използването на софтуер с отворен код в правителството и да участват в проекти за разработка на този софтуер.

Бизнес модел 
Отвореният код се е доказал през годините като нещо много повече от чиста идеология или подход, използван само от идеалисти и фанатици. Той се е превърнал в бизнес модел и начин продуктът да се развива по-бурно и по-пълноценно. Това е добре описано в есето на Ерик Реймънд „Катедралата и базарът“.

Все пак има някои пречки пред това един продукт безпроблемно да възприеме принципите на отворения код и веднага да стане печеливш. Такива пречки са например честата липса на утвърдени срокове и планове за развитие на продукта, липсата на подходящо обучение и дори самите лицензи (някои от тях се самоналагат или ограничават продукта, като например GPL).

Разбира се, на база на отворения код са разработени различни бизнес модели, които да се справят с тези пречки и да подобрят резултатите. Но те са в употреба от скоро и тяхното поведение не е достатъчно изучено и изяснено. Пример за такъв проект е BeeKeeper.

Вижте също 
 Свободен софтуер
 Свободен хардуер
 Фондация за свободен софтуер
 Свободно съдържание
 Лиценз за свободна документация на ГНУ

Източници

Външни препратки 
 Защо понятието „свободен софтуер“ е по-добро от „отворен код“
 Въведение. Какво е софтуер с отворен код? GNU Линукс. Други проекти. Философски четива.
 Най-добрите програми с отворен код за домашния компютър, от Мартин Белтов – 24 януари 2015
 Софтуер с отворен код. Download.BG
 Катедралата и базарът на български език
  Open Source Initiative
  Free Software Foundation

Свободен софтуер
Софтуерни лицензи