Być może było ale ... właśnie po raz kolejny "dopadła" mnie reklama (ogłoszenie) firmy oferujące oprogramowanie OpenSource (generalnie chodzi o oprogramowanie biznesowe), skłoniło mnie to do pewnej próby obiektywnej oceny i nasuwa mi się pewien wniosek:
- albo jest to dobre oprogramowanie bardzo źle promowane
- albo jest to po protu gorsze od komercyjnego oprogramowanie
- albo po protu w 100% o jakości końcowego produktu decydują kompetencje ludzi a to ile kosztował kod (i czy w ogóle) nie ma żadnego znaczenia.

dlaczego tak? otóż przejrzałem właśnie (google) kilkanaście ofert i jest pewna prawidłowość: 100% ofert na OpenSource skupia się na haśle "najtańsze" lub "taniej niż komercyjne", zaś oprogramowanie komercyjne w 100% jest promowane w rodzaju "najlepszy", "idealny dla", "wysokiej jakości..."

Może więc jest tak, że po protu nie ma żadnego znaczenia ten "cholerny" kod......

Gdzieś ktoś napisał w reklamie, że koszt kodu to ok. 50%, to chyba dotyczy oprogramowania "z pudełka" takiego za 400zł....

Bardziej chodzi o to, że przy opensource, wykorzystywane są pewne moduły / elementy oprogramowania, które się powielaja funkcjonalnością w wielu aplikacjach i są dostępne dla programistów za darmo. Wystarczy je posklejac do kupy, doszlifować i masz gotowy produkt.

Wiadomo, że będzie to tańsze niż dziobanie analogicznych rozwiązań od początku.
Mniejszy nakład pracy, więc i cena idzie w dół.
Czy lepsze czy gorsze... chyba zależy to od jakości i podejścia wykonawcy aplikacji.

Nie ma jednej reguły mówiącej które jest lepsze a które gorsze. Spotkałem się wielokrotnie ze znakomitą jakością oprogramowania open source (w szczególności gdy dane oprogramowanie ma faktycznie aktywną społeczność).

Nie należy również zapominać o tym że zdecydowana większość oprogramowania komercyjnego również składa się w sporej części z komponentów Open Source - tylko się o tym głośno nie mówi.

Osobiście nie mam żadnych uprzedzeń odnośnie zarówno oprogramowania open source jak i closed source. Decydującym czynnikiem jest co to oprogramowanie faktycznie potrafi, jaki jest jego koszt, wsparcie, itp. itd czyli standardowe czynniki wpływające na zakup.

Odnośnie przekazu marketingowego - hmm - to już pytanie do firm które się tym zajmują. Być może faktycznie największą zaletą danego oprogramowania jest cena. Poza tym - nie zapominajmy że oprogramowanie nie zawsze musi być "najlepsze" - czasami wystarczy że jest "wystarczająco dobre" i kosztuje np. 20% tego co konkurencja.

Witam,

ponieważ nasza firma również oferuje oprogramowanie Open Source, pozwolę sobie także wyrazić opinię na ten temat. Open Source nie jest ani źle promowany, ani gorszy od komercyjnego oprogramowania. Kompetencje firmy wdrożeniowej jak zawsze spełniają kluczową rolę, jednak to jaką funkcjonalność i możliwości oferuje produkt bazowy nie jest bez znaczenia.

Jeżeli zaś chodzi o hasła marketingowe ofert, to powód może być następujący - Open Source jest często kierowany z założenia do sektora MSP. W wielu sytuacjach budżet małych firm nie pozwala na zakup oprogramowania komercyjnego o rozbudowanej funkcjonalności. Jeżeli więc procesy biznesowe zachodzące w małym przedsiębiorstwie są na tyle złożone, że nie wystarcza już Subiekt itp., jedynym rozwiązaniem może być Open Source. Brak opłat licencyjnych lub konieczności tworzenia rozwiązania od zera co realnie zmniejsza koszty. Dodatkowo standardowa stawka konsultantów firm oferujących wsparcie wdrożeniowe produktów Open Source jest ciągle niższa niż w przypadku znanych komercyjnych rozwiązań.

