Катедралата и базарът

[mnogoznaiko]

Катедралата и базарът

Есето на Ерик Реймънд е издадено на български (превод Владимир Койлазов), 
като притурка на сп. Linux 2-ри брой от 2000 г., откъдето е взет настоякщия текст. 
Друг превод на Катедралата и базарът може да намерите тук.

Увод

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

1. Катедралата и базарът

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

Със сигурност не и аз. По времето, когато Linux доплува в обхвата ми в началото на 1993 година, вече бях участвал в разработката на Unix и на отворени продукти в продължение на десет години. Бях един от първите, които писаха за GNU в средата на 80-те. Бях пуснал доста голямо количество отворен софтуер в мрежата, бях разработил или участвал в разработката на няколко програми (nethack, VC и GUD режимите на Emacs, xlife и други), които все още широко се използват днес. Мислех, че знам как се прави.

Linux преобърна голяма част от това, което си мислех, че знам. Изповядвах 
религията на Unix за малки инструменти, бързи прототипи и еволюционно

програмиране в продължение на години. Но освен това вярвах, че има определена критична сложност, отвъд която е необходим по-централизиран, a priori подход. Вярвах, че най-важният софтуер (операционни системи и наистина големи програми като Emacs) трябва да се строят като катедрали, внимателно оформяни от отделни магьосници или малки групички магове, работещи в самотно уединение, без бета версии, докато не му дойде времето.

Стилът на Линус Торвалдс – да се пускат версии рано и често, да се предлага всичко, до степен на безотговорност – дойде като изненада. Тук нямаше тихо, внимателно строене на катедрала - вместо това общността на Linux изглежда приличаше на голям бърборещ базар от различни мнения и подходи (доста точно символизирана от сайтовете с архиви за Linux, които приемаха мнения от всеки), от който смислена и стабилна система може да се получи само като поредица от чудеса.

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

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

Това е историята на този проект. Ще я използвам, за да предложа някои афоризми относно ефективното отворено разработване. Не всички тези неща научих от света на Linux, но ще видим как Linux ги представя в определена светлина. Ако съм прав, те ще ви помогнат да разберете какво прави общността на Linux толкова добър източник на хубав софтуер – и, може би, ще ви помогнат да станете по-добри в програмирането. 
 

2. Пощата трябва да се достави

