Wypromował ją swoim esejem (który potem został przekształcony w książkę) Eric Steven Raymond. Opisałem tę metodykę i praktyczne z nią doświadczenia w artykule: Katedra i Bazar: Jak stworzyć wielki i skomplikowany projekt, gdy masz mało zasobów i ludzi?

W eseju Eric wymienił 19 lekcji wyniesionych z dobrych projektów Open Source. Z wszystkimi się zgadzam, bo większość była, jest lub chciałbym aby była obecna w procesie tworzenia moich systemów. Wkrótce opiszę każdą z nich z własnej perspektywy i w oparciu o własne doświadczenia.p> Wiele z tych lekcji ma zastosowanie również przy tworzeniu produktów wiedzowych.

Na razie tylko lista:

1. Każdy dobry software zaczyna się od czegoś, co zirytowało jego twórcę
2. Dobrzy programiści wiedzą co napisać. Wspaniali wiedzą, co zmienić (lub użyć inaczej).
3. Zaplanuj, że jedną wersję wyrzucisz. Tak się stanie.
4. Jeśli masz właściwe podejście, interesujące problemy same Cię znajdą.
5. Jeśli zgubisz zainteresowanie programem, Twoim ostatnim obowiązkiem jest przekazać go kompetentnemu następcy.
6. Traktowanie Twoich użytkowników jako współtwórców jest najmniej uciążliwą drogą do błyskawicznej poprawy kodu i efektywnego wynajdywania błędów.
7. Wypuszczaj wcześnie. Wypuszczaj często. I słuchaj Twoich Klientów.
8. Zakładając odpowiednio dużą grupę betatesterów i współtwórców, prawie każdy problem zostanie zauważony szybko a rozwiązanie będzie dla kogoś oczywiste.
9. Mądra struktura danych i głupi kod działa znacznie lepiej niż w odwrotnej sytuacji.
10. Jeśli będziesz traktował betatesterów jako Twoje najcenniejszy zasób, zareagują stając się Twoim najcenniejszym zasobem.
11. Najlepszą rzeczą obok wpadania na dobre pomysłów, jest czerpanie dobrych pomysłów od użytkowników. Czasami to drugie jest lepsze.
12. Czasami najbardziej uderzające i innowacyjne rozwiązania są skutkiem zdania sobie sprawy, że Twoje rozumienie problemu było błędne.
13. Perfekcyjny design osiąga się nie wtedy, gdy nie można już nic dodać, ale wtedy, gdy nie ma już czego odjąć. (Antoine de Saint-Exupéry)
14. Każde narzędzie powinno być używane tak, jak je zaprojektowano, ale naprawdę wspaniałe narzędzie często prowadzi do sposobów użycia, których nigdy byś się nie spodziewał
15. Jeśli piszesz program komunikacyjny, wysil się aby modyfikacje treści były możliwie jak najmniejsze - i nigdy nie usuwaj informacji jeśli odbiorca Cię do tego nie zmusza!
16. Jeśli to, co tworzysz ma wiele braków, ubierz to ładnie, aby ludzie nie zwracali na to uwagi.
17. System bezpieczeństwa jest tak bezpieczny, jak jego sekret. Uważaj na pseudo-hasła.
18. Aby rozwiązać interesujący problem, zacznij od szukania problemu, który interesuje Ciebie.
19. Zakładając, że koordynator projektu ma medium komunikacji przynajmniej tak dobre jak Internet i umie prowadzić bez przymusu, więcej głów jest niezwrównanie lepsze niż jedna.