Kolejnym przykładem może być przedsiębiorstwo, które dopiero zaczyna wchodzić na rynek. Z powodu początkowych inwestycji firma nie jest w stanie przeznaczyć milionów na oprogramowanie. Jednak ma ona potencjał, więc pakiet rozwiązań za 300zł może szybko okazać się niewystarczający. W tym przypadku standardowa funkcjonalność produktów Open Source może być dla niej całkowicie wystarczająca. Natomiast wraz z rozwojem firmy i rozszerzeniem asortymentu usług, system może zostać bezproblemowo rozbudowany.

Ponadto warto też zauważyć, iż funkcjonalność oprogramowania biznesowego Open Source jest na tyle ciekawa, iż wiele znaczących korporacji (nawet polskich) decyduje się na ich wykorzystanie jako produktu bazowego. Powodem jest właśnie szukanie oszczędności.

Produkty biznesowe Open Source są także stosunkowo nowym trendem, więc podobnie jak ze wszystkimi nowymi produktami - początkowa droga wejścia na rynek jest dość utrudniona. Zatem żeby odróżnić się od tych wszystkich haseł odnośnie "bycia najlepszym", "idealnym" itp., firmy reklamujące produkt podkreślają także (i chyba dość słusznie) oszczędności jakie ze sobą niesie.

Jeżeli chodzi personalnie o mnie, to bardziej bym obstawała za hasłem "idealny" dla Open Source, ponieważ może on zostać całkowicie dostosowany do potrzeb ;)

50% zdaje się dotyczyło TCO (Total Cost of Ownership), czyli przede wszystkim kosztów licencji i wdrożenia, a nie samego kodu.

Pozdrawiam,
Magda

eVolpe Consulting Group
magdalena.ziebinska@evolpe.pl
evolpe.pl

Magdalena Ziębińska:
Jeżeli chodzi personalnie o mnie, to bardziej bym obstawała za hasłem "idealny" dla Open Source, ponieważ może on zostać całkowicie dostosowany do potrzeb ;)

byłbym bardzo ostrożny z tym "zawsze" - wszystko zależy od typu licencji open source (których jest wiele) oraz ewentualnych (wynikających z licencji) konsekwencji takiego dostosowywania

Jarek Żeliński:
dlaczego tak? otóż przejrzałem właśnie (google) kilkanaście ofert i jest pewna prawidłowość: 100% ofert na OpenSource skupia się na haśle "najtańsze" lub "taniej niż komercyjne", zaś oprogramowanie komercyjne w 100% jest promowane w rodzaju "najlepszy", "idealny dla", "wysokiej jakości..."

Bo komunikację marketingową firmy, która wytwarza oprogramowanie "najlepsze", "idealne dla", "wysokiej jakości..." zwykle prowadzą profesjonaliści, a firm "opensourcowych" zwykle nie. Choć są wyjątki - zobacz sobie nakampanie promocyjną np Firefox'a, choć to nie oprogramowanie biznesowe.

Może więc jest tak, że po protu nie ma żadnego znaczenia ten "cholerny" kod......

Cholerny kod ma cholernie duże znaczenie, bo od niego zależy jakość oprogramowania, jego funkcjonalność, bezpieczeństwo, niezawodność itd.

Gdzieś ktoś napisał w reklamie, że koszt kodu to ok. 50%, to chyba dotyczy oprogramowania "z pudełka" takiego za 400zł....

Zdaje się ok 30%, ale nie pamiętam źródeł.

Dziś prawie wszystko jest w jakieś części "open source". Nawet biznesowe oprogramowanie robione przez największych korzysta z bibliotek i rozwiązań open source. Wszyscy. Banki, ubezpieczalnie, firmy informatyczne na A S C M T Z i inne literki.

