Jarek Żeliński:Marek Kubiś:Cezary Cichocki:Jarek Żeliński:
nie widzę żadnej wartości w tym, ze jakieś naście tysięcy linii kodu (a nie raz znacznie więcej) jest otwarte,
Wartość jest. ;-) Jest nią poczucie bezpieczeństwa klienta, że jak podmiot zniknie / przestanie się interesować tematem / przerasta możliwości wykonawcy i lepiej przekazać innym / .., będzie można temat kontynuować.
mając "zamknięty" produkt wystarczy wybrać taki, który ma wystarczająco stabilnego producenta i sieć partnerów,
No to jest Pan niekonsekwentny. ;-(
Najpierw staje Pan po stronie obrony potrzeby jak najlepszego spełniania wymagań klienta (zgoda), a teraz ogranicza Pan niniejsze tak nieprecyzyjnym jak wystarczająco stabilny producent. ;-( Co się więc tu dziwić, że w szczególności młodzi ludzie, próbując zrobić coś wartościowego wyrażają swoje zdziwienie, że nawet przysłowiowy "pies z kulawą nogą" nie chce na efekt ich pracy spojrzeć, choć oni oferują to za darmo.
Oczywistym jest, że autorzy takich rozwiązań liczą na przychód na usługach okołoproduktowych (nie ma w tym nic złego), ale liczą też na coś dla nich chyba ważniejszego, choćby minimalne zainteresowanie, docenienie choćby dobrym słowem. Przecież zdziwienie dotyczy tego braku zainteresowania, którego jednym z wyjaśnień jest "bo oceniono ciebie, że nie jesteś wystarczająco stabilnym producentem". ;-(
zakładając, że ja osobiście nie będę grzebał w żadnym kodzie
I nie w tym rzecz, że jak piekarz, producent sznurka, księgowy, .. kupią sobie prawo dostępu do kodu, to że mając ten kod będą sobie w nim grzebać. Rzecz w tym, że przy takim zakupie mają prawo przekazać ten kod innemu producentowi oprogramowania, który w zależności od potrzeb będzie miał prawo i możliwość pielęgnacji, .., itd. itp..
Otwartość kodu ma więc znaczenie, tylko nie takie jak się postronnemu obserwatorowi na pierwszy rzut oka może wydawać. Nie widzę uzasadnienia aby mała firma prdukcyjno-handlowo-usługowa kupowała sobie kod źródłowy Windows, Linux, Oracle, .., ale jeżeli dostawcy dedykowanego rozwiązania zaadaptowali w oprogramowaniu obsługę wdrożonych i dobrze funkcjonujących w jej strukturze organizacyjnej procesów, to rozważenie prawa do modyfikacji oprogramowania na wypadek jak komuś temat się znudzi, wg mnie zasadne.
kilka lat temu wybrałem open PHPNuke i niestety panu się znudziło i odstaje strasznie a wtedy był na topie... nie ma gwarancji.
Jak najbardziej, że nie ma gwarancji, ale czego powyższe dowodzi? Wszak znudziło się już niejednemu panu, tak jak i znudziło się nie jednemu podmiotowi ocenionemu jako wystarczająco stabilny. Czyli jak rozczarował jeden mały podmiot to teraz żaden inny mały nigdy szans już nie będzie miał, w przeciwieństwie do korpo, które zawodziły już wielokrotnie a szanse powtórnie dostają? :-(
Brak konsekwencji Panie Jarku w obronie potrzeby jak najlepszego spełniania wymagań klienta. ;-(
Ponadto program, jak każdy inny produkt ma swój czas życia i to że kiedyś trzeba będzie go czymś zastąpić (nową zaktualizowaną wersją?, innym produktem?) pewne jak to że 2x2=4. Płacąc nawet astronomiczne kwoty za produkt, tego czasu się nie wydłuży, więc jak ktoś zawodzi i nie dostarcza właściwego produktu, to chyba najlepiej zrobić szybkie podsumowanie zysków i strat (można porównać z alternatywami) i podjąć bez zbędnych emocji nowe decyzje. ;-)
Dobrym przykładem wydaje mi się tu sytuacja sprzed lat kiedy to IBM stanął przed dylematem wyprodukowania oprogramowania systemu operacyjnego do swojego nowego komputera o nazwie PC. Mogli otworzyć własny dział, mogli kupić dowolnego wystarczająco stabilnego innego producenta oprogramowania, a co zrobili? Zaufali, że to co potrzebują jest w stanie wykonać jeden młody entuzjasta pisania programów bez sieci partnerów o imieniu Bill. Jak produkt zaczął się materializować, aby IBM mógł chłopakowi legalnie zapłacić założył on micro firmę od softu. A jak się biznes zaczął rozwijać to i on stanął na wysokości zadania i znalazł partnerów, bo taka była potrzeba. ;-)))
osobiście preferuje znacznie bezpieczniejszą rozbudowę
No właśnie, przecież
clou to
zaufanie. Buduje się je latami, traci w minuty. Chodzi o to aby umieć właściwie rozpoznać, czy są szanse na spełnienie wymagań klienta. Nie zawsze się musi udać ale warto w coś wierzyć. ;-)
wydaje mi się, że wiele zależy od "metodyki" pracy developera/projektanta, jedni grzebią stale w tym samym kodzie powiększając go inni tworzą kolejne elementy z dostępnych komponentów ale nie grzebią, tylko korzystając z API integrują nowe..
To inne zagadnienie. Osobiście mam zastrzeżenia bo korzystanie z API może być silnie powiązane z bazowaniem na istniejącej logice, a ta przecież może być błędna. Niech każdy postępuje jak uważa właściwie. ;-)
пропозиції роботи