От 1993 година работех по техническата поддръжка на малък доставчик на Ннтернет услуги с безплатен достъп, наречен Chester Country InterLink (CCIL) в Уест Честър, Пенсилвания (бях съосновател на CCIL и написах нашия уникален многопотребителски софтуер за съобщения – можете да го видите, ако направите telnet към locke.ccil.org – telnet://locke.ccil.org. Днес системата поддържа почти три хиляди потребители на трийсет телефонни линии.) Работата ми позволяваше 24-часов достъп до мрежата през 56К линията на CCIL – всъщност, тя практически го изискваше!

Съответно бях свикнал с мигновената електронна поща в Интернет. Поради най-различни причини ми беше трудно да накарам SLIP да работи между моята машина вкъщи (snark.thyrsus.com) и CCIL. Когато най-накрая успях, намерих необходимостта постоянно да се telnet-вам до locke, за да си проверя пощата, за доста изнервяща. Исках пощата ми да пристига на snark, така че да получавам сигнал, когато е дошла и да мога да я обработвам с локалните си инструменти. Препращането със sendmail не ставаше, защото домашната ми машина не винаги е свързана към мрежата и няма статичен IP адрес. Трябваше ми програма, която да използва SLIP и да изтегля пощата ми на моята машина. Знаех, че има такива програми и че повечето използват прост протокол, наречен POP (Post Office Protocol). Освен това операционната система на 1оске – BSD/OS – естествено включваше POP3 сървър.

Трябваше ми POP3 клиент. Потърсих в мрежата и намерих един. Всъщност, намерих три или четири. Използвах pop-perl за известно време, но на него му липсваше една според мен очевидна възможност – да се променят адресите в изтеглената поща така, че отговорите да отиват на правилното място.

Проблемът беше следният: представете си. че някой си "joe" на locke ми изпрати поща. Ако я изтеглех на snark и след това се опитах да й отговоря, програмата се опитваше безгрижно да я изпрати на несъществуващия "joe" на snark. Ръчното преправяне на обратните адреси на "@ccil.org" скоро се превърна в изключително досадна работа.

Очевидно компютърът трябваше да прави тези работи. Обаче никой от съществуващите РОР клиенти не знаеше как! И това ни води до първия урок:

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

Може би това е очевидно (отдавна е известно, че "нуждата учи"), но твърде често програмистите прахосват дните си за пари над програми, от които нито се нуждаят, нито пък обичат. Но не и в света на Linux – което може би обяснява защо средното качество на софтуера, водещ началото си от общността на Linux, е толкова високо.

И тъй, дали се впуснах веднага в трескаво кодиране на чисто нов POP3 клиент, който да се мери със съществуващите? Естествено, че не! Прегледах внимателно програмите, които имах под ръка и се запитах "коя е най-близо до това, което искам?" Защото

2. Добрите програмисти знаят какво да напишат. Наистина великите знаят какво да пренапишат (и използват).

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

Линус Торвалдс (http://www.tuxedo.org/~esr/faqs/linus) например всъщност не се е опитвал да напише Linux отначало. Вместо това той започнал, като използвал код и идеи от Minix, мъничка операционна система за PC-клонинги, наподобяваща Unix. В края на краищата всичкият код от Minix бил заменен или напълно пренаписан – но докато бил там, служил като скеле за това, което по-късно станало Linux.

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

Традицията за обмяна на изходен код в света на Unix винаги е насърчавала повторното използване на код (ето защо проектът GNU избра Unix като основна операционна система, въпреки някои сериозни съмнения относно самата ОС). Светът на Linux доведе тази традиция почти до технологичния й предел – има достъпни терабайти изходен код. Ето защо търсенето на нечие друго "почти добро " решение е по-вероятно да даде добри резултати именно в областта на Linux отколкото където и да е другаде.

При мен стана точно така. Заедно с предишните ми находки, второто търсене даде общо девет кандидата – fetchpop, PopTart, get-mail, gwpop, pinp, pop-perl, popc, popmail и upop. Първо се спрях на fetchpop от Сюнг-Хонг О. Добавих към него възможността за промяна на адресите в съобщенията, както и различни други подобрения, които авторът вгради във версия 1.9.

Няколко седмици по-късно обаче се натъкнах на кода за popclient от Карл Харис и се оказах изправен пред един проблем. Макар fetchpop да имаше някои добри и оригинални идеи (например неговия режим на "демон"), той можеше да се справя само с POP3 и беше доста аматьорски написан (по това време Сюнг-Хонг беше умен, но неопитен програмист, и това си личеше в кода му). Програмата на Харис беше написана по-добре, доста професионално и стабилно, но й липсваха някои важни и доста хитри за реализиране възможности на fetchpop (включително тези, които добавих аз).

Дали да се спра на fetchpop или да мина на popclient? Ако се прехвърлех, щях да изхвърля кода, който вече бях написал, но пък щях да имам по-добра основа за разработване.

Практически мотив да мина на popclient: беше поддръжката на множество протоколи. POP3 се използва най-често, но не е единственият. Fetchpop и другите конкуренти не се справяха с POP2, RPOP или APOP, а пък аз вече имах смътни мисли за добавяне на IMAP (www.imap.org, Internet Message Access Protocol, най-новият и най-мощен email протокол) просто заради спорта.

Но имах и по-теоретична причина да мисля, че прехвърлянето може да е добра идея, нещо, което научих дълго преди Linux.

3. "Планирай да изхвърлиш нещо – тъй или иначе ще се наложи." (Фред Брукс, "The Mythical Man-Month". глава 11).

Или, да го кажа по друг начин, човек често не разбира наистина проблема, докато не му намери решение. Втория път може би знае достатъчно да го направи правилно. Тъй че, за да стане това, бъдете готови да започнете отначало поне веднъж.

Е, (казах си аз) промените във fetchpop бяха първият ми опит. И така, аз го изоставих.

След като изпратих първите си допълнения към popclient: на Карл Харис на 25 юни 1996, открих, че той всъщност е загубил интерес към програмата известно време преди това. Кодът беше малко занемарен, тук-там стърчаха грешки. Трябваше да направя много промени и ние бързо се съгласихме, че е логично аз да поема програмата.

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

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

4. Ако човек има правилното отношение към нещата, интересните проблеми сами ще го намерят.

Но отношението на Харис беше още по-важно. Той разбираше, че

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

Без дори да се налага да го обсъждаме, Карл и аз знаехме, че имаме обща цел – да направим най-доброто съществуващо решение. Единственият въпрос беше дали мога да докажа, че съм достатъчно добър. След това той беше много отзивчив и благосклонен. Надявам се и аз да се справя така добре, когато дойде моя ред. 
 

3. Важно е да има потребители.

И тъй, аз поех popclient. Нещо повече, аз поех и неговите потребители. Потребителите са много хубави неща. не само защото демонстрират че си полезен и правиш нещо добро. Когато се насърчават подходящо, те могат да станат и разработчици.

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

6. Да смятате потребителите за ваши партньори е най-лесният път към бързо подобрение на кода и ефективно откриване на грешки.

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

Всъщност мисля, че най-умният и с най-големи последици ход на Линус не е написването на ядрото на Linux, а измислянето на нейния модел за разработка. Когато веднъж изразих това свое мнение в негово присъствие, той се усмихна и кротко повтори нещо, което често е казвал: "Аз по принцип съм един много мързелив човек, който обича да обира похвалите за неща, които всъщност други правят."Ленив като лисица. Или, както Робърт Хайнлайн пише за един от известните си герои – твърде мързелив, за да се провали.

В ретроспект, един предшественик на методите и успеха на Linux може да се види в разработката на Lisp-библиотеката за GNU Emacs и архива с код за Lisp. За разлика от катедралния стил на C-ядрото на Emacs и повечето други инструменти на FSF, еволюцията на базата с код на Lisp беше гладка и водена от потребителите. Идеи и прототипи често бяха пренаписвани три или четири пъти преди да се стигне до стабилен краен вид. Освен това свободно създавани съвместни работи през Интернет, в стил на Linux, бяха доста често явление.

Всъщност моят най-голям успех преди fetchmail беше може би режимът VC за Emacs, съвместна разработка по електронната поща в стил на Linux с трима други програмисти, само един от които (Ричард Столман, авторът на Emacs и основател на FSF – (http://www.fsf.org) съм срещал до ден-днешен. Това беше потребителски интерфейс за достъп до SCCS, RCS, а по-късно и CVS от средата на Emacs. който предлагаше лесен контрол на операциите с различните версии на изходния код. Той се разви от малка, грубо написана от някой друг програмка за scss.el. И разработката на VC успя, защото, за разлика от самия Emacs. Кодът на Lisp може да минава през цикъла пускане-тестване-подобряване много бързо. 
 

4. Пускайте версии отрано и често

Ранното пускане на продукта и честото обновяване са критична част от модела на разработка при Linux. Повечето разработчици, включително и аз, вярваха, че това е грешна тактика за по-големи проекти, тъй като ранните версии почти винаги са бъгави.и програмистите не искат да подлагат на изпитание търпението на потребителите.

Тази вяра подсилва стремежа към катедралния стил на разработка. Ако приоритетна цел е потребителите да виждат колкото може по-малко грешки в програмата, тогава просто се пускат нови версии на всеки шест месеца (или дори по-рядко), а в това време се бъхтате да оправяте бъгове. Си-ядрото на Emacs беше разработено по този начин Библиотеката на Lisp – обратно, тъй като имаше активни Lisp архиви извън контрола на FSF, където можеше да се намерят нови и все още в разработка версии независимо от цикъла на разработка на Emacs.

Най-важният от тези архиви, eLisp архивът в Охайо, беше предшественик на духа и много от характеристиките на днешните големи Linux архиви. Много малко от нас обаче се замисляха какво точно правим, или какво точно подсказва наличието на този архив за катедралния стил на FSF. През 1992 направих един сериозен опит да пренеса голяма част от този архив в официалната Lisp библиотека на Emacs. Навлязох в бюрократски проблеми и общо взето, начинанието нямаше голям успех.

Но една година по-късно, когато Linux стана широко известна, беше ясно, че с нея става нещо различно и много по-приемливо. Отворената стратегия за разработка на Линус беше точно противоположна на катедралния стил. Архивите на Sunsite (сега Metalab – http://metalab.unc.edu) и tsx-11 набъбваха стремително, нароиха се най-различни дистрибуции. И всичко това се предизвикавше от нечуваната честота на новите версии на основната операционна система.

Линус приемаше потребителите като сътрудници по най-ефективния възможен начин:

7. Пуснете програмата рано. Пускайте нови версии често. И слушайте клиентите си.

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

Но как работеше всичко това? Дали беше нещо, което аз също можех да повторя, или се дължеше на някакъв уникален талант на Линус Торвалдс?

Не мислех така. Е да, Линус е страхотен хакер (колко от нас могат да напишат сами професионално ядро на операционна система?). Но Linux не представляваше някакъв принципен скок напред. Линус не е (поне засега) изобретателен гений като Ричард Столман или Джеймс Гослинг (съответно с NeWS и Java). По-скоро Линус ми приличаше на конструктивен гений, със шесто чувство за избягване на бъгове и задънени улици, и с истинско умение да намира най-лесният път от точка А до точка В. Наистина от цялостният дизайн на Linux лъха това свойство и то отразява консервативния и опростен начин за разработка на Линус.

И тъй, ако честите версии и използването на Интернет не са случайност, а съществена част от пътя на минималните усилия, какво използваше Линус? Какво изстискваше от машинариите?

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

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

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

Казано по друг начин, "Ако гледат достатъчно очи, всички грешки са очевидни." Наричам това "Закон на Линус".

Оригиналната ми формулировка беше, че всеки проблем "ще бъде открит от някого". Линус обаче отбеляза, че човекът, който разбира причините за проблема и може да го оправи, може да не е, и всъщност често не е, този, който пръв се натъква на него. "Някой открива проблем", каза той, "а друг разбира причините за него. Намирането на проблема често е по-голямото предизвикателство." Важното е, че и двете неща стават бързо.

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

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

И това е всичко. Напълно достатъчно. Ако Законът на Линус беше неверен, тогава която и да е система, сложна колкото ядрото на Linux и над която работят много хора, би се сринала под тежестта на непредвидени лоши взаимодействия между частите й и неоткрити "дълбоки" бъгове. Ако законът е верен, той е достатъчен да обясни относителната стабилност на Linux и способността й да работи непрекъснато с месеци и дори години.

Може би това не е толкова изненадващо. Социолозите отдавна откриха, че средното мнение на множество еднакво квалифицирани (или неквалифицирани) наблюдатели е по-надеждно от мнението на един-единствен случайно избран представител. Те наричан това "ефектът на Делфи". Явно Линус показа, че това се отнася дори за разработката на операционна система – ефектът на Делфи може да се справи със сложни разработки дори на ниво ядрото на една операционна система.

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

Задължен съм на моя приятел Джеф Дътки (dutky@wam.umd.edu), който посочи, че законът на Линус може да се формулира и така: "Откриването и оправянето на грешки може да се провежда паралелно."Джеф отбеляза, че макар процесът да изисква комуникация между сътрудниците и даден главен координатор, не е необходима кой знае каква координация между самите сътрудници. Така този процес не става жертва на квадратичната сложност и разходите по управлението, които правят добавянето на допълнителни разработчици проблематично.

На практика теоретичната загуба на ефективност от това, че работата на няколко разработчика може да се припокрие, почти никога не изглежда проблем в света на Linux. Едно от следствията на честите обновявания е, че такива случаи се минимизират, тъй като поправките се разпространяват бързо.

Брукс дори направи допълнителна забележка, свързана с тази на Джеф: "Общата цена за поддръжка на една широко използвана програма обикновено е 40 или повече процента от цената на разработката й. Изненадващо е, че това силно зависи от броя на потребителите. Повече потребители намират повече грешки." (което е и моята теза).

Повече потребители намират повече бъгове, защото намират повече начини да натоварят програмата. Този ефект се усилва, когато потребителите са и разработчици. Всеки подхожда към намирането на бъгове по различен начин и вижда проблемите от малко по-различен ъгъл. Ефектът на Делфи изглежда работи именно благодарение на тези вариации. Що се отнася до откриването на грешки, това намалява и количеството дублирана работа.

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

Все пак Линус се подсигурява. В случай на твърде сериозни бъгове. версиите на ядрото на Linux се номерират по такъв начин, че потенциалните потребители могат да избират между последната версия, отбелязана като "стабилна", и най-новата, която може да съдържа грешки, но има и нови възможности. Тази тактика все още не се прилага от повечето разработчици за Linux, а си мисля, че би трябвало. Фактът, че са достъпни и двете версии ги прави, по-привлекателни. 
 

5. Кога розата не е роза?

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

Първото, което направих обаче, беше да реорганизирам и опростя popclient. Реализацията на Карл Харис беше много солидна, но имаше онази ненужна сложност, която се среща при много програмисти на C. Той разглеждаше кода като централен, а структурите от данни като допълнение към него. В резултат кодът беше красив, но структурата на данните – хаотична и доста грозна (поне по високите стандарти на един програмист на Lisp).

Имах и друга причина за пренаписването, освен подобряването на кода и структурата на данните. Тя беше да превърна програмата в нещо, което напълно разбирам. Не е интересно човек да се занимава с оправяне на грешки в програма, която не разбира.

През първия месец просто следвах основните принципи, заложени от Карл. Първата сериозна промяна направих, когато трябваше да добавя поддръжка на IMAP. Това стана като реорганизирах поддръжката на протоколи като отделен драйвер и направих три таблици с методи за поддръжка на POP2, POP3 и IMAP. Това, както и предишните промени, илюстрират един общ принцип, който е хубаво да се помни, особено за езици като C, които не поддържат динамични типове данни:

9. Комбинацията от добра структура на данните и тъпичък код работи по-добре от обратното.

Брукс, глава 9: "Ако ми покажеш кода си без структурата на данните, няма да разбера нищо. Ако ми покажеш данните си, обикновено няма да има нужда от кода; той ще бъде очевиден."

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

В този момент (началото на септември 1996-а, около шест седмици след като започнах от нулата) се замислих дали да не сменя името – все пак, вече нямах само POP клиент. От друга страна се колебаех, защото в програмата нямаше нищо съществено ново. Моята версия на popclient: трябваше тепърва да развие собствена индивидуалност.

Това се промени радикално, когато fetchmail се научи да пренасочва изтеглената поща към SMTP порт. Ще стигна до там след малко. Но преди това – казах, че бях решил да използвам този проект, за да проверя теорията си защо Линус Торвалдс е прав. Как (ще запитате вие) направих това? По следния начин:

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

2. Разширявах списъка на бета-тестерите с всички, които се заинтересуваха от fetchmail.

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

4. Вслушвах се в бета-тестерите си, питах ги, когато трябваше да взема важни решения относно дизайна на програмата и ги хвалех, когато изпращаха patch-ове и коментари.

Ползата от тези прости мерки си пролича веднага. Още от началото получих информация за бъгове, за каквато повечето разработчици биха дали мило и драго, при това често придружена с добри решения на проблемите. Имаше и конструктивна критика, хвалебствени писма, интелигентни предложения за нови възможности. Което ни води до следното:

10. Ако се отнасяте към бета-тестерите си като към вашия най-ценен ресурс, те ще ви отвърнат като станат най-ценния ви ресурс.

Една интересна мярка за успеха на fetchmail е дължината на списъка с бета-тестери, "фенове" на fetchmail. По времето, когато писах тази статия, той включваше 249 души и всяка седмица се включваха по двама-трима нови.

Сега, когато преглеждам текста в края на май 1997 година, списъкът започва да намалява. В най-добрите си времена той включваше близо 300 члена, но сега няколко души ме помолиха да ги отпиша, защото fetchmail им служи толкова добре, че вече няма нужда да следят списъка! Може би това е част от нормалния жизнен цикъл на един зрял проект, разработван в базарен стил. 
 

6. Popclient става Fetchmail

Истинската повратна точка в проекта беше когато Хари Хокхайзер ми изпрати основата на код за препращане на поща към SMTP-порта на клиентска машина. Осъзнах почти веднага, че стабилна реализация на тази възможност ще направи всички други режими за доставка на поща излишни.

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

Когато се замислих за препращане на съобщенията към SMTP, разбрах, че popclient се опитва да прави твърде много неща. Беше проектиран да бъде както програма за транспортиране на поща (mail transport agent, MTA), така и програма за локална обработка на пощата (local delivery agent, LDA). Ако използвах препращане към SMTP, можех да се отърва от цялата работа с MDA и да направя програмата само MTA, като подавам пощата на други програми за локална обработка, точно както sendmail.

Защо да се занимавам с всичките сложнотии по конфигурирането на MDA или поддръжката на пощенска кутия, когато е почти сигурно, че всяка платформа с поддръжка на TCP/IP ще поддържа и порт 25? Особено когато това означава, че изтеглената поща ще изглежда като нормална поща от подателя, което всъщност искахме ние.

Тук има няколко полезни урока. Първо, идеята за SMTP-препращане беше най-голямата полза от това, че се опитах да използвам методите на Линус. Потребител ми даде тази страхотна идея и всичко, което трябваше да направя, е да разбера значението й.

11. Освен да имате добри идеи, трябва да можете да разпознавате добрите идеи на вашите потребители. Понякога последното е по-важно.

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

(Когато изнасях лекция на конференцията за Perl през август 1997, Лари Уол беше на първия ред. Като стигнах до предния параграф, той извика в библейски стил "Кажи им, кажи им, братко!" Цялата публика се разсмя, защото знаеха, че така стана и с човека, измислил Perl.)

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

Има обаче още два основни урока, които са общи за всякакъв вид начинания.

12. Често най-изненадващите и новаторски решения се получават, когато човек осъзнае, че концепцията му за проблема е грешна.

Бях се опитвал да реша грешния проблем, като продължавах да разработвам popclient; като комбинация на MTA и MDA с всякакви странни начини за локална доставка на поща. Структурата на fetchmail трябваше да се проектира наново като чисто MTA приложение, част от нормалния път за доставка на поща през SMTP.

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

Точно това направих и аз. Очевидно правилното решение беше: (1) да се добави пренасочване към SMTP, (2) по подразбиране да се установява този режим. и (3) да се махнат всички други режими за доставка и най-вече тези към файл и стандартен изход.

Известно време се колебаех за стъпка 3, защото се страхувах да не разочаровам потребителите, разчитащи на алтернативните режими за доставка. На теория можеха веднага да преминат на .forward файлове или еквиваленти, за да получат същия резултат. На практика преходът можеше да се окаже по-заплетен.

Когато се реших, ползата се оказа огромна. Най-тромавите части от драйвера изчезнаха. Конфигурирането стана значително по-просто – не се налагаше да се уточняват системен MDA и потребителска пощенска кутия, нито пък да се тревожа дали операционната система поддържа заключване на файлове.

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

Освен това се подобри производителността (макар и не толкова, че да се забележи от пръв поглед). Друго не съвсем незначително предимство беше, че ръководството към програмата стана много по-просто.

По-късно трябваше да върна възможността за доставяне на поща чрез посочен от потребителя MDA, за да могат да се обработват някои неясни ситуации, отнасящи се до динамичен SLIP. Обаче намерих много по-прост начин да го направя.

Поуката? Не се колебайте да изхвърлите излишни части, ако това може да стане без загуба на ефективността. Антоан дьо Сент-Екзюпери (който бил авиатор и проектант на самолети, когато не се занимавал с писане на класически детски книжки) казал:

13. "Съвършенство (в проектирането) не се постига, когато няма какво да се добави, а когато няма какво повече да се махне."

Когато кодът ви става и по-добър, и по-прост, значи сте на прав път. А и по този начин fetchmail придоби свой собствен характер, различен от неговия предшественик popclient.

Беше време за смяна на името. Новият дизайн приличаше много повече на sendmail, отколкото popclient – и двете програми бяха MTA приложения, но докато sendmail просто изпраща поща, новият popclient: първо я изтегляше и след това я препращаше. И тъй, два месеца след като започнах проекта, преименувах програмата на fetchmail.

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

Дори и на по-високо ниво на проектиране може да бъде много полезно да има множество сътрудници, които да оглеждат структурата на вашия продукт. Представете си как езерце вода намира точка на оттичане, или още по-добре, как мравки търсят храна – на практика случайно изследване на средата, последвано от използване на намерения източник, като между двете има гъвкава система за комуникация. Този подход работи много добре – както стана с мен и Хари Хокхайзер, на някой от сътрудниците ви, може да му хрумне супер идея, която вие сте пропуснали, защото сте фокусирани малко по-тясно. 
 

7. Fetchmail пораства

Вече си имах изчистен и оригинален проект – код, за който знаех, че работи добре, защото го използвах всеки ден, както и нарастващ списък от бета-тестери. Бавно ме осени идеята, че вече не се занимавам с тривиална програмка, която може случайно да се окаже полезна за няколко души. Имах програма. от която всеки потребител на Unix със SLIP/PPP поща би могъл да се нуждае.

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

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

Анди Таненбаум имаше оригиналната идея да направи прост Unix за IBM PC, който да използва като учебно помагало. Линус Торвалдс доведе концепцията за Minix по-далеч, отколкото Анди вероятно си е представял – и тя се превърна в нещо чудесно. По същия начин (макар и в по-малък мащаб) аз взех някои идеи от Карл Харис и Хари Хокхайзер и ги разработих усилено. Нито един от нас не беше "оригинален" по онзи романтичен начин, който хората смятат за гениален. И всъщност, повечето научни, технически и софтуерни разработки не се дължат на чист гений, противно на хакерската митология.

Тъй или иначе, резултатите бяха доста напредничави – всъщност, точно онзи успех в живота, за който всеки хакер мечтае! А това означаваше, че ще трябва да поставя стандартите си още по-високо. За да направя fetchmail на нивото, на което вече виждах, че може да бъде, трябваше да реализирам не само нещата, от които аз се нуждаех, но и такива, които биха се използвали от други. При това програмата трябваше да си остане проста й стабилна.

Първата и несъмнено най-важна характеристика, която написах след като осъзнах това, беше поддръжката на multidrop – възможността да се изтегля поща от общата кутия на група потребители и след това да се разпраща на отделните получатели.

Реших да добавя тази възможност отчасти защото някои потребители ме врънкаха за нея, но най-вече защото си мислех, че така ще махна някои грешки от кода, понеже щеше да се наложи да се справям с адресирането на пощата в пълния му вид. Така и се оказа. Да накарам обработката на адреси (така, както е описана в RFC 822, http://info.internet.isi.edu:80/in-notes/rfc/files/rfc822.txt) да работи правилно ми отне доста дълго време, не защото отделните аспекти са трудни, а защото трябва да се имат предвид купища зависими един от друг дребни детайли. Все пак multidrop адресирането се оказа отлично решение. Така разбрах, че

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

Неочакваната полза в случая се оказа възможността за поддръжка на mailing list като самия списък и alias-файловете се пазят върху клиентската страна на SLIP/PPP връзката. Това означава, че някой с лична машина, свързана към ISP, може да поддържа mailing list без да му се налага непрекъснато да се обръща към alias-файловете на доставчика.

Друга важна промяна, за която настояваха бета-тестерите, беше поддръжката на работа с 8-битов MIME. Това беше доста лесно, защото се бях старал да запазвам осмия бит навсякъде. Не защото очаквах, че ще ми трябва в бъдеще, по-скоро следвах друго правило:

15. Когато пишете междинна програма от какъвто и да е вид, старайте се да променяте потока данни колкото може по-малко – и никога не изхвърляйте информация, освен ако получателят не ви накара.

Ако не бях следвал това правило, поддръжката на 8-битов MIME щеше да бъде трудна и пълна с грешки. Сега обаче трябваше само да прочета RFC 1652 (http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1652.txt) и да добавя тривиален код за генериране на подходящ header.

Някои потребители от Европа ме врънкаха да добавя възможност за ограничаване броя на съобщенията, изтеглени за една сесия (за да могат да контролират по-скъпите си телефонни сметки). Съпротивлявах се на това доста дълго, и все още не съм много щастлив от това. Но ако пишеш за света, трябва да слушаш клиентите си – това не се променя само защото не ти плащат. 
 

8. Още няколко урока от Fetchmail

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

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

Всичко започна като късен нощен експеримент, когато забелязах как декларациите в rc-файловете започват много да приличат на мини-език. (Това беше и причината да сменя ключовата дума "server" в оригиналния popclient на "poll").

Струваше ми се, че ако се опитам да направя този език по-близък до нормален текст, ще го направя по-лесен за използване. Макар че съм твърд привърженик на школата "щом може, нека е език", както в случая с Emacs, HTML и много системи за бази данни, обикновено не съм голям почитател на близките до човешкия езици.

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

Това обаче не е причината обикновено да избягвам синтаксис, близък до нормален английски; тук я споменавам, само за да я опровергая. При днешните евтини машини краткостта на израза не трябва да е самоцел. Днес е по-важно един език да е удобен за хората, отколкото да се обработва лесно от компютъра.

Все пак има причини човек да е предпазлив. Едната е сложността на обработката – тя не трябва да достига точка, в която е значителен източник на грешки и объркване сред потребителите. Другата причина е, че за да се направи един синтаксис "подобен на нормален език", често означава въпросният "нормален" език да е доста изкривен, дори до степен, в която външната прилика с естествен език е толкова объркваща, колкото би бил и традиционен синтаксис. (Това си личи в много от тъй наречените езици от "четвърто поколение" за описване на заявки към бази данни).

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

16. Ако правите език, който далеч не е еквивалентен на машина на Тюринг, може да си позволите разточителство в синтаксиса му.

Друг урок в свързан със защита чрез скриване на информация. Някои потребители на fetchmail ме молиха да съхранявам паролите кодирани в rc-файла, за да не могат натрапници да ги открият.

Не го направих, защото това не добавя никаква защита. Всеки, които се е добрал до права да чете гс-файла, ще може да изпълни и fetchmail – а ако му трябва паролата ви, ще извади декодиращия код от самия fetchmail.

Всичко, което кодирането на паролите във файла .fetchmailrc би направило, е да даде фалшиво чувство на сигурност на хората, които не мислят много-много. Общото правило е:

17. Една система за защита е сигурна само докато остава в тайна. Пазете се от псевдо-тайни. 
 

9. Необходими предпоставки за базарния стил

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

Достатъчно очевидно е, че един проект не може от самото начало да започне в базарен стил. Така може да се тества, да се откриват грешки и да се правят подобрения, но би било много трудно да се започне. Линус не се е опитвал да прави това. Хората трябва да имат нещо работещо, с което да си играят.

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

Linux и fetchmail излязоха на бял свят със силни и привлекателни основни възможности. Много хора, които мислят за базарният модел по подобен начин, правилно усещат, че това е много важно и правят заключението, че е задължително този, който води проекта, да е много умен и да има силна интуиция

Но Линус заимства своя проект от Unix. Аз взех моя от popclient (макар че след това той се промени много, при това в доста по-голяма степен, отколкото Linux). Трябва ли координаторът на един отворен проект наистина да има изключителен талант или просто да може да използва таланта на другите?

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

Както Linux. така и fetchmail са пример за това. Линус, макар и да не е (както стана дума по-рано) изключително оригинален, показа способността си да разпознава добрите идеи и да ги включва в ядрото на Linux. А аз вече описах как най-важната идея за fetchmail (препращането към SMTP) ми беше дадена от някой друг.

Ранните читатели на този документ ме похвалиха, като предположиха, че съм склонен да омаловажавам оригиналността на базарните проекти, защото се оправям доста добре сам и поради това го смятам за даденост. Може би има известна истина в това – проектирането (за разлика от кодирането и поправката на грешки) със сигурност е най-силното ми качество.

Но проблемът с хитростите и оригиналността в проектирането на софтуер е, че те стават навик – човек започва да прави нещата хитри и сложни, вместо да ги държи стабилни и прости. Случвало ми се е да затъвам с проекти поради тази грешка, но при fetchmail успях да избягна това.

Ето защо вярвам, че fetchmail успя отчасти защото се въздържах да се правя на хитър; това може да служи като аргумент, че оригиналността не е от съществено значение за базарните проекти. Вземете и Linux. Представете си, че Линус Торвалдс се беше опитал да прави фундаментални открития в дизайна на операционни системи – щеше ли да бъде вероятно полученото ядро да е толкова стабилно и успешно като сегашното?

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

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

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

Не е случайно, че Линус е симпатяга, който кара хората да го харесват и да искат да му помогнат. Не е случайно и че аз съм енергичен екстроверт, който се радва да работи в екип и има някои от чертите и инстинктите на комик. За да работи базарният модел, умението поне малко да се очароват хората е от огромна помощ. 
 

10. Социалният контекст на софтуера с отворен код

Вярно е писано: най-добрите програми започват като личните решения на ежедневните проблеми на автора им и се разпространяват, защото се оказва, че са типични за голям клас потребители. Което ни довежда до правило номер 1, изказано може би по-полезно така:

18. За да решите интересен проблем, започнете оттам да намерите проблем, който ви е интересен лично на вас.

Така беше с Карл Харис и неговия popclient, така беше и с мен и fetchmail. Но това е известно от много време. Интересното нещо, това, на което изглежда историите на Linux и fetchmail изискват да се обърне внимание, е следващият етап – еволюцията на софтуера в присъствието на голяма и активна общност от потребители и сътрудници.

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

Класическата "Психология на компютърното програмиране" на Джералд Уайнберг предлага една основна корекция на Брукс. В неговата дискусия на "самоотверженото програмиране", Уайнберг отбелязва, че ако разработчиците 
не държат кода си затворен, а насърчават други да търсят грешки и потенциални подобрения, въпросните подобрения се правят драстично по-бързо, отколкото другаде.

Изборът на термините, използвани от Уайнберг, може би е причина анализът му да не получи признанието, което заслужава – описанието на Интернет хакерите като "самоотвержени" предизвиква усмивка. Но мисля, че твърденията му изглеждат по-смислени днес отколкото когато и да било.

Историята на Unux би трябвало да ни подготви за това. което научихме от Linux (и което експериментално проверих в по-малък мащаб като нарочно копирах методите на Линус). Тоест, макар писането на програми да остава по същество самостоятелна дейност, наистина големите неща се получават като се привлече вниманието и умствената мощ на цяла една общност. Разработчик, който използва ума си в затворен проект, ще изостане в сравнение с този, който знае как да създаде отворен, еволюиращ контекст, в който обратната връзка по отношение на архитектурата, кода, откриването на грешки и други подобрения става от страна на стотици (може би дори хиляди) хора.

Но традиционният свят на Unix не позволяваше този подход да се докара до край по няколко причини. Едната беше законовите ограничения на различните лицензи, търговски тайни и комерсиални интереси. Друга (в ретроспекция) беше, че Интернет все още не беше достатъчно развита.

Преди Интернет да стане достатъчно евтина, имаше няколко концентрирани в географско отношение общности, където се насърчаваше "самоотверженото" програмиране на Уайнберг. Bell Labs, лабораторията по изкуствен интелект в MIT, университета в Berkeley – те станаха дом на проекти, които са легендарни и все още жизнеспособни. 
 

Linux беше първият проект, който направи сериозен и успешен опит да използва целия свят като източник на талант. Не мисля, че е съвпадение факта. че раждането на Linux стана по времето, когато се роди World Wide Web, и че Linux напусна детството си в същия период през 1993-1994, когато се разви ISP индустрията и интересът към Интернет нарасна експлозивно. Линус беше първият човек, който се научи как да играе по новите правила, които вездесъщата Интернет направи възможни.

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

Какъв обаче е този стил и какви са тези правила? Те не могат да са базирани да силови взаимоотношения – а дори и да можеха, ръководството чрез принуда не би дало резултатите, които виждаме. Уайнберг цитира автобиографията на руския анархист от 19-ти век Пьотр Алексеевич Кропоткин "Мемоарите на един революционер" като добър пример за това:

"Тъй като бях отгледан в семейството на притежател на крепостни селяни, навлязох в активен живот, както и всички млади хора по моето време, с доста голяма увереност в необходимостта от нареждане, заповеди, порицания, наказания и тем подобни. Но когато още на ранен етап се наложи да ръководя сериозни начинания и да работя със [свободни] хора, и когато всяка грешка водеше веднага до големи последствия, започнах да оценявам разликата в действията, основани на заповеди и дисциплина, и тези, основани на принципите на общо разбирателство. Първото работи великолепно във военна обстановка, но не струва нищо в реалния живот, където резултат може да бъде постигнат само чрез големи усилия от страна на много хора с еднаква цел."

"Големите усилия на много хора с еднаква цел" е точно това, което изисква един проект като Linux – а "действията, основани на заповеди" са на практика невъзможни за приложение сред доброволци от този рай на анархистите, който наричаме Интернет. За да работят и да се конкурират ефективно, хакери, които искат да водят отворени проекти, трябва да се научат как да набират и насърчават общности по начина, който Кропоткин неясно нарича "принцип на общо разбирателство". Те трябва да се научат да използват закона на Линус.

По-рано се позовах на "ефекта на Делфи" като вероятно обяснение за закона на Линус. Но по-мощни аналогии с адаптивни системи в биологията и икономиката сами се налагат. Светът на Linux се държи в много отношения като свободен пазар или екологична система, сбор от егоистични агенти, които се опитват да извлекат максимална полза, което предизвиква спонтанна самокоригираща се организация, по-сложна и ефективна отколкото би постигнало каквото и да е централно планиране. Тогава точно тук е мястото, където трябва да се търси "принципа на общо разбирателство".

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

Линус, като се поставя успешно в ролята на "пазител" на проект, при който разработката се прави главно от други хора, и като подхранва интереса към него, докато проекта стане способен да се самоподдържа, показва отлично разбиране на "принципа за разбирателство" на Кропоткин. Този квази-икономически поглед върху света на Linux ни позволява да видим как се прилага въпросното разбирателство.

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

Много хора (особено тези, които по принцип не вярват в свободните пазари) биха очаквали една общност от самостоятелно действащи егоисти да е фрагментирана, разпокъсана, прахосническа, потайна и враждебна. Такива очаквания обаче се опровергават от (и това е само един от примерите) смайващото разнообразие, качество и дълбочина на документацията на Linux. Тя е цяло чудо, като се има пред вид, че програмистите мразят да пишат документация. Тогава как се получава така, че Linux хакерите са написали толкова много? Очевидно свободният пазар на "репутация" при Linux работи по-добре за налагането на добродетелно, насочено към другите поведение, отколкото масивно спонсорираната документация на производителите на комерсиален софтуер.

Както fetchmail, така и ядрото на Linux показват, че като се задоволява егото на много други хакери, един силен разработчик/координатор може да използва Интернет. за да получи предимствата на многото разработчици без да допусне проекта да се превърне в хаотична каша. Затова на закона на Брукс предлагам да противопоставим следното:

19. При условие, че координаторът на разработката има среда, добра поне колкото Интернет, и знае как да ръководи, без да принуждава, много глави са неизбежно по-добре от една.

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

А може би и не само бъдещето на отворения код. Никой затворен производител на софтуер не може да се сравнява с таланта, който общността на Linux може да отдаде за решаването на даден проблем. Много малко могат дори да си позволят да наемат повече от 200-те (а през 1999-та и 600) души, които допринесоха за разработката на fetchmail.

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

11. За управлението и линията Мажино

Първоначалната статия "Катедралата и базарът" свършваше с горната визия – щастливи тълпи от програмисти-анархисти, свързани с Интернет, задминаващи йерархичния свят на конвенционалния затворен софтуер.

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

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

В този аргумент със сигурност има нещо. Всъщност във "Вълшебното гърне" (The Magic Cauldron, http://www.tuxedo.org/~esr/writings/magic-cauldron/) разработих идеята, че очакваната бъдеща стойност на поддръжката е ключът към икономиката на софтуерното производство.

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

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

Каквато и да е тя, със сигурност не включва надеждно приключване в срок, вместване в рамките на бюджет, или реализация на планирания набор от характеристики. Рядко един "управляван" проект изпълнява дори една от тези цели, да не говорим за всичките три. Изглежда, че ползата не е и способност за адаптация към промени в технологиите и икономическия контекст по време на живота на проекта – отворените проекти се оказват много по-ефективни в това отношение (както може да види човек, ако сравни например 30-годишната история на Интернет с краткия полуживот на затворените мрежови технологии, или пък цената за преминаване от 16 към 32 бита в Microsoft Windows в сравнение с почти безпроблемната миграция на Linux през същия период, не само на платформите, базирани на Intel, а и на повече от десет други хардуерни платформи, включително 64-битовата Alpha).

Едно нещо, което според хората може да им даде традиционното разработване е, че има някой, който да държат отговорен по закон и от който може потенциално да се иска компенсация, ако нещата се объркат. Но това е илюзия повечето софтуерни лицензи изрично отричат всякаква отговорност, да не говорим за гаранции за работоспособност – а случаите на успешна компенсация за неработоспособен продукт са изключително и все по-редки. Но дори и да не беше така, едва ли смисълът на цялата работа е в това да се чувстваш удобно, защото има кого да съдиш. Хората не искат съдебни процеси, а работещ софтуер.

Тогава каква е ползата от тъй наречения мениджмънт?

За да разберем това, трябва да видим какво вярват че правят мениджърите на софтуерните разработки. Една жена, която познавам, и която изглежда е доста добра в тази работа, казва, че управлението на един софтуерен проект има пет функции:

1. Да дефинира целите и да държи всички ориентирани в една и съща посока.

2. Да наблюдава внимателно разработката и да се увери, че няма да се пропуснат критични подробности.

3. Да мотивира хората да вършат скучна, но необходима черна работа.

4. Да организира нещата така, че да се постигне максимална производителност.

5. Да се управляват ресурсите, необходими за поддръжката на проекта.

Очевидно смислени цели, всяка една от тях. Но в модела на отворен код и неговия социален контекст те започват да изглеждат странно не на място. Ще ги разгледаме в обратен ред.

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

Така или иначе в един свят на евтини PC-та и бързи Интернет връзки по-често се оказва, че единствения ограничаващ ресурс е квалифицираното внимание. Когато отворените проекти замират, това на практика никога не става поради липса на машини, връзка или офис-пространство. Те престават да се развиват само когато самите разработчици загубят интерес. 
 

При това положение, двойно по-важно е участниците в един отворен проект да се организират за максимална производителност чрез самоизбиране – а социалната среда е такава, че се търси изключителна компетентност. Моята позната, наясно както със света на отворения код, така и с големи затворени проекти, вярва, че отворените програми са успешни отчасти защото тяхната култура приема само най-талантливите 5% или там някъде от всички програмисти. Тя прекарва повечето от времето си, като организира работата на останалите 95%, тъй че знае от първа ръка разликата в горе-долу 100-те процента производителност между най-способните програмисти, и просто компетентните такива.

Тази разлика винаги е повдигала неудобния въпрос: дали на индивидуалните проекти, а и на тази област като цяло, няма да им е по-добре без повече от 50-те процента от най-малко способните? Предвидливите мениджъри отдавна са разбрали, че ако единствената цел на конвенционалния мениджмънт в софтуерното производство беше да превръща най-малко способните от чиста загуба в минимална печалба, цялата работа може и да не си струва.

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

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

Обикновено този отговор върви заедно с твърдението, че на отворени проекти може да се разчита само, ако трябва да се върши привлекателна и интересна работа; всичко друго би останало настрана (или недоправено), освен ако не се изстиска от парично мотивирани пионки, с мениджъри, размахващи камшик над тях. Психологичните и социалните причини, които ме карат да се отнасям скептично към това твърдение, съм изложил в "Homesteading the Noosphere". За настоящите ни цели обаче, мисля че е по-интересно да видим какви биха били следствията, ако го приемем за вярно.

Ако конвенционалният, затворен, силно управляван стил на софтуерна разработка се защитава наистина само от един вид линия Мажино – проблеми, които водят до скука, тогава той би останал жизнеспособен в някоя индивидуална област само, докато не се намери някой, намиращ проблема за наистина интересен и никой друг не намира начин да го заобиколи. Защото в момента, в който се появи отворен проект – конкуренция на "скучен" софтуер, клиентите ще знаят, че с него се е захванал човек, избрал точно този проблем заради самия него – което, както и при другите видове творческа работа, е много по-ефективен мотиватор от парите сами по себе си. (Интересно дали има отворени проекти за счетоводен софтуер? – бел. прев.)

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

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

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

Малко трудно е да се приеме този възглед. И причината не е толкова в доказателствата в полза на отворения код (дългия живот на Emacs, или способността на Линус Торвалдс да мобилизира орди разработчици с приказки за "световно господство"). По-скоро проблемът е в изключителната неспособност на конвенционалните механизми да дефинират цели за софтуерните проекти.

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

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

Тогава нашият отговор към традиционния мениджър на софтуерни разработки е прост – ако отворената общност наистина подценява ползата от конвенционален мениджмънт, защо толкова много от вас показват презрение към работата си?

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

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

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

Ето защо да свързваш работата си със страх и ненавист (дори и това да се изразява само в закачането на шеговити карикатури и картички по стените) трябва само по себе си да се счита за знак. че цялата работа е пропаднала. Удоволствието, хуморът и игривостта са наистина ценни неща – по-горе не споменах "щастливите орди" само заради хубавия израз, и не е просто шега, че символът на Linux е гушкав симпатичен пингвин.

Може дори да се окаже, че най-важният ефект от успеха на отворения софтуер е да ни научи, че играта е икономически най-ефективният начин за творческа работа. 
 

12. Благодарности

Този документ беше подобряван след разговорите ми с много хора, които ми помогнаха да оправя грешките в него. Особено съм благодарен на Джеф Дътки (dutky@wam.umd.edu). който предложи формулировката за паралелността на дебъгването и ми помогна да разработя анализа, който следва от нея. Също така на Нанси Лебовиц (nancyl@universe.digex.net) за предложението й да подражавам на Уайбърг като цитирам Кропоткин. Значителна критика дойде и от Джоан Езлингер (wombat@kilimanjaro.engr.sgi.com) и Марти Франц (marty@net-link.net). Глен Ванденбург (glv@vandenburg.org) посочи значението на самоизбирането на участниците и предложи плодотворната идея, че голяма част от разработката отива за оправяне на грешки от рода "пропуснати характеристики"; Даниел Апър (uper@peak.org) предложи естествените аналогии за това. Благодарен съм и на членовете на PLUG, групата на Linux-потребителите от Филаделфия (Philadelphia Linux User’s Group), които осигуриха първата пробна публика, пред която беше представена устната версия на този документ. Паула Матушек (matusp00@mh.us.sbphrd.com) ме осветли относно практиката на софтуерното инженерство. Фил Хъдсън (phil.hudson@iname.com) ми напомни че социалната организация на хакерската култура отразява структурата на нейния софтуер и обратно. И най-накрая, коментарите на Линус Торвалдс бяха полезни, а ранното му одобрение – особено окуражаващо. 
 

13. За допълнително четене

Цитирах няколко откъса от класическата книга на Фредерик П. Брукс "Митичният човекомесец" (Frederick P. Brooks, 'The Mythical Man-Month"), защото в много отношения неговите прозрения тепърва ще се подобряват. Сърдечно препоръчвам юбилейното издание на Addison-Wesley(ISBN 0-201-83595-9), което включва и неговото съчинение "Без сребърен куршум" (No Silver Bullet) от 1996 година.

Новото издание завършва с безценна 20-годишна ретроспекция, в която Брукс признава няколкото грешни преценки в оригиналния текст, които не издържаха проверката на времето. Прочетох тази ретроспекция след като първата публична версия на настоящата статия беше на практика готова и бях доста изненадан да науча, че Брукс приписва някои характеристики на отворено разработване на Microsoft! (Всъщност се оказа, че това е било погрешно. През 1998 научихме от колекцията Halloween (http://www.opensource.org/halloween/), че вътрешната организация в Microsoft е строго фиксирана, като общият достъп до изходен код, необходим за поддръжката на базарен стил, изобщо не е възможен.)

"Психология на компютърното програмиране" на Джералд М. Уайнбърг (Gerald M. Weinberg, "The Psycology of Computer Programming", New York, Van Nostrand Reinhold 1971) въвежда доста неудачно формулираната концепция за "самоотвержено програмиране". Макар той да не първият човек, осъзнал безполезността на "принципа на командване", вероятно той е първият, който свързва този въпрос с разработката на софтуер.

Ричард П. Гейбриъл, който разглежда Unix културата отпреди времето на Linux, с нежелание признава превъзходството на примитивен базарен модел в своето съчинение "Lisp: добри новини, лоши новини и как да спечелим много" (Lisp: Good News, Bad News And How to Win Big) от 1989 година. Макар да е остаряло в някои отношения, това есе все още се радва на популярност сред много почитатели на Lisp (включително и мен). Един мой кореспондент ми напомни, че секцията, озаглавена "По-лошото е на добре" изглежда почти като предсказание за Linix. Този документ е достъпен по WWW на адрес http://www.naggum.no/worse-is-better.html.

"Peopleware: Продуктивни проекти и екипи" на Де Марко и Листер (De Marco and Lister, " Peopleware: Productive Projects and Teams", New York, Dorset House, 1987, ISBN 0-932633-05-6) е недооценено бижу и бях доволен, че Фред Брукс го цитира в ретроспекцията си. Макар малка част от това, което пише вътре, да е директно приложимо към Linux или отворения код, прозренията на авторите за условията, необходими за творческа работа, са особено ясни и полезни за всеки, който се опитва да пренесе част от предимствата на базарния стил в комерсиален контекст.

Най-накрая трябва да призная, че на косъм не озаглавих това съчинение "Катедралата и агората", като последното (agora) е гръцки термин за отворен пазар или място за обществени срещи. "Агоричните системи" на Марк Милър и Ерик Дрекслър, които описват свойствата на "пазарни" изчислителни екологии. ми помогнаха да мисля ясно ,за аналогичните феномени в културата на отворения код, когато Linux ме въвлече в тази работа пет години по-късно. Тези документи са достъпни в Web на адрес http://www.agorics.com/agorpapers.html. 
 

14. Епилог: Netscape прегръща базара

Странно е чувството, че човек помага да се напише историята...

На 22 януари 1998, почти седем месеца след като публикувах за пръв път "Катедралата и базарът", Netscape Communications Inc. съобщи плановете си да отвори изходните кодове на Netscape Comunicator (http://www.netscape.com/newsref/pr/newsrelease558.html). Нямах никаква представа за това преди да прочета съобщението.

Ерик Хан, изпълнителен вицепрезидент, и главен технологичен директор на Netscape, ми изпрати малко след това писмо, в което пишеше: "от страна на всички в Netscape бих искал първо да ти благодаря, че ни помогна да стигнем до тук. Твоят начин на мислене и твоите статии бяха основният източник на вдъхновение, за да вземем нашето решение."

Следващата седмица отлетях до Силициевата долина по покана на Netscape, за да участвам в еднодневна конференция (на 4 февруари 1998) за определяне на тяхната стратегия. В нея участваха някои от висшите служители, както и технически специалисти. Заедно проектирахме стратегията за отваряне на Netscape и съответния лиценз.

Няколко дена по-късно писах следното:

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

От друга страна, това е една изключителна възможност. Първоначалната реакция на Уол Стрийт, както и другаде, беше предпазливо позитивна. Освен това ни дават шанс да се докажем. Ако чрез този ход Netscape си възвърне значителна част от пазарния дял, това може стане началото на една отдавна просрочена революция в софтуерната индустрия.

Следващата година би трябвало да е много поучително и интересно време."

И тя наистина се оказа такава. Като пиша тези редове сега, в средата на 1999, разработката на по-късно наименованата Mozilla, се оказа безспорен успех. Тя постигна първоначалната цел на Netscape, която беше да отхвърли монопола на Microsoft върху пазара на браузърите. Освен това постигна и някои драматични успехи (най-вече пускането на рендиращият енджин от ново поколение Gecko).

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

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

Действително е така. Дългосрочните прогнози за Mozilla изглеждат доста по-добре сега (през август 1999) отколкото по времето, когато Джейми Завински подаде оставката си – но той беше прав, като отбеляза, че отварянето на кода няма непременно да спаси един съществуващ проект, страдащ от зле дефинирани цели, разбъркан код или която и да е друга хронична болест на софтуерните продукти. Mozolla се оказа едновременно пример за това как един отворен проект може да успее и как може да се провали.

Междувременно идеята за отворен код пожъна успехи и последователи другаде. 1998 и 1999 година показаха експлозивно нарастване на интереса към отворения модел на разработка, което се предизвиква и на своя страна увеличава успеха на операционната система Linux. Насоката, дадена от Mozilla, се развива все по-бурно. 
 

15. Бележки

[JB] В "Програмистки бисери" известният компютърен афорист Джон Бентли коментира забележката на Брукс по следния начин "Ако мислите да изхвърлите нещо, ще изхвърлите две." Почти със сигурност е прав. Смисълът на забележката на Брукс, както и на Бентли, не е просто, че би трябвало да се очаква първият опит да е грешен, а че започването наново с правилната идея обикновено е по-ефективно от опита да се спаси една каша.

[QR] Примери за успешни отворени разработки в базарен стил, предшестващи експлозията на Интернет и несвързани с традициите на Unix и Интернет, са съществували. Разработката на компресиращата програма info-Zip (http://www.cdrom.com/pub/infozip/) в периода 1990-1992, предимно за DOS, е един такъв пример. Друг е системата RBBS (също за DOS), която беше започната през 1983 и събра край себе си достатъчно стабилна общност, за да има доста редовни нови версии и досега (средата на 1999) въпреки огромните технически предимства на Интернет пощата и обмяната на файлове по локални BBS. Разработчиците на info-Zip разчитаха до известна степен на електронна поща, докато RBBS си имаше своя инфраструктура, напълно независима от TCP/IP.

[JH] Джон Хаслър предложи интересно обяснение на факта, че дублирането на работата изглежда не засяга отворените проекти. Ще нарека неговото предложение "Закон на Хаслър": загубите поради дублиране на работата нарастват по-бавно от квадрата на броя разработчици, тоест по-бавно от допълнителното планиране и ръководство, необходими за избягването им.

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

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

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

[IN] Един въпрос, свързан с това дали един проект може да започне от нулата в базарен стил, е дали базарният стил може да подържа наистина творческа работа. Някои твърдят, че при липсата на силно ръководство, базарният стил може да се справи само с клонирането и подобряването на идеи, които вече са известни и използвани, но не е способен да развие нови. Този аргумент е може би най-известно формулиран в документите от Хелоуийн (http://www.opensource.org/halloween/), два смущаващи вътрешни меморандума на Microsoft: за отвореното разработване. Авторите сравняват разработката на Linux с непрекъсната гонитба, защото "(след като един проект се е изравнил с най-новите разработки в областта), нивото на управление, необходимо за постигането на нови хоризонти, става огромно."

В това твърдение има няколко сериозни фактологически грешки. Една от тях личи, когато авторите сами отбелязват по-късно, че "често [...] нови експериментални идеи се реализират и са достъпни първо на Linux преди да се интегрират в други платформи."

Ако заместим "Linux" с "отворен код", ще видим, че това далеч не е ново явление. Исторически погледнато, отворената общност не е измислила Emacs или Word wide Web или самата Интернет като е подражавала на други или като е имала солидно ръководство. А понастоящем има толкова много нови идеи, разработвани под формата на отворен код, че човек да се чуди кое да избере. Проектът GNOME (да вземем един от многото за пример) разширява границите на понятието "графичен интерфейс" и има достатъчно солидна обектноориентирана технология, за да привлече значително внимание в пресата извън общността на Linux. Други примери има със шепи, както би показало едно посещение на Freshmeat (http://freshmeat.net) в който и да е момент.

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

Някои биха определили това като романтичен възглед, връщане към остарелия стереотип на самотния изобретател. Не е така – аз не твърдя, че групите от хора са неспособни да развиват революционните идеи след като те веднъж са се появили. Всъщност такива групи са необходими за постигане на качествен резултат. Аз само посочвам, че всяка такава група започва – задължително се запалва - от една добра идея в главата на един човек. Катедралите и базарите, както и другите социални структури, могат да подхванат тази искра и да я оформят, но не мотат да я предизвикат при поискване.

Ето защо основният проблем на изобретателството (в софтуера, или където и да е другаде) е как да не изгасим тази искра – и дори още по-важно. как да отгледаме много хора, които имат нови идеи.

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

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

Това обаче е негативен пример. На читателя ще му послужи по-добре положителен такъв. Предлагам като експеримент следното:

1. Изберете си критерии за оригиналност, който смятате, че ще можете да прилагате обективно. Ако дефиницията ви е "като го видя, ще го позная" това не е проблем за целите на настоящия тест.

2. Изберете си някоя операционна система със затворен код, която е конкурент на Linux, както и най-добрият източник на новини за текущата работа по нея.

3. Наблюдавайте този. код и Freshmeat! в продължение на един месец. Всеки ден бройте съобщенията във Freshmeat, които според вас са "оригинална" работа. Приложете същата дефиниция на "оригинален" към съобщенията за другата операционна система и ги пребройте.

4. След трийсет дни съберете общите суми.

В деня, когато написах това, на Freshmeat имаше двайсет и две съобщения, от които три изглежда можеха да се окажат революционни в даден аспект. Това беше оскъден ден за Freshmeat. но ще съм изненадан, ако някой читател ми посочи поне три възможни нововъведения на месец в някой затворен канал.

[EGCS] Вече имаме проект, който по няколко начина може да се окаже по-добър тест на базарната практика отколкото fetchmail. Това е EGCS (http://egcs.sygnus.com/). Experimental GNU Compiler System – експерименталният компилатор на GNU.

Проектът беше обявен в средата на август 1997 като съзнателен опит да се приложат идеите от ранните публични версии на "Катедралата и базарът". Основателите на проекта чувстваха, че разработката на GCC, C-компилаторът на GNU, е в застой. За около двайсет месеца след това GCC и EGCS продължиха като паралелни продукти – и двата черпеха от една и съща база разработчици по Интернет, и двата започваха от изходните кодове на GCC, и двата използваха до голяма степен едни и същи Unux инструменти и среда за разработка. Проектите се различаваха само това. че GCC запази по-катедрална организация със затворена група разработчици и не толкова чести нови версии.

Това беше един контролиран експеримент, доколкото изобщо е възможно, и резултатите бяха драматични. Само за няколко месеца версиите на EGCC бяха напреднали доста по отношение на характеристики – по-добра оптимизация, по-добра поддръжка на Фортран и C++. Много хора намериха EGCC за по-надежден от последните стабилни версии на GCC, и основни Linux дистрибуции започнаха да преминават към EGCC.

През април 1999 Free Software Foundation (официалните спонсори на GCC) разпуснаха първоначалната група по разработката на GCC и официално предадоха проекта на екипа, отговарящ за EGCC.

[SP] Разбира се, критиката на Кропоткин и Законът на Линус повдигат някои по-широки въпроси относно кибернетиката на социалните организации. Друга теорема на софтуерното производство подсказва един от тях. Законът на Конуей – обикновено във вида "Ако по един компилатор работят четири екипа разработчици, ще се получи 4-пасов компилатор." Оригиналният вид е малко по-общ: "Организации, проектиращи системи, са ограничени да произвеждат само такива, които копират комуникационните структури в тези организации." По-сбито можем да го кажем така: "Средствата определят целите" или дори "Процесът става продукт".

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

Частта за еднаквите права е съществена за производителността на въпросната общност. Идеята, която Кропоткин се опитва да формулира относно силовите взаимоотношения, се разработва по-нататък от принципа SNAFU: "Истинска комуникация е възможна само между равнопоставени хора, защото подчинените често се награждават, ако приказват на началниците си приятни лъжи, а не истината". Творческата работа в екип зависи съществено от наличието на истинска комуникация и затова една йерархия е сериозна пречка. Отвореното разработване, на практика без никакви взаимоотношения началник-подчинен, ни показва чрез контраст колко ужасно много може да струва една йерархия, измерено в бъгове, ниска производителност и загубени възможности.

Освен това, принципът SNAFU предсказва все по-силно откъсване от реалността на тези, които вземат решения, тъй като все по-голяма част от това, което чуват, се оказва приятни лъжи. Начинът, по който това се отразява на конвенционалното разработване на софтуер, се вижда лесно. Има силни стимули нискостоящите да крият, пренебрегват и минимизират проблемите. Когато този процес се превърне в продукт, полученият софтуер е истинска катастрофа. 
 

16. Версия и история на промемите

$Id: cathedral-bazaar.sgml, v 1.46 1999/08/08 02:21:32 esr Exp $

Изнесох версия 1.16 на Конгреса на Linux, 21 май 1997.

Добавих библиографията на 7 юли 1997 във версия 1.20.

Добавих анекдота за конференцията на Perl на 18 ноември 1997 във версия 1.27.

Промених "безплатен софтуер" на "отворен код" на 9 февруари 1998 във версия 1.29.

Добавих "Епилог: Netscape прегръща базара" на 10 февруари 1998 във версия 1.31.

Махнах графиката на Пол Егърт за GPL срещу базара в отговор на убедителни аргументи от RMS, на 28 юли 1998.

Добавих корекция на Брукс, базирана на документите Хелоуийн, на 20 ноември 1998 във версия 1.40.

Добавих секцията "За управлението и линията Мажино", някои размисли за ползата от базарния стил по отношение на програмната архитектура, и значително подобрих епилога във версия 1.44, в края на юли 1999.

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

Другите ревизии включват дребни редакции и поправки на текста.

Източник: http://www.savanne.ch/svoboda/anarchy/theory/bazaar.html

[Avatara]

Здравейте,

Няколко пъти прочетох внимателно както превода, така и оригинала на написаното от Ерик Реймън. Определено има доста моменти, които аз не мога да приема, най-вече като непосредствен свидетел на определени събития.

Нека подложим на анализ само пасажа, касаещ Netscape Communications Inc.

Това, което авторът пропуска, че по време на визирания в есето период, компанията е подложена на сериозен натиск от страна на Web Standards Project (WaSP), който в момента познавате като консорциум (не е грешка, именно консорциум)  World Wide Web Consortium (W3C), чиито цели са ясно дефинирани.

Мисля, че е излишно да споменавам, че не друг а AOL, "погълна" и на практика ликвидира Netscape, оставяйки и развивайки само и единствено Mozilla Foundation и провеждайки масирана медийна кампания за "ползите" от "свободното и открито" програмиране. Влиянието на W3C е много силно в Европа, но това има съвсем елементарно обяснение. В Континентална Европа, Великобритания и САЩ стандартите са препоръчителни, което е различно от патентното законодателство, което е много различно за UK и САЩ и Централна Европа. Реално това бе едно перфектно проведено оперативно мероприятие, щедро финансирано от държавния бюджет на САЩ.

 

Разбирам емоциите на автора, но действителността е твърде сурова. За да бъде узаконена вашата разработка (та дори да е написана на Linux) ще е нужно да се сдобиете със следните документи:

• Чернова на сертификацията (Draft)
• Работен проект (Working Draft)
• Последно известие (моля за извинение за превода, но на английски е Last Call)
• Възможна рекомендация (Candidate Recommendation)
• Предлагана рекомендация (Proposed Recommendation)

Дори да разполагате с всичко това, W3C си запазва правото да не ви предостави рекомендация, което реално обезмисля, всичко, което сте направили. Целият положен труд ще бъде заличен, а вие ще бъдете подложен на жестоки подигравки в специализираните форуми. Още по-лошо ще стане, ако проявите упорство и преминете от другата страна и решите да се противопоставите на статуквото.

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

 

Съвсем друга е темата за авторски права и патентите.

 

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

Логиката на "узаконения грабеж" ми е добре позната. Повярвайте към момента ме считат за един от най-жестоко ограбените IT специалисти в света. Дори Microsoft не са ги крали толкова, колкото мен, но най-забавно е, че сред тези, които са го вършили ще срещнете имената на много фондации, за които авторът пише.

От друга страна това е повод за гордост.

Все пак се краде това, което има някаква стойност, нали?

 

С уважение

 

Avatara

 

 

 

[kall]

Хубавата черта на всичко що е отворен код е тази, че тези системи се развиват със свои собствени темпове и всяка по свой си път. Интересно е да се наблюдава, еволюция в действие извън биологичния свят:-)

[Avatara]

Из "Теоретични аспекти на вярата"

. . .

 

Първи принцип на Герасимов за системите с отворен код:

(взаимстван от филмите за Джеймс Борн, и слабостта му към произведения в жанра на нео-кибер-пънка)

Всяка система с отворен код се подчинява на нарежданията, спуснати от АНС (англ.National Security Agency / Central Security Service, NSA / CSS) *.

* Този принцип е в сила независимо от това в какво вярват потребителите и разработчиците.

 

Основно следствие на първия принцип на Герасимов за системите с отворен код:

(за любителите на конспирации  препоръчвам последния филм за упоменатия Джеймс Борн, за да навлязат в същността на тезата)

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

 

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

 

Пример за величието на съюза в сферата на отворения код между Nokia и Mozilla:

Battery Status API

И ако не разбирате за какво говоря, то нека видим какво казват по въпроса тези, които се възползват от него.

 

Интересни виждания на Шанкар Ведантам (Shankar Vedantam) и Кара Алисън (Kara McGuirk-Alison), свързани с нашумяло мобилно приложение, което си е чиста проба далавера:

This is you brain on UBER

А за тези, които все още се опитват да докажат как Chrome, Mozilla Firefox и Opera са "много, ама много по cool от гадния IE" горещо препоръчвам да вземат да си сменят зададеното по подразбиране значение TRUE на  dom.battery.enabled във FALSE.

За съжаления за Crome това няма как да стане, но вие не се отчайвайте.

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

Що се отнася до безсмъртната и бронирана вяра в Linux, обещавам да ви запозная с доклад от една конференция в Канада от 2003 година, както и с една разпечатка от 2016 година. Много е интересно да се прочете какво пишат колегите от Intel, за тази OS и най-вече за това, което ядрото и прави. Ще останeте очаровани, колко стриктно Linux Fondation се придържа към стандартите на United States Department of Defense (по нашенски Пентагон, но на латински това означава нещо, за което не е редно да се говори). Няма да повярвате какво усърдие влагат разработчиците в благородното си начинание да следват пътя на Силата. 

 

[Avatara]

Здравейте,

 

Преди няколко дни ми се наложи да проведа беседа с колеги юристи занимаващи се с въпросите на защитата на авторски права при системите с отворен код. Това, което се наложи да обсъждаме в детайли е лиценза MIT. Мисля да отделя специално внимание на темата, защото определено е много важно.

 

А дотогава вижте какво могат системите със "затворен код" и така омразното за българските програмисти Delphi. Клипът показва само малка част от това, което може да се направи с RAD Studio и Firemonkey.

Вярно, че не е като да е написано с Ruby, Python, Java, C# и пр, но не е лесно да сочиш пътя на другите, нали?

Малък пример на Delphi (със "затворен код")

 

Редактирано Октомври 1, 2016 от Avatara

[Avatara]

Понякога няма да ме разбирате какво пиша или какво говоря.

Причината за това е, че всяка моя теза се основава на определен вид ресурс и познание.

Понякога публикувам примери, които остават неразбрани. Предлагам да пробвате ето това:

https://www.embarcadero.com/products/delphi/starter/promotional-download/?&utm_source=Facebook_Paid&utm_medium=social&utm_campaign=100OFF_Delphi_DesktopOnly

Знам, че тук няма FireMonkey, както и всичко свързано с iOS и Android, но поне ще може да се докоснете до съвременна технология (визирам такава от 2016 година, а не от края на 90-те на миналия век). Безплатно и поне ще може да водим актуална дискусия.

За мен въпросът: "Как се прави?" е много по-важен от: "как се ползва?" и "Как функционира?". 

 

[Avatara]

За тези, за които Linux e религия, a Delphi е мръсна дума. 

 

https://community.embarcadero.com/blogs/entry/setting-up-ubuntu-server-for-the-delphi-on-linux-beta

 

Понеже от години чета как Delphi (RAD студио и де що е производна) "умира" искам да кажа, че не се случи точно така. 

Добрата новина е, че Starter Edition както за Delphi, така и за C++ са напълно безплатни.

Дръпнете си ги и сами ще усетите предимствата на професионалната среда за разработка.

Това, което установих за себе си, че Firedac с лекота се справя с бази данни с размер от няколко десетки TByte (не е грешка при това става дума на бази данни на Firebird), да не говорим за възможностите, които библиотеката за паралелни изчисления предоставя.

Ако наистина сте професионалисти, просто опитайте. Няма да съжалявате.

 

 

[Captain Nemo]

Преди 3 минути, Avatara said:

За тези, за които Linux e религия, a Delphi е мръсна дума. 

 

https://community.embarcadero.com/blogs/entry/setting-up-ubuntu-server-for-the-delphi-on-linux-beta

 

Понеже от години чета как Delphi (RAD студио и де що е производна) "умира" искам да кажа, че не се случи точно така. 

Добрата новина е, че Starter Edition както за Delphi, така и за C++ са напълно безплатни.

Дръпнете си ги и сами ще усетите предимствата на професионалната среда за разработка.

Това, което установих за себе си, че Firedac с лекота се справя с бази данни с размер от няколко десетки TByte (не е грешка при това става дума на бази данни на Firebird), да не говорим за възможностите, които библиотеката за паралелни изчисления предоставя.

Ако наистина сте професионалисти, просто опитайте. Няма да съжалявате.

 

 

С какво IDE е по-добър от Еклипс или Нетбийнс? Каква е скалируемостта и отказоустойчивостта на базата? Колко TPS могат да се постигнат (са постигани практически)? Как стои въпроса с поддръжката (защото за корпоративните клиенти това ще е първия въпрос)?

[Avatara]

Веднага отговарям. 

На DX мога да направя всичко което IDE Java прави без никакво изключение, и без да се налага да пренаписвам код (много ми е интереснo да видя какви оператори има в Java за работа с множества в т.ч. такива  с размита логика, примерно, но това е друга тема).

Най-лесно е това да се извърши посредством малко допълнение, като това, но изборът е много по-богат (просто този лично на мен ми допада най-много).

http://winsoft.sk/java4delphi.htm

Помня Eclipce, когато все още се разработваше от IBM в рамките на   Visual Age (IBM са ми слабост, заради техният Composer, който бе прекрасен компонент на Web Sphere). 

Идеята при Eclipce беше да се разработват приложения за IBM на различни програмни езици. 

Концепцията при RX и DX е диаметрално противоположна - един език и неограничен брой платформи, без да се налагат изменения в кода.

Вярно, че при Eclipce с OSGi нещата леко се промениха. Ако не ме лъже паметта тазгодишният  Simultaneous Release на Eclipce се нарича Neon и в него има много съществени подобрения, но все пак става дума за нещо много различно. Eclipce е прекрасна платформа за разработка на разширения на съществуващи приложения. В този ред на мисли създадените от QNX  Java Development Tools (JDT), C/C++ Development Tools (CDT) са много добри. Но когато говорим за корпоративни решения и Eclipce трябва да споменем Swordfish.

Когато говорим за NetBeans трябва да разбираме Oracle, нали така? 

За да работите обаче с NetBeans ще се наложи да инсталирате Sun JDK или J2EE SDK, с всички произтичащи от това последици (това е тема, която е предмет на доста сериозна дискусия). Все пак трябва да приемем, че ако говорим за професионални приложения е много по-добре да ползваме Java Studio Enterprice. 

Ако обаче говорим за наистина сериозни разработки и NetBeans ще се наложи да споменем и Oracle Solaris Studio, а това означава, че освен C++ (за къде без него) ще се наложи да споменем и Fortran, а самото споменаване на този език за програмиране в България може да доведе до психоделична реакция (шегувам се). 

От друга страна има малка (но съществена) разлика между  NetBeans Visual Library и FireMonkey и VSX.

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

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

Скалируемост ...

Много забавна дума. Разширяваме, но плащаме колкото се може по-малко. Като знам колко струват т.н. "консултантски услуги" на бизнеса (аз работя в реалния сектор) ми настръхва косата. Въпросът е, че годината е 2016 (ако не греша) и тенденциите в реалната икономика (най-вече стратегическите) са доста различни от тези от края на 8--те и началото на 90-те години на миналия век. Модерният термин в момента е къстомизация (от custom design). Все пак masproduction в реалната икономика имаме през XiX век, а от тогава до сега сме се развивали, нали? 

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

Въпросът за скаларуемостта е въпрос на икономическа стратегия и е комплексен, а не само и единствено въпрос на платформа.

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

Отказоустойчивост ... на база (поне аз така го разбрах, но се извинявам ако греша) ...

Предполагам, че визирате Firebird? 

Firebird е безкрайно интересна като СУБД. Да започнем с разликите в начина, по който се извършва индексирането във FB и това в DB2, Oracle, MySQL и др.. Разликата е фундаментална. Да не говорим за преносимост, мащабируемост, отказоустойчивост и пр. и пр. и пр.. При Firebird това е много ... елементарно, което го прави невероятно надеждно. Най-вече за БД над 40 GByte. Аз лично в момента работя с няколко промишлени бази, всякa от които е над 40 TByte и нямам проблем.

Ако обаче говорим за Firedac то това е нещо съвсем различно. 

За Firedac няма значение "какво стои отзад". Дали това е Oracle, Subbase, Intrabase, My SQL, DB2 или неструктурирана БД няма значение. Просто, леко и ... безкрайно ефективно решение.

Темата е доста обширна.

Но все пак искам да подчертая, че не може да правим сравнение между несравними неща. Все пак аз говоря за съвременни средства с мощен апарат за паралелна (не "многопоточна" а именно "паралелна" обработка, което е нещо съвсем различно), аз разглеждам средство за разработка (а не инструмент за поддръжка) и т.н..

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

Наистина въпросите са много актуални, а темата е безкрайно интересна.

Тази дискусия ми доставя невероятно удоволствие, за което Ви благодаря.

С уважение

Георги Тодоров Герасимов

CSA NGIT

 

 

 

 

 

Редактирано Декември 22, 2016 от Avatara

[Captain Nemo]

Нека да изясним няколко понятия, които мисля вие интерпретирате малко свободно (всъщност доста)

(дефинициите са мои и съм готов да дискутирам по тях)

Скалируемост - възможност един и същ софтуер да се приложи при голям диапазон от ситуации. Примерно база данни, което поддържа от 3 таблици с по 100 реда, до 100к таблици с по 100Г реда (в някои от тях). Обикновено бива два вида, хоризонтална и вертикална. За вертикална DB2, Oracle DB са много добър пример. Ако имате нужда от повече производителност ползвате по-мощна машина. За хоризонтална hadoop и splink са класически пример. И не можете да ме уплашите с 40ТБ, само една от оракълските бази, които ползвам е толкова А hadoop базите, които поддържам  съдържат съдържат (всяка) над 100ТБ информация. Та въпроса ми беше по-скоро  Firebird колко практически може да се скалира, с каква производителност и на каква цена (говорейки в контекста на корпоративни клиенти)

Отказоустойчивост - не видях някакъв пример за това как Firebird би работил в HA обкръжение. Аз ползвам за Oracle 3 нода в RAC. За продукти, които са над 99.5 говорим за 4 нода в два клъстера. Какво предлага Firebird

 

П.П. И за много други софтуери, които ползвам няма значение какъв е бекенда (да живее JDBC) :D

[Avatara]

Уважаеми Немо,

От последният Ви пост разбрах, че когато говорите за "скалируемост" Вие визирате само и единствено СУБД. Моля да ме извините, но в разглежданията си аз съм анализирал термина малко по разширено. Това навярно се дължи на факта, че едно време ни учеха, че при Finite State Machine (FSM или казано по-просто: едносесийно мрежово съединение) броят на използваните процесори не влияе на скалируемостта както и при използването на нишки (threads). Мисля, че във втория случай моделът може да се окаже не само нескалируем, но и  дори неефективен, най-вече при някои ОС, които за да не Ви ядосам няма да споменавам.

Това си го изясних, но моля да ме извините, че не съм убеден в правотата на тезата, че за по-добра производителност е нужна по-добра машина. .

Тук ако ми позволите ще вметна малка забележка. Има грешки, които се дефинират като "политически" (това е термина).

Когато говорим за "отказоустойчивост" и "производителност" при системи трябва да имаме предвид редица фактори, за да може да дадем отговор на много въпроси. Съгласете се, че ако нямате непрекъсваемо захранване, при изключване на ел.захранването ще имате сериозни проблеми (дори да ползвате Oracle) и нулева производителност, дори при най-модерната архитектура. Ако неправилно сте проектирали системата за превключване на токовите кръгове, ще имате още по-сериозни проблеми при включване на ел.захранването, а това ще генерира и огромни щети. Тези въпроси нямат нищо общо със СУБД. Да не споменаваме за спецификите на различните ОС (все пак има сериозни различия между Sun Solaris и RedHat и Novel SUSE примерно). Да не споменавам настройките на апаратната част и ОС, които трябва да се направят. Съвсем дръг е въпросът за т.н. "вътрешна свързаност" защото ако ползвате контролери с 40 Gbit скорост на обмен и мрежа с cat.5 нещата няма да се получат. Но съдейки по написаното от Вас, разбирам чв Вие сте сериозен експерт и имате доста богат опит и приемам, че аз не разбирам правилно въпросите Ви, за което моля да бъда извинен. 

Явно аз съм разбрал следното:

Вие визирате High Availability cluster (HA) или казано на разбираем български език "отказоустойчив клъстер". За незапознатите, това е група от сървъри, която е проектирана така, че да позволява висока степен на достъпност при минимално време за престой. Ако това го няма е възможнно приложенията и мрежовите сървиси да се окажат недостъпни в един момент, а това не е желателно.

Това обаче автоматично ни препраща към термини като Network Attached Storage (NAS) и Storage Area Network (SAN), а това според мен (ще извините невежеството ми) са архитектурни решения.

Алгоритмите за въстановяване след отказ (поне доколкото съм запознат) са Apache Cassandra и Hector, но и те имат само коствена връзка с използваната СУБД. 

Oracle Real Application Clusters е софтуер на Oracle и касае основно Oracle RDBMS (обектно-релационната система на компанията Oracle). 

С оглед на гореизложеното не виждам как мога да посоча "пример" който да е релевантен. Все пак говорим за доста различни неща, а както вече писах няма  как те да бъдат сравнявани. Ако следвам тази логика би следвало да ставняваме самолет с лек автомобил, просто защото и двете са превозни средства.

Познаването на различията е важно. Това важи с огромна сила при технологиите за т.н. "вътрешна диагностика". Лично аз имам наблюдения върху тези на Intel, но от колеги съм чувал много интересни неща за Asus, които са впечатляващи. От друга страна да се разглежда апаратната част като нещо самостоятелно, когато говорим за устойчивост и производителност на една система е неразумно. Дори компания като NEC, която произвежда сървъри от висок клас си сътрудничи с EMC. Това е сериозна тема и аз се отнасям към нея сериозно.

Сега за цената ...

Искам пак да попитам нали разбрахте, че аз говоря за Firedac и Firebird?

Firedac има цена, когато е enterprice и това е нормално. Firebird не се продава и никога не се е продавала. За това има доста добре написани лицензионни договори. В момента може да се ползва както стандартен сървър (clasic) така и суперсървър до версия 3.0.1. Има 32/64 Bit версии за Windows и версии за Linux.

. . .

Лично за мен "backend" (задна част) звучи доста двусмислено.

Редно е да споменем, че в случая визираме логиката, която изпълнява това, което крайният потребител изисква. Да, но има много по точен термин, когато става дума за приложения, който се нарича "слой на бизнес логиката" или BUS. Това е онова нещо, което се намира между представителния слой (или "тънкия" клиент) и DAO (как само звучи, а).   

В този ред на мисли да запитам при СУБД редовете не се ли наричаха "записи" (records), а колоните "полета" (fields)?

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

Все пак ако не ми изневерява паметта (извинете, но напоследък много забравям) при писането на код и избор на език трябва да бъдем много внимателни най-вече в частта стратегия.

Няма как да не знаете, че Java и други функционални езици изискват да се събира "боклука", докато императивните такива като C, C++ (който не е C), Delphi (който не е Pascal), Fortran и др. вършат това "почистване" съвсем самостоятелно. Малка разлика, но за хора като мен много полезна. Има и други, но в момента не си ги спомням. Гинкобилобата струва скъпо, а пенсията вечно недостига.

Наистина е приятно да дискутираме тази тема.

С уважение

Георги Тодоров Георасимов

(скромен български полуинтелигент)

 

P.S. Славия - шампион, но едва ли ще доживея това да се случи.

 

[Captain Nemo]

Започвайки отзад напред:

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

При С++ също има форма на събиране на боклука, която не е съвсем самостоятелна И зле приложена може да докара доста проблеми. И С++, джава са ОО езици, а не функционални. Нито С е такъв. https://en.wikipedia.org/wiki/Functional_programming

Когато правя сравненията се опитвам да дефинирам абстрактно нещата, както казах дали има единична машина или цял клъстер за мен достъпа (от middleware) е jdbc.

Така че просто проучвам как стоят нещата с това, което вие предлагате. А ако говорим за приложни сървъри (в корпоративния свят) никой няма да смени jboss, weblogic, websphere с нещо друго. Наречете го закостенялост, но това е положението.

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

Говорейки за ОС в корпоративния свят много рядко ще срещнете Windows. Там можете да видите AIX, HP-UX, Solaris, Linux. И при тях скалируемоста е на ниво. Да, вертикалната не е линейна (особено при линукс) но е достатъчно добра (поне за целите за които го ползваме)

[Avatara]

Уважаеми Nemo,

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

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

Ако не греша в предходния си пост ясно съм споменал Sun Solaris, RedHat, Novel SUSE и Linux в съвсем конкретен контекст на изложението. Windows е споменат при дистрибуциатя на Firebird.

Моля да ме извините, но аз съм обикновен инженер и по тази причина не съм в състояние да анализирам абстрактни (добре, че не са имагенерни) определения. Аз работя със стандарти и технологични карти.  Аз нищо не предлагам. Не съм търговец и никога не съм бил. 

Що се отнася до C по добре да се цитират Керниган и Ричи и това, което са написали. Относно C++ може просто да си изтеглите някои от последните доистрибутиви на RC (дори някой от 2015 година ще свърши работа) и след внимателен анализ отново да се върнем на тази тема. Извинете ме, но лично за мен Wikipedia не е сериозен източник, по ред причини.

От последния Ви пост оставам с впечатление, че Вие концентрирате вниманието си изцяло и единствено върху web-базирани приложения. Поправете ме ако греша. Ако говорим само и единствено за web, то ще се постарая да премина на една друга плоскост. Все пак до момента аз визирам въпроси, свързани с архитектурни концепции, а не само и единствено web. Пак повтарям, че говорим за много различни неща. Вие започнахте с бази от данни, а сега говорите за web (от big data към web, дори за мен е малко плашещо). И тъй като споменахте за web сървъри, работещи като обратни проксита (reverse proxy), ми стана безкрайно интересно. Това, което аз знам за използването на Reverse Proxy е следното (поправете ме ако съм допуснал грешка): 

• Намаляване на натоварването на web сървъра,  посредством кеширане на съдържанието*  (web accelerator);
• Позволява да бъде намаленио времето за достъп до web ресурса (не визирам само сайтове);
• Разпределяне на натоварването, в случай че ползваме повече от един web сървър, но трафика преминава през proxy;
• Защита от общи web-базирани атаки;
• В случай на необходимост компресиране на съдържанието. 

На практика имаме типичен web-ускорител, който няма нищо общо с инструментите за разработка.

Тези ускорители може и да са част от бизнес логиката, но това не е задължително. За да ме разберете, има огромна разлика между това да ползвате Apache Traffic Server или Squid (типични Reverse Proxy) и това Вие сам да напишете имплементиран Reverce Proxy модул. Това са много различни неща. Аз знам какво е Varnish и Nginx, но също така знам каво е някой да напиша свой собствен proxy сървър, също толкова добре както  да напише REST-сървър. Ще се радвам, ако ми покажете свои разработки. Това определено е от голям интерес за мен. От години следя всичко свързано с оптимизацията на трафика.

С пожелания за един прекрасен ден.

С уважение

Георги Тодоров Герасимов

(заядлив старец със сприхав нрав)

* По принцип reverce proxy сървърите основно кешират, но това е друга тема.

 

 

[Captain Nemo]

За терминологията съм съгласен. И нека всеки представи своите определения за нещата. Така ще дадем възможност на четящите да "видят" повече от една гледна точка

 

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

 

За обратното прокси:

- обикновено кеширането е на последно място. До сега само в един проект се наложи да ползваме нещо такова и то по-скоро проксито да предоставя статичното съдържание вместо да "пита" middleware за него

- времето за достъп не се променя съществено, защото така и така проксито чака отговора от машините зад него за да го подаде на клиента

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

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

- компресирането обикновено не е съществено, разчита се по-скоро на "груба сила" под формата на честотна лента и процесорна мощност

 

А защо смесвам уеб, бази данни, приложни сървъри. Ами (поне в работата ми) те са тясно свързани и няма как да се говори за едното без да се спомене друго. И няма как да изграждате архитектура на подобна система без да тръгнете от желязото и стигнете до слой 7

[Avatara]

Напълно съм съгласен с гореизложеното.

Мдааа ... Мобилните оператори.

Познати са ми. Eдин от тях разположи UPS-модулите си на петия етаж в сградата на ДНА в Стара Загора. Допълнително ускъпяване в резултат на подсилване на плочата с двойни T-образни профили, монтаж на телфер и пр. и пр..

Лично за мен най-голямата дивотия е използването на СВЧ-сигнали за пренос на информация. Много скъпа поддръжка, ниска ефективност, да не говорим за т.н. "странични ефекти". Тепърва ще се заплаща цената за лудостта наречена GSM комуникация. Но тази цена ще бъде висока и определено няма да оправдае никакви "печалби". В армията когато се работи със СВЧ, независимо от мощността (подчертавам това, защото то е много важно) винаги се съблюдават определени предписания.

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

От "големите" познавам Tektronix, Rоhde&Schwarz (ученическа любов), както и някои по-малко известни, но определено интересни компании. Като се замисля, ако попитате някой за Philips (примерно), едва ли ще може да Ви каже какво точно произвеждат и това е разбираемо.

Sun познавам от техните "мобилни дейтацентрове". Двадесет или четиридесет футови контейнери. Талигите за тях се произвеждат в Tatra Vagonka в Югославия. Самикте контейнери също се комплектоват в района. Производителност няколко десетки пет флопса и капацитет от няколко стотин петабайта. Има такива, които се монтират на камиони, но те са по-малки.

Microsoft, Motorola, IBМ, General Electric и др. са от редовните ни клиенти.

Като цяло, колегите са изключително ерудирани специалисти и прекрасни хора.

Истината е, че както Sun, така и много други са в някаква степен зависими от това, което правим.

Понякога се шегуваме, че сме неизбежни като смъртта, но реално гледаме да не се занимаваме с хора извън системата. Те са прекалено сложни за разбиранията ни. Ние сме просто устроени и още по-прости като начин на мислене.

Много Ви благодаря за дискусията. За мен тя е от голяма полза.

Желая Ви весели празници и щастлива Нова година.

С уважение

Г.Т.Герасимов

CSA NGIT

 

 

[Captain Nemo]

Четейки за Катедралата и базара се сетих за нещо, което съм писал в 2005 година. Стана ми интересно как някои неща са се променили кардинално. И как други неща са си същите. Надявам се че ще представлява интерес за някого

-------------

Linux в страната на Десктопите
или
могат ли пингвините да чупят прозорци?

Имаше времена, когато на Linux не се гледаше сериозно и според тежките хора бе по-скоро нещо за развлечение в свободното време. Но дойдоха времена, когато тази операционна система има по-голям дял на сървърния пазар от всички UNIX операционни системи взети заедно. А дали е дошло времето да бъде завладяно и бюрото на потребителя?

----------------------

Целия текст тук: http://www.geocities.ws/romeo_ninov/articles/desktop1.html

[Avatara]

Много хубава статия.

 

[Avatara]

Моля да бъда извинен, но все пак аз оставам с някои резерви относно развитието на Linux като операционна система.

Като начало ще посоча само факта, че и до момента при Linux (както и при UNIX) се наблюдава нещо, което е в тотален разрез с наука, известна като "Метрология".

Според Linux денят се състои от 86400 секунди, което от гледна точка на упоменатата наука не се счита за коректно.

Пример:

На 19.01.2038 година променливата time_t, която отчита секундите от 01.01.1970 год. ще достигне стойност от 2 на степен 31, което грубо казано ще доведе до ... отрицателно време.

Забавно, но факт. 

Да се борави на Linux с милисекунди (или с микро) си е сериозно изпитание. Да, но съвременните машини с CPU оперират с милисекунди, което е сериозно препятствие при разработка на професионални CAM (Computer Aided Manufacturing) системи. 

Има и още нещо, за което в Linux Foundation не обичат да говорят - въпросът какви графични стандарти ползват? Тук имаше няколко доста забавни куриоза, като в един от случаите се стигна до сериозни пререкания с голяма компания за разработка на графична периферия.

За мен Linux e (и ще бъде) една от многото сървърни платформи. Мисля, че би следвало да продължи да се усъвършенства. Не е допустимо и до момента грешка, за която всички алармират от 2011 година, да не е отстранена, още повече, че тя допуска да се получи неоторизиран достъп като root администратор.

Има и по-фрапиращи неща.

Горещо препоръчвам прекрасният труд на Рамеш Хатараджан (Ramesh Natarajan) "Linux 101 haks".

http://langevin.univ-tln.fr/cours/UPS/extra/Linux-101-Hacks.pdf

Същвствува и една "специфична" група от проблеми, с които Linux ще трябва да се справи. За съжаление всички те са свързани с TEMPEST (Transient Electromagnetic Pulse Emanation Standard). Тепърва предстои покриване на изискванията на MIL, NTISSI, NATO SDIP и др..

Когато човек държи на някого или на нещо, той прави всичко възможно за да му помага. Обичам Linux, но не мога да си затварям очите пред проблемите. Това би било предателство към самата идея. В момента ми се налага да работя със сървъри (списъкът е над 370 странници), някои от, които са толкова екзотични, че е трудно да се повярва, че човешка мисъл би могла да роди нещо подобно. Ако Linux продължи да следва настоящата линия на развитие, в един момент ще последва Novell, с всички произтичащи от това последици. Все пак не друг а именно Microsoft са основен донор на Linux (както и Cisco, Fujitsu, HP, Huawei, IBM, Intel, NEC, Oracle, Samsung, а такива "спонсори" не дават нищо просто така) а само преди година един от членовете на ръководството на компанията ясно заяви, цитирам: "Време е да изрежем това зловредно образование.". Лошо е, че колкото и да не ми харесва (а и съдейки по това, което се случва с активното оборудване, ползващо Linux, през последните месеци) активно се работи в това направление и едва ли това е еднолично решение.  

Моето лично мнение е, че Linux трябва да се върне към здравите си корени. Мисля, че е време да се извърши реформа на ниво ядро. Визирам истинска сериозна реформа, в която да видя реална паралелна обработка, а не многонишковост, която ми се представя за "паралелност". Искам да видя възможност за работа в реално време. Искам да видя един различен подход в управлението на интерфейсите. Искам да видя нормална поддръжка на 10 G мрежови карти. За съжаление дори компания като Edison вече споделя мнението ми, а това е тревожно.

И понеже стана дума за предишни публикации, аз просто ще приведа един цитат, без коментар:

" ... Ако обаче се върнем 15 (петнадесет) години назад няма как да не си спомним за откритата от Рандал Шварц (Randal L Schwartz), критична уязвимост в много от използваните в Linux библиотеки. От тогава и до днес периодично има сериозни пробиви в сигурността, които биват обяснявани с меко казано, абсурдни аргументи. Обикновенно някой „експерт” ни успокоява и много убедително ни убеждава как, цитирам: „всичко може да се поправи с корекцията на два програмни реда”  ...".

 

 

Редактирано Декември 25, 2016 от Avatara

[Captain Nemo]

Аватар, вие вероятно не сте усетил изцяло насочеността на статията. Това, което дискутирам в нея е дали може линукс да бъде подходяща за десктоп операционна система. Което ще се съгласите няма много общо с метрологията. А за останалите случаи хвърлете едно око на clock_gettime което е Позикс интерфейс към високопрецизни таймери. За 2³¹  няма защо да се притеснявате защото в момента >95% от сървърните ОС са 64-битови и не е особен проблем да се препишат таймерите да работят с 64-битова дума.

Ако мислите че CAM системите са подходящи за ползване на линукс е добре да преосмислите нещата. ТОва е място за слециализирани (или къстомизирани) ОС. С тях ще можете да управлявате нещата в реално време и да имате гарантирано време на отговор. Насочете се примерно към QNX, поне преди време на стандартна 100MHz Пентиум система предлагаха време за отговор на прекъсване до 5 микросекунди (което ще ви е достатъчно за 99.99% от технологичните процеси)

Линукс много трудно може да последва Новел защото това не е компания в общоприетия смисъл. Всеки може да си изтегли сорса на ядрото и да направи свой форк (което води то появата на хиляди, често несъвместими, дистрибуции)..... Така че в този смисъл линукс като ОС няма да изчезне. По-добре се молете компании като RH, Ubuntu да не изчезнат защото те държат голямата част от съвременната сървърна база. А Майкрософт участват в развитието на ядрото за да могат да го ползват в Азур. Въпрос на бизнес

Линукс фондацията се управлява от бизнеса и те налагат развитието в зависимост от бизнес интересите си. Харесва или не, но това е положението.

А поддръжката на конкретен хардуер винаги е било проблем, защото няма много желаещи да пишат драйвери, няма много желаещи да тестват драйверите. Няма и много желаещи да променят архитектурата на ядрото заради нов хардуер.... По повод бързите HBA се сещам един интересен случай в който работата на 10Гб карти под Соларис беше много по-гладка и безпроблемна сравнено с линукс.....

[Avatara]

Никога не съм споменавал, че Linux е подходящ за CAM системи. Все пак знам какво е "промишлен стандарт". 

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

Мисля, че големият проблем тепърва предстои. Доколкото знам не друг, а Huawei купи контролния пакет акции на Cisco и определено скoрo ще погълне и Apple. Китайците имат логика, с която ми се е налагал;о да се сблъскам и тя определено не ми допада. В момента IBM скубят коси заради сделката с Lenovo, но преди години по същата схема загубиха и най-голямото си финансово перо - това на криногренните, измервателни прибори. Когато "бизнесът" управлява загубите са гарантирани (за справка HP). Не случайно Доналд Тръмп поиска среща с ръководството на големите IT компании. Проблемите са сериозни. 

Мдааа ... Няма желаещи да пишат драйвери. Лошо е, че стават все по малко. Друго си е copy/paste ... на отворен код. Не се сърдете, но това е масова практика.Наскоро един колега от Турция изтегли от internet всички свои разработки.

Личните ми притеснения от т.н. "отворен код" е наличието в много от библиотеките на стеганографски записи. Лошо е, че антивирусните не реагират, но това е разбираемо. Все пак става дума за друг принцип на анализ. Лично аз не виждам каква е ползата от "отворения код". Ако някой е професионален разработчик няма как да не знае, че за САЩ (примерно) е нужно кодовете да се регистрират в ECO, а там контролът е много стриктен и се носи наказателна отговорност, ако някой си позволи своеволия. Отворения код, просто заобикаля един правен казус, но ... лично аз имам съмнения, доколко това е от полза не само за потребителите, а за целия IT-сектор. 

Не ме приемайте на сериозно. Просто дискусията ми е приятна.

 

[Captain Nemo]

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

Говорейки за системи в реално време аз съм започнал професионалния си опит с разработката на една такава. Преди доста време беше и тя беше базирана на 6502, 1 MHz, 8 битов процесор. Вярно е че беше много къстъм и следеше и управляваше само 100-тина параметъра но си беше предизвикателство. Писах я изцяло на асемблер (тогава нямах нищо друго) Знам че RTO системите са много специфични и не е лесна промяната там, но конкретно тези с микроядро са достатъчно гъвкави за да могат да бъдат модифицирани за по-дълга дума на някои броячи. Ако се върнем само няколко години назад всички UNIX/Linux ОС (а голяма част от тях и в момента) ползват 16-битов регистър на процесите (PID). Много неща са обвързани в ядрото и userspace с тези номера, но си мисля че би било разумно да се сложи 32-битов регистър за тази цел, така някои управления ще се опростят.

Покупки и продажби стават непрекъснато, ИТ пазара е много динамично нещо и не можем да очакваме че всички сливания, продажби и т.н. ще са разумни. Освен това ние гледаме от по-ниска гледна точка, докато С-левъл мениджмънта има съвсем различно (и невинаги правилно) виждане за нещата :D Конкретно ИБМ продадоха голяма част от бизнеса си, принтери, твърди дискове, ПС, х86 сървъри. В последните няколко години се опитват да се съсредоточат в облачни услуги (с известно закъснение) както и да си поддържат Z и P сериите (големите машини и UNIX машините). Освен това те залагат много на продажби на услуги, поддръжка. Самия аз съм работил в тази компания именно в такъв отдел и имам представа как се развиват там нещата.

За драйверите по мое мнение положението е трагично. Това явно се смята за толкова непрестижна работа и (почти) никой не се занимава с това.. И големите компании (RH, Ubuntu, SuSE) просто публикуват лист на поддържаните хардуери и само срещу заплащане (и то сериозно) са готови да поддържат/пишат драйвери за друг хардуер

Ох, отворения код е голямо и тъмно място.... почти като Ада... Нагледал съм се на какви ли не изпълнения там. И какво като е отворен? Ерик Реймънд може би е бил прав за времето си. Но в момента единици са тези, които биха прегледали сорс кода преди да го сложат на машина(ите) си. Да не говорим че колко могат да прочетат и разберат този код.... Така че едно от основните преимущества се превръща в нонсенс....

[Avatara]

Ох. Така е. С много от нещата е така. 

Като споменахте 5502 си помних за Z80 и определено много доброто решение на старичкия Правец 8М, който съчетаваше в едно тези два процесора. За промишлени цели си беше много добро. Работили сме с немската Sket по проект, който ги ползваше и резултатът беше съвсем приличен.

Не знам дали "облачните" услуги ще донесат кой знае какви печалби, защото бизнесът става все по стиснат и при положение, че може да си купи два диска по 2 TByte (които за един завод са достатъчни), и да плаща някаква заплата на един техник за поддръжка, ще приеме някой да му пази информацията (независимо какво му се обещава).

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

Благодаря ви за отделеното време. За мен тази дискусия е изключително полезна.

Удоволствие е да се обсъжда темата, когато има допълване във възгледите.

 

 

[Captain Nemo]

Z80 беше (и е) много добър процесор. Особено  факта че имаше два набора регистри го правеше особено удобен за обработка на прекъсвания и системи в (почти) реално време. Освен това се произвеждаше със скорост до 8MHz което дръпваше доста напред в сравнение с 6502 (1 мегахерц). Не съм програмирал на него, но съм се дълбал из кодове и съм виждал доста добри неща

По повод облаците - те просто не са подходящи за производство (и не само). При производствени процеси се търси по-скоро постоянност на "услугите" докато облачните такива не могат (лесно и евтино) да осигурят подобни характеристики. В други случаи са много удобни. Аз имам примери от текущата си работа как някои продукти лесно и просто се имплементират в облачни услуги и си работят. Докато други (заради специфични неща като мултикаст например) не могат много лесно да се пуснат. Да не говорим че опита ни да пуснем една услуга в облак показа отчайващи резултати от гледна точка на производителност и проекта просто беше спрян. Освен това ние предлагаме услуги на мобилни оператори (от групата от която сме част) и известна част от информацията е конфиденциална. Което (отново) е предизвикателство за пускането й в облак.

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

Финансовите институции е нормално да не са фенове на облачните услуги именно заради това че голяма част от информацията, която обработват е чувствителна и конфиденциална. И някои от техните подсистеми (примерно core banking) трябва да работят почти в реално време.

Мисля си че в Русия отдръпването от такива услуги е по-скоро заради факта че не много от големите доставчици предлагат съхранение на информацията на територията на Русия. А руснаците не желаят да пазят информация извън своята територия (и извън техния контрол)