Pytanie na jakim poziomie logicznym pojawia się ta "open sourcowość". Czasem językowym - piszą w Javie, ale tworzą swoje frameworki. Czasem korzystają np z JPA, czy Hibernate, Struts czy Faces. Czasem używają pełnych frameworków jak Java Seam, a czasem gotowych rozwiązań, które dostosowują - jak SugarCRM, czy OpenBravo.

Mateusz Kurleto:

Może więc jest tak, że po protu nie ma żadnego znaczenia ten "cholerny" kod......

Cholerny kod ma cholernie duże znaczenie, bo od niego zależy jakość oprogramowania, jego funkcjonalność, bezpieczeństwo, niezawodność itd.

Kod oczywiście ma znaczenia. Natomiast nie ma żadnej gwarancji, że aplikacje kupione za grubą kasę mają ten kod lepiej napisany. Ba... W zamkniętych aplikacjach nie mamy nawet możliwości tego zweryfikować...

Co do samych Open Source, to moim zdaniem nadchodzi złota era tego typu licencji. Korporacje (bo to właśnie one są najmniej przekonane do open sourców) cały czas jeszcze przywiązują zbyt dużą wagę do tak zwanego utrzymania, czy wsparcia. Fakt jest taki, że zdarza się nierzadko drogi soft, który jest podziurawiony bardziej niż niektóre gatunki sera szwajcarskiego... A jak zgłosi się buga to się w odpowiedzi otrzymuje często prośbę o zainstalowanie olejnego service-packa, który się tam kiedyś ukaże... W praktyce dużo szybciej bugi są naprawiane przez prężnie działające społeczności rozwiązań open sourcowych. A utrzymania rozwiązania powinno być na głowie integratora.

Fakt jest taki, że z open source bardzo często jest jak z pewnym proszkiem do prania: "Jak nie widać różnicy, to po co przepłacać..."

Pozdrawiam

Wojciech Nurkowski:
Bardziej chodzi o to, że przy opensource, wykorzystywane są pewne moduły / elementy oprogramowania, które się powielaja funkcjonalnością w wielu aplikacjach i są dostępne dla programistów za darmo. Wystarczy je posklejac do kupy, doszlifować i masz gotowy produkt.

to chyba "ogólna prawda", kazde narzędzie i środowisko ma jakieś biblioteki, OOowe tzra samemu integrować a te z "jednego pudełka" już nie zawsze.

Wiadomo, że będzie to tańsze niż dziobanie analogicznych rozwiązań od początku.
Mniejszy nakład pracy, więc i cena idzie w dół.

chyba nikt normalny nie dzierga już niczego od początku zaś specyfika danego projektu i tak jest do zrobienia "od zera" wiec i tu nie widzę specjalnej różnicy...

Czy lepsze czy gorsze... chyba zależy to od jakości i podejścia wykonawcy aplikacji.

zacząłem ten wątek zaczynam mieć wrażenie, że spór o OO chyba zamknął się w ideologii bo z perspektywy praktyki nie widzę żadnej różnicy. Nie programuje już ale jeżeli różnica pomiędzy narzędziami i oprogramowaniem OO a komercyjnym jest podobna jak różnica pomiędzy narzędziami CASE OO i komercyjnymi to wole komercyjne bo od czasu jak kupiłem porządną licencję na pakiet do projektowania to mam mniej pracy niż wcześniej na "półśrodkach"....

tak więc coraz bardziej skłaniam do potwierdzenia tego: "zależy to od jakości i podejścia wykonawcy aplikacji"

Magdalena Ziębińska:
Jeżeli zaś chodzi o hasła marketingowe ofert, to powód może być następujący - Open Source jest często kierowany z założenia do sektora MSP. W wielu sytuacjach budżet małych firm nie pozwala na zakup oprogramowania komercyjnego o rozbudowanej funkcjonalności.

Zrzucę to na karb pojęcia "budżet": jeżeli ktoś podchodzi do tematu "a mogę se pozwolić by wydać na jakieś tam programy 100.000" to ma problem w 100% cenowy. Jak się trafi ktoś myślący "mogę podnieść przychody o 20% ale nie mam narzędzia" to inna rozmowa, budżet może być życzeniowy albo "biznesowy", ten pierwszy niestety nadal cechuje nasze kochane MSP i raczej w tym upatruję kłopot. Niedawno mnie ktoś (właściciel firmy) zapytał czy ktoś mu napisze CRM za 5000zł bo ty ma zamiar wydać (to jego budżet) na taki "prosty dedykowany programik" (gotowce mu nie przypasowały)..... bez komentarza...

Jeżeli więc procesy biznesowe zachodzące w małym przedsiębiorstwie są na tyle złożone, że nie wystarcza już Subiekt itp., jedynym rozwiązaniem może być Open Source.

Jedynym???? Jeżeli procesy są "złożone" to problemem będzie ich implementacja a nie żaden gotowy produkt (pomijam, że system ERP to liczydło a nie wyrafinowany workflow).

Brak opłat licencyjnych lub konieczności tworzenia rozwiązania od zera co realnie zmniejsza koszty.

kto dziś pisze coś "od zera"??????

Dodatkowo standardowa stawka konsultantów firm oferujących wsparcie wdrożeniowe produktów Open Source jest ciągle niższa niż w przypadku znanych komercyjnych rozwiązań.

ciekawe dlaczego (ale nie zawsze tak jest)

Kolejnym przykładem może być przedsiębiorstwo, które dopiero zaczyna wchodzić na rynek. Z powodu początkowych inwestycji firma nie jest w stanie przeznaczyć milionów na oprogramowanie.

czyli, że wchodzący na rynek taksówkarz może zaczynać "tanio" od wożenia ludzi taczką a jak zarobi to se kpi samochód???

Jednak ma ona potencjał, więc pakiet rozwiązań za 300zł może szybko okazać się niewystarczający. W tym przypadku standardowa funkcjonalność produktów Open Source może być dla niej całkowicie wystarczająca. Natomiast wraz z rozwojem firmy i rozszerzeniem asortymentu usług, system może zostać bezproblemowo rozbudowany.

powyższe dotyczy każdego typu oprogramowania

Ponadto warto też zauważyć, iż funkcjonalność oprogramowania biznesowego Open Source jest na tyle ciekawa, iż wiele znaczących korporacji (nawet polskich) decyduje się na ich wykorzystanie jako produktu bazowego. Powodem jest właśnie szukanie oszczędności.

jak wyżej....

Jeżeli chodzi personalnie o mnie, to bardziej bym obstawała za hasłem "idealny" dla Open Source, ponieważ może on zostać całkowicie dostosowany do potrzeb ;)

Ostatnio miałem w rękach ofertę na Dynamix AX i IFS - obie zawierały dokładnie ten sam, powyższy tekst: "może on zostać całkowicie dostosowany do potrzeb ".

50% zdaje się dotyczyło TCO (Total Cost of Ownership), czyli przede wszystkim kosztów licencji i wdrożenia, a nie samego kodu.

z tym TCO bym nie przesadzał bo ono akurat w ogóle nie zależy od OO bo TCO to praca ludzi a nie kod.

Witam,
ja wrzucam kamyczek do ogródka. Już niedługo się okaże (mam na myśli koniec roku i nowe stawki VAT), jakie koszty pociągną za sobą modyfikacje "open coś tam" i ERP'a z API (teoretycznie pozwalające na dowolną konfigurację, bez pomocy producenta) w dostosowaniu tych programów do przepisów podatkowych.

pozdrawiam

Krzysztof Bokiej:
Kod oczywiście ma znaczenia. Natomiast nie ma żadnej gwarancji, że aplikacje kupione za grubą kasę mają ten kod lepiej napisany. Ba... W zamkniętych aplikacjach nie mamy nawet możliwości tego zweryfikować...

poprawcie mnie ale w kategoriach ryzyka: jaki zespół napisze dobrze "kod" stały czy dorywczy? Jaka jest różnica pomiędzy "społecznością" a "zespołem" w produkcji "kodu"?

Co do samych Open Source, to moim zdaniem nadchodzi złota era tego typu licencji. Korporacje (bo to właśnie one są najmniej przekonane do open sourców) cały czas jeszcze przywiązują zbyt dużą wagę do tak zwanego utrzymania, czy wsparcia. Fakt jest taki, że zdarza się nierzadko drogi soft, który jest podziurawiony bardziej niż niektóre gatunki sera szwajcarskiego... A jak zgłosi się buga to się w odpowiedzi otrzymuje często prośbę o zainstalowanie olejnego service-packa, który się tam kiedyś ukaże...

O, to prawda, potwierdzam :)

W praktyce dużo szybciej bugi są naprawiane przez prężnie działające społeczności rozwiązań open sourcowych. A utrzymania rozwiązania powinno być na głowie integratora.

a tu mam problem, bo jeżeli mogę zawrzeć umowę cywilną z "jakąś firmą" to nie mam takiej możliwość w przypadku "społeczności"

Fakt jest taki, że z open source bardzo często jest jak z pewnym proszkiem do prania: "Jak nie widać różnicy, to po co przepłacać..."

a tu owszem :)

ROMAN WILK:
Witam,
ja wrzucam kamyczek do ogródka. Już niedługo się okaże (mam na myśli koniec roku i nowe stawki VAT), jakie koszty pociągną za sobą modyfikacje "open coś tam" i ERP'a z API (teoretycznie pozwalające na dowolną konfigurację, bez pomocy producenta) w dostosowaniu tych programów do przepisów podatkowych.

abstrahując od wątku to akurat zależy od projektu (model danych i architektura) a nie tego kto wykonał i na jakiej licencji ....

Krzysztof Bokiej:

Mateusz Kurleto:

Może więc jest tak, że po protu nie ma żadnego znaczenia ten "cholerny" kod......

Cholerny kod ma cholernie duże znaczenie, bo od niego zależy jakość oprogramowania, jego funkcjonalność, bezpieczeństwo, niezawodność itd.

Kod oczywiście ma znaczenia. Natomiast nie ma żadnej gwarancji, że aplikacje kupione za grubą kasę mają ten kod lepiej napisany. Ba... W zamkniętych aplikacjach nie mamy nawet możliwości tego zweryfikować...

Oczywiście, że mamy - badając ich jakość. Technologie technologiami, ale już w biblii napisano "po owocach ich poznacie".

Poza tym - zdaje mi się, że w swoich rozważaniach skupiasz się na aplikacjach typu "pudełkowego". Kupić Office'a czy ściągnąć OOo. A systemy dedykowane dzisiaj można zamawiać dostając nie tylko kod źródłowy - ale także SRS, SLA, projekt implementacji, udokumentowany kod, z zaznaczeniem pełnej śladowości i systemem do zarządzania zmainą. Komercyjnie.

Co do samych Open Source, to moim zdaniem nadchodzi złota era tego typu licencji. Korporacje (bo to właśnie one są najmniej przekonane do open sourców) cały czas jeszcze przywiązują zbyt dużą wagę do tak zwanego utrzymania, czy wsparcia. Fakt jest

To życzeniowe nastawienie wynikające zwykle z braku doświadczenia. Nie da się przecenić utrzymania i wsparcia. Godzina bez systemu w pojedynczej stacji dealerskiej kosztuje cię od kilku set do kilku tysięcy zł. Dzień - od kilku tysięcy do kilkudziesięciu.
Jak padnie na raz system rozproszony i takich stacji masz w Polsce 40 to za jeden dzień przestoju tracisz od kilkudziesięciu to kilkuset tysięcy DZIENNIE.
Przeanalizuj sobie koszty błędów w oprogramowaniu itd.

To nie jest tak, że Open Source jest zły bo nie ma do niego wsparcia - Open Source bez wsparcia jest zły. Więc jeśli za jakimś otwartym rozwiązaniem staje firma, która dobrze je zna i to wsparcie daje - ryzyko natychmiast spada.

taki, że zdarza się nierzadko drogi soft, który jest podziurawiony bardziej niż niektóre gatunki sera szwajcarskiego... A jak zgłosi się buga to się w odpowiedzi otrzymuje często prośbę o zainstalowanie olejnego service-packa, który się tam kiedyś ukaże... W praktyce dużo szybciej bugi są naprawiane przez prężnie działające społeczności rozwiązań open sourcowych. A utrzymania rozwiązania powinno być na głowie integratora.

I często tak właśnie jest.

Fakt jest taki, że z open source bardzo często jest jak z pewnym proszkiem do prania: "Jak nie widać różnicy, to po co przepłacać..."

Tu się zgadzam.

Ja od siebie powiem tyle, że wile osób krytykuje Open Source, tylko dlatego, że nie znają pełni ich możliwości, wrzucając wszystkie do jednego worka o nazwie "zło".
Prawda jest taka, że wśród programów/systemów/skryptów Open Source'owych jak i komercyjnych, są lepsze i gorsze rozwiązania.Adrian Jaworski edytował(a) ten post dnia 07.09.10 o godzinie 13:33

Jarek Żeliński:

Krzysztof Bokiej:
W praktyce dużo szybciej bugi są naprawiane przez prężnie działające społeczności rozwiązań open sourcowych. A utrzymania rozwiązania powinno być na głowie integratora.

a tu mam problem, bo jeżeli mogę zawrzeć umowę cywilną z "jakąś firmą" to nie mam takiej możliwość w przypadku "społeczności"

To prawda. Dlatego napisałem, że utrzymanie powinno być na głowie integratora (w rozumieniu: firma wdrażająca jakieś rozwiązanie korzystając z softu open source. integrator nie jest tu producentem softu, ale go wdraża). Jeżeli coś nie działa to dostawca integrator kontaktuje się ze społecznością lub szuka workaroundów. Zresztą tak też się dzieje w przypadku integratorów wdrażających rozwiązania komercyjne. To oni często kontaktują się bezpośrednio z producentem i po ewentualnym spuszczeniu na drzewo szukają obejścia. Z integratorem umowę już można podpisać i wszystkie inne stosowne dokumenty obejmujące czasy reakcji, priorytety itp.

Jarek Żeliński:

ROMAN WILK:
Witam,
ja wrzucam kamyczek do ogródka. Już niedługo się okaże (mam na myśli koniec roku i nowe stawki VAT), jakie koszty pociągną za sobą modyfikacje "open coś tam" i ERP'a z API (teoretycznie pozwalające na dowolną konfigurację, bez pomocy producenta) w dostosowaniu tych programów do przepisów podatkowych.

abstrahując od wątku to akurat zależy od projektu (model danych i architektura) a nie tego kto wykonał i na jakiej licencji ....

Zgadzam się w 100%. Wszystko zależy od konkretnego projektu.

Zastanawia mnie tylko jedno - czemu ludzie z branży IT nadal uważają, że projekty Open Source tworzone są przez grupkę studentów. W obecnych czasach za biznesowymi projektami Open Source stoją wielkie międzynarodowe przedsiębiorstwa, które mają dużo większe możliwości i potencjał niż nie jedna polska firma tworząca komercyjne rozwiązania. Rozbudowane API i możliwości konfiguracyjne to już dawno standard. Ze swojej strony sugeruję przyjrzeć się projektom Open Source systemów klasy ERP, CRM itp. Gwarantuje, że zakres funkcjonalny jest dużo większy niż w wielu polskich produktach systemów tych samych klas.

Pozdrawiam,
Marcin

Adrian Jaworski:
Prawda jest taka, że wśród programów/systemów/skryptów Open Source'owych jak i komercyjnych, są lepsze i gorsze rozwiązania.

jak Mateusz napisał "po owocach ich poznacie" ... wiec chyba nie ma znaczenia kod i jego licencja, znaczenie ma całość projektu w szczególności jego wykonawca lub integrator, kod jest jedynie "kawałkiem" projektu i to z reguły małym... i nie mówimy tu absolutnie o pudełkowym "office" coś tam...

Jarek, ale temat wybrałeś ;) nieskończona opowieść ;)

Poza tym warto tu też dodać, że "Open Source" to nie zawsze znaczy darmowy. Dodatkowo "Closed Source" też nie zawsze znaczy płatny.

Jak się poczyta o "Open Source" i całej historii powstania to można się dowiedzieć, że takie były założenia, żeby wszystko było za darmo i publicznie dostępne.

Jednak często się powtarza, że "darmówki" psują rynek. Według mnie wprowadzają jedynie alternatywę, nowe możliwości i realną konkurencję w sektorach silnie zmonopolizowanych i często "kontrolowanych" czy "powiązanych" z rządem.

"Open Source" ma jeszcze taką zaletę, że nie ma ukrytego kodu, który czyni cuda. Jest testowany przez miliony pasjonatów a nie garstkę wybrańców.

Choć gwarancji odnośnie jakości nigdy nie ma. Zarówno "darmowe", "Open Source", "płatne", "Closed Source" może spełniać wymagania jak również może nie spełniać wymagań danej firmy, czy osoby prywatnej.

Wszystko należy dostosować do indywidualnych potrzeb i wymagań.

To, że jest wiele darmowych też nie zmienia faktu, że czasem coś co jest akurat idealnie pasujące do potrzeb się kupi. Dodatkowo teraz się bardziej kupuje usługi a nie produkt w sensie oprogramowania.

Pozdrawiam,
Darek

Mateusz Kurleto:

Oczywiście, że mamy - badając ich jakość. Technologie technologiami, ale już w biblii napisano "po owocach ich poznacie".

Po owocach to można co najwyżej sprawdzić, czy działa, albo nie działa. Ni jak nie da się ocenić, czy może działać szybciej, albo dlaczego działa wolno.

Poza tym - zdaje mi się, że w swoich rozważaniach skupiasz się na aplikacjach typu "pudełkowego". Kupić Office'a czy ściągnąć OOo. A systemy dedykowane dzisiaj można zamawiać dostając nie tylko kod źródłowy - ale także SRS, SLA, projekt implementacji, udokumentowany kod, z zaznaczeniem pełnej śladowości i systemem do zarządzania zmainą. Komercyjnie.

Nie wiem dlaczego akurat na pudełkowych... SRS, SLA itp są uzgadniane z integratorem a nie producentem. Przecież SLA nie podpisuję z Oracle jak wdrażam bazę danych tylko z firmą, która dla mnie to robi. Ona ma to zrobić tak, żeby spełnić moje wymagania.

To życzeniowe nastawienie wynikające zwykle z braku doświadczenia. Nie da się przecenić utrzymania i wsparcia. Godzina bez systemu w pojedynczej stacji dealerskiej kosztuje cię od kilku set do kilku tysięcy zł. Dzień - od kilku tysięcy do kilkudziesięciu.
Jak padnie na raz system rozproszony i takich stacji masz w Polsce 40 to za jeden dzień przestoju tracisz od kilkudziesięciu to kilkuset tysięcy DZIENNIE.
Przeanalizuj sobie koszty błędów w oprogramowaniu itd.

Dokładnie, ale znowu. To ne wina Oracle'a, że mam źle zaprojektowany system...

edit: LiterówkiKrzysztof Bokiej edytował(a) ten post dnia 07.09.10 o godzinie 13:50

Krzysztof Bokiej:

Mateusz Kurleto:

Oczywiście, że mamy - badając ich jakość. Technologie technologiami, ale już w biblii napisano "po owocach ich poznacie".

Po owocach to można co najwyżej sprawdzić, czy działa, albo nie działa. Ni jak nie da się ocenić, czy może działać szybciej, albo dlaczego działa wolno.

Ale uwierz mi, że właściciela procesu windykacji, który ma wspierać system, dla którego celem wdrożenia jest obniżenie średniego czasu windykacji należności z 58 do 39 dni albo zwiększenie odsetka rozmów prowadzonych z bezpośrednio z dłużnikiem z 40% do 60% naprawdę nie interesuje czy system może działać szybciej i czy ktoś korzysta z drzew AVL czy czerwono-czarnych.
Interesuje go:
- w jakim stopniu realizuje cel
- jak szybko nowy pracownik jest w stanie nauczyć się korzystać z systemu
- co się stanie jeśli system nie działa - jakie są utracone korzyści, jakie są straty, jakie są warunki przywrócenia systemu
- jakie są adaptacji systemu dla osiągnięcia podobnych celów w dziale sprzedaży bezpośredniej

Poza tym - zdaje mi się, że w swoich rozważaniach skupiasz się na aplikacjach typu "pudełkowego". Kupić Office'a czy ściągnąć OOo. A systemy dedykowane dzisiaj można zamawiać dostając nie tylko kod źródłowy - ale także SRS, SLA, projekt implementacji, udokumentowany kod, z zaznaczeniem pełnej śladowości i systemem do zarządzania zmainą. Komercyjnie.

Nie wiem dlaczego akurat na pudełkowych... SRS, SLA itp są uzgadniane z integratorem a nie producentem. Przecież SLA nie podpisuję z Oracle jak wdrażam bazę danych tylko z firmą, która dla mnie to robi. Ona ma to zrobić tak, żeby spełnić moje wymagania.

To wszystko kwestia ryzyka w projekcie. Jednym z pytań na które przy wdrożeniu należy sobie odpowiedzieć to czy będę w stanie zapewnić ciągłość działania systemu jeśli mój integrator, dostawca, wdrożeniowiec - zbankrutuje, nie sprawdzi się, wycofa ze wsparcia, nie przedłuży umowy itp.
Ale generalnie się zgadzam - jak zapewne zrozumiałeś nie mówię, że rozwiązania Open Source są złe - mówię, że należy obiektywnie oceniać korzyści i ryzyka z nimi związane.

To życzeniowe nastawienie wynikające zwykle z braku doświadczenia. Nie da się przecenić utrzymania i wsparcia. Godzina bez systemu w pojedynczej stacji dealerskiej kosztuje cię od kilku set do kilku tysięcy zł. Dzień - od kilku tysięcy do kilkudziesięciu.
Jak padnie na raz system rozproszony i takich stacji masz w Polsce 40 to za jeden dzień przestoju tracisz od kilkudziesięciu to kilkuset tysięcy DZIENNIE.
Przeanalizuj sobie koszty błędów w oprogramowaniu itd.

Dokładnie, ale znowu. To ne wina Oracle'a, że mam źle zaprojektowany system...

Podajesz przykład warstwy danych, a zdaje się nie rozmawiamy o wykorzystywaniu Open Source w warstwie Danych, czy implementacji ale o całościowych rozwiązaniach biznesowych. O tym,. że wiele komercyjnych rozwiązań korzysta z PgSQL, Javy, czy całych frameworków wszyscy wiemy.