Szukam osób, które chciałyby tworzyć nowy system klasy ERP

0

Szukam osób, które chciałyby tworzyć nowy system klasy ERP (głównie z przeznaczeniem dla MŚP).

Założenia:

  • Funkcjonalność: Fakturowanie, Księgowanie, Magazyn, itd.
  • Aplikacja typu: PWA, RESTfull
  • Podejście do programowania: DDD
  • Podejście do testów: BDD
  • Stack technologiczny:
    • Angular 5+,
    • Angular Material,
    • .NET Core,
    • SQL Server

Kilka słów o mnie:
Zawodowo (komercyjnie) od 15 lat programuję (głównie: C#, Delphi, JavaScript, TypeSrcipt), od 9 lat czynnie uczestniczę w projektowaniu systemów informatycznych, od 3 lat pełnię funkcję samodzielnego architekta oprogramowania oraz sprawuję opiekę mentorską dla zespołów developerskich. Przez 3 lata byłem kierownikiem działu IT a przez 5 lat zarządzałem projektami. Większość swojego doświadczenia zawodowego zdobyłem podczas realizacji projektów dla dużych korporacji będących liderami rynku w swoich branżach.

Wszystkie osoby chętne do pracy (nie zaborkowej) przy współtworzeniu projektu mile widziane :).

1

Dlaczego akurat taki stack wybrales?

0

PWA – Aplikacje desktopowe w dzisiejszych czasach nie mają za bardzo racji bytu i chyba nikogo do tego nie trzeba przekonywać. „Klasyczne” aplikacje Webowe, są trochę nie właściwe dla firm, które nie posiadają własnego IT (system kierowany do MŚP). Trudno sobie wyobrazić, że pani stojąca za ladą wystawiała paragon za pośrednictwem przeglądarki (klient czekający na taki paragon chyba by się rozmyślił i wyszedł ze sklepu bez swoich zakupów ;)). Odpowiedzią na to może tu być właśnie PWA.

RESTFull – To poniekąd konsekwencja PWA.

DDD – Pozwala skupić wysiłki na realizacji biznesu a nie na infrastrukturze systemu, jednocześnie dając możliwość (stosunkowo) szybkiego wprowadzania zmian i poprawek. Choć oczywiście nie jest to za darmo.

BDD – Trudno określić w sposób zero-jedynkowy wynik poszczególnych testów w systemie do ogólnego przeznaczenia, bo przecież nie wiemy jaki będzie biznes użytkownika systemu. Dlatego właśnie podejście BDD świetnie się tu sprawdzi. Pozwala określić poprawność funkcjonowania systemu w ramach danego scenariusza, w obrębie zdefiniowanych założeń i wywoływanych zdarzeń. Słynne: Give… When… Then….

Angular 5+ - Wybierając framework Front-Endu, miałem do dyspozycji tak naprawdę 3: Vue, React i Angular. Pozostałe frameworki są tak daleko w tyle (chociażby pod względem popularności), że nie ma sensu ich rozpatrywać. Dodatkowo, zależało mi, żeby był to framework wysokiego poziomu, w którym łatwo dałoby się zapanować nad kodem. Vue – za dobrze nie znam, więc odpuściłem sobie. Co prawda zyskuje mocno na popularności ale nie znam żadnego komercyjnego projektu (aplikacji biznesowej), gdzie Vue by się sprawdził. React – nie jest frameworkiem :), ponadto, miesza HTMLa z JavaScriptem, przez co użycie tych samych templatek HTMLowy wraz z inną logiką jest problematyczne (code reuse). Ponadto, do zaimplementowanie kompletnego rozwiązania bogatego UX (bo mówimy przecież o PWA) wymaga dodatkowych pluginów, utrzymywanych przez różne społeczności i różne problemy z tym związane. Angular – cóż innego mi pozostało ;). Kompletny framework dostarczany ze wszystkim co tylko możliwe, dzięki czemu nie potrzebujemy niczego więcej. Wszystkie odpowiedzialności są od siebie odseparowane (nie tylko logicznie ale również fizycznie – inny plik z HTMLem, inny plik z TypeScriptem, inny z CSSem). Całość składana w runtime z wykorzystaniem wstrzyknięć zależności, którymi możemy dowolnie manipulować. Oczywiście ma on swoje wady: wysoki próg wejścia, większa objętość kodu. Ale ma on również zaletę, z którą ciężko dyskutować: wymusza porządek w kodzie.

Angular Material – Skoro mowa o aplikacji PWA, to musi ona wyglądać jak desktopowa, stąd ukłon w stronę Material – chyba już wszyscy wiodący dostawcy systemów pogodzili się z ujednoliceniem ich interfejsów do jednego wyglądu. A jak Material i Angular, to Angular Material.

.NET Core – Jak każda aplikacja Internetowa, tak i ta musi być gdzieś hostowana. Trudno przewidzieć dzisiaj, jak będzie wyglądać rynek VPSów czy CloudApp (zwłaszcza pod względem cenowym) za lat kilka. Dlatego Back-End powinien być wykonany w sposób „przenoszalny”. .NET Core już dzisiaj może być uruchamiany na Windowsie, Lunxie, czy iOSie. Wiec jak najbardziej spełnia te wymagania. Oczywiście można by powiedzieć, że są też inne technologie, które to umożliwiają: Java, Node.js, itd.. Jednakże, mają też swoje wady, których wydaje się nie posiadać .NET Core. Java wymaga wirtualnej maszyny, więc ma większy narzut na zasoby (przynajmniej teoretycznie, bo to też zależy od przypadku użycia). Node.js, chyba jeszcze nie do końca dorósł, być odpowiedzialnym za Back-End w złożonym systemie biznesowym.

SQL Server – Skoro już idziemy w rozwiązania MS, to po całości. Działa na Windowsie, Linuxie, a więc wraz z serwisem Back-Endu możemy przenosić także jego bazę danych. Problemem może być tutaj jego cena, ale wersja Express wydaje się zaspokoić potrzeby systemu ;).

Oczywiście, to jest tylko propozycja systemu i jego stacku. Jaki kształt ostatecznie będzie miał system, zależy od jego twórców i siły ich argumentów, a nie od pobożnych życzeń jednej osoby. Na wynik, zawsze pracuje zespół!

0

Czytając pierwszego posta nie zauważyłem nigdzie wzmianki o tym, że ma to być aplikacja darmowa, nie ma też słowa o open source nigdzie poza ankietą. Stąd pytanie - czy to przeoczenie, czy może ankieta sobie, a licencja tego systemu, który chcesz stworzyć wcale wolną nie będzie?

Zakładając jednak, że to tylko przeoczenie, a system ma być wolnoźródłowy i darmowy - dlaczego chcesz to oprzeć o komercyjne rozwiązania Microsoftu? Niby jest wersja darmowa, ale jest ona jednak ograniczona, zwłaszcza w zakresie wielkości bazy. A potem kupienie "prawdziwego" SQL'a to nie jest 400 zł, tylko trochę więcej ;) Więc w mojej ocenie trochę się to mija z założeniami - albo robi się coś "darmowego", albo klient musi płacić (wprawdzie nie Tobie, tylko za licencję - ale z punktu widzenia użytkownika to wiele nie zmienia - w efekcie Twój produkt wymaga zakupienia usług/licencji). A jeśli użytkownik będzie musiał i tak ładnych kilka złotych wyłożyć, to może raczej być zainteresowanym w pełni komercyjnym rozwiązaniem, z wyrobioną opinią na rynku oraz porządnym wsparciem.

0

Oczywiście, zakładam, że oprogramowanie będzie OpenSource. Osobiście skłaniam się ku licencji MIT.

Wszystkie technologie użyte do tworzenia oprogramowania zakładam, że będą w wersji darmowej dla użytkownika końcowego. Czemu więc SQL Server, który taki nie jest? Odpowiedź jest prosta, choć trochę pokrętna :). Obecne ograniczenia SQL Server w wersji Express wydają się być wystarczające dla pojedynczej firmy z sektora MŚB, czyli takich, które nie mają więcej niż 250 pracowników a ich roczny obród jest poniżej 50mln EUR. Trudno mi sobie wyobrazić, by firma z sektora MŚB wygenerowała danych, których składowanie w okresie 5 lat przekraczałaby 10GB, a praca 250 pracowników wymagałaby większej mocy obliczeniowej. Oczywiście dopuszczam możliwość użycia innej bazy danych w projekcie dla bardziej wymagających użytkowników. Pozostaje tylko pytanie: jaka baza danych jest w stanie konkurować z SQL Server i jednocześnie być w pełni darmowym rozwiązaniem? Ponadto, mówimy tutaj o aplikacji typu PWA. Z założenia taka aplikacja komunikuje się z usługą WebAPI umieszczoną gdzieś w Internecie. Aby taka usługa mogła być dostępna, to musi być gdzieś hostowana. Dlatego zakładam, że system będzie hostowany za pośrednictwem jakiegoś VPSa lub CloudApps. A te usługi (niestety) są również płatne. Zatem aby projekt OpenSource systemu z nastawieniem na PWA mógł funkcjonować (a nie być tylko developowany), to musi być finansowany. Modeli finansowania jest wiele. Począwszy od dotacji a na reklamach skończywszy. Tutaj uwydatnia się jeszcze jedna kwestia często mylona. Oprogramowanie OpenSource, to nie znaczy, że jest za darmo (w sensie, że nic nie kosztuje). To znaczy, że kod jest otwarty i dostępny, a użycie może być płatne. Wszystko zależy od tego, na jakiej licencji oprogramowanie OpenSource zostało udostępnione.

Z powyższego wywodu, wyłaniają się 3 możliwe scenariusze korzystania z systemu:

  1. Użytkownik/Firma ma własny serwer i własne licencje na komponenty 3-rd (płatne lub nie) + cała infrastrukturę sieciowo-serwerową (a to nie są małe koszty), w ramach której uruchamia OpenSourceowy system ERP.
  2. Użytkownik/Firma dzierżawi usługę VPS/CloudApp i licencje na komponenty 3-rd (płatne lub nie), w ramach których uruchamia OpenSourceowy system ERP.
  3. Użytkownik/Firma korzysta z OpenSourceowego systemu ERP, a społeczność tego systemu dba by system miał odpowiednie środowisko uruchomieniowe i pozyskuje środki finansowe na jego funkcjonowanie.

Jak zawsze, każde rozwiązanie ma swoje plusy i minusy. Co z tego będzie – społeczność zadecyduje.

0

Jak sądzisz jak wiele osób i ile czasu potrzeba do realizacji tego przedsięwzięcia?

2
SzymKelo napisał(a):

PWA – Aplikacje desktopowe w dzisiejszych czasach nie mają za bardzo racji bytu i chyba nikogo do tego nie trzeba przekonywać. „Klasyczne” aplikacje Webowe, są trochę nie właściwe dla firm, które nie posiadają własnego IT (system kierowany do MŚP). Trudno sobie wyobrazić, że pani stojąca za ladą wystawiała paragon za pośrednictwem przeglądarki (klient czekający na taki paragon chyba by się rozmyślił i wyszedł ze sklepu bez swoich zakupów ;)). Odpowiedzią na to może tu być właśnie PWA.

PWA (Progressive Web Application) to w dalszym ciągu aplikacja Webowa. Dlaczego te są odpowiednie dla firm nie posiadających własnego IT a standardowe apki Webowe nie są odpowiednie? Kolejna sprawa, jest to technologia "nowa", nie wspierana we wszystkich przeglądarkach.

SzymKelo napisał(a):

RESTFull – To poniekąd konsekwencja PWA.

W jaki sposób REST jest konsekwencją PWA?

SzymKelo napisał(a):

Angular Material – Skoro mowa o aplikacji PWA, to musi ona wyglądać jak desktopowa, stąd ukłon w stronę Material – chyba już wszyscy wiodący dostawcy systemów pogodzili się z ujednoliceniem ich interfejsów do jednego wyglądu. A jak Material i Angular, to Angular Material.

Nie, że się czepiam, ale przecież Materials jest stosowane w technologii Webowej, dlaczego uważasz że material sprawi, że aplikacja będzie wyglądać jak desktopowa?

SzymKelo napisał(a):

.NET Core – Jak każda aplikacja Internetowa, tak i ta musi być gdzieś hostowana. Trudno przewidzieć dzisiaj, jak będzie wyglądać rynek VPSów czy CloudApp (zwłaszcza pod względem cenowym) za lat kilka. Dlatego Back-End powinien być wykonany w sposób „przenoszalny”. .NET Core już dzisiaj może być uruchamiany na Windowsie, Lunxie, czy iOSie. Wiec jak najbardziej spełnia te wymagania. Oczywiście można by powiedzieć, że są też inne technologie, które to umożliwiają: Java, Node.js, itd.. Jednakże, mają też swoje wady, których wydaje się nie posiadać .NET Core. Java wymaga wirtualnej maszyny, więc ma większy narzut na zasoby (przynajmniej teoretycznie, bo to też zależy od przypadku użycia). Node.js, chyba jeszcze nie do końca dorósł, być odpowiedzialnym za Back-End w złożonym systemie biznesowym.

Wiesz, że NodeJS jest używany produkcyjne przez takie firmy jak LinkedIn, Trello, Uber, Netflix, i inne? Java jest wszedzie, to wszyscy wiemy.

SQL Server – Skoro już idziemy w rozwiązania MS, to po całości. Działa na Windowsie, Linuxie, a więc wraz z serwisem Back-Endu możemy przenosić także jego bazę danych. Problemem może być tutaj jego cena, ale wersja Express wydaje się zaspokoić potrzeby systemu ;).

A może zrobić to tak, żeby moglo być zdeployowane z każdą popularną bazą danych?

0

Pytanie do @SzymKelo - czy zebrała się grupa zainteresowanych?
Projekt jakoś ruszył z miejsca, czy na razie czeka "na lepsze czasy"?

0

Jesśli znasz TypeSrcipt to skupiłbym się na NodeJS.

2

Tylko, że rynek jest już zdominowany przez kilku producentów. Ponieważ mowimy tu o firmach MŚP to nie wydaj mi się, aby firmy chętnie przesiadły sie na nowy system nawet jeżeli miałby być on darmowy i lepszy od obecnie używanych. W tego typu produktach jakość rozwiązań nie zawsze jest decydującym czynnikiem dla klienta, często liczy się przyzwyczajenie, wsparcie techniczne i zaufanie do produktu pomijam już sam proces migracji. To czy program jest webowy czy desktopowy też nie jest kluczowe bo wiele firm problem ten rozwiązuje się za pomocą zdalnego pulpitu.

1

Poza tym to są tysiące roboczogodzin, doliczając do tego stworzenie sensownej dokumentacji dla administratorów i użytkowników, Trzeba przeprowadzić wiele testów sprawdzających program pod względem merytorycznym (np. czy rozliczenia VAT do urzędów skarbowych są prawidłowe) więc kto to będzie robił za free i kto za to będzie brał odpowiedzialniość (jak klientowi przyjdzie zapłacić zaległy podatek z odsetkami)?

0

moim zdaniem mit obalony

0

Odnośnie odpowiedzialności - akurat tego bym się nie obawiał.

Nie wiem, czy i jak się do tego mają różne wolne licencje (OP wspominał na początku, że rozważa stworzenie tego produktu na bazie licencji MIT), ale jeszcze jest takie coś jak EULA. Na pewno zostaną tam umieszczone stosowne zapisy. Często płatne aplikacje mają podobne "dodatki" (inna sprawa to pytanie, czy w razie sprawy w sądzie, takie zapisy by skutecznie ochroniły autora), więc tym bardziej nie widzę powodów, żeby nie było stosownych wykluczeń w oprogramowaniu OpenSource i darmowym.

0

Minął ponad rok. Czy ktoś jest w stanie powiedzieć, czy coś się w sprawie przez ten czas ruszyło? Widzę, że OP przez ten rok się nie logował na forum, więc opcje są dwie: albo to sobie żyje swoim życiem gdzieś indziej, albo temat upadł. Jeśli ktoś coś wie, to proszę o podzielenie się swoją wiedzą :)

1

Przeprasza, z przyczyn osobistych/zawodowych musiałem "zawiesić temat na kołku".
Zacząłem "coś" developować samodzielnie (na razie manualne wystawianie faktur - mam trochę backendu .net core i trochę frontendu w angular).
Obecnie repo gitowe (z powodów osobistych) nam na TFS Online -jakby ktoś był zainteresowany, to mogę wrzucić to na githuba.

Na obecny moment, jestem jeszcze trochę zaangażowany w sprawy osobiste, które ograniczają moją dostępność dla projektu. Jednak że, z każdym dniem moja dostępność będzie teraz rosła :).

Jeśli znalazły by się osoby, które chciałby by się zaangażować w projekt, to było by mi bardzo miło :D.
Ze swojej strony mogę obiecać moją dostępność w projekcie (na chwilę obecną) na poziomie 4-12h tygodniowo. Zdaję sobie sprawę, że to nie dużo, w skali całego przedsięwzięcia - ale jak wspomniałem wcześnie, moja dostępność dla projektu będzie teraz narastająca.

@cerrato Dziękuję za Twoje pytanie - bez niego pewnie nie było by powyższego wyjaśnienia, które należy się wszystkim forumowiczom.

cerrato napisał(a):

Pytanie do @SzymKelo - czy zebrała się grupa zainteresowanych?
Projekt jakoś ruszył z miejsca, czy na razie czeka "na lepsze czasy"?

Nie zebrała się grupa, projekt zacząłem samodzielnie developować, jednak z uwagi na przyczyny osobiste/zawodowe nie miałem możliwości poświęcenia mu należytej uwagi. W chwili obecnej coraz częściej do niego wracam, a moja dostępność dla projektu będzie rosła.

0

Jak już coś tam ruszyło to jaka technologia?

1
szydlak napisał(a):

Jak już coś tam ruszyło to jaka technologia?

Na chwilę obecną:

  1. Backend:
    1.1. WebAPI (REST): .Net Core,
    1.2. ORM: EntityFramework,
    1.3. DB: MS SQL Server,
  2. Frontend:
    2.1. WebSite: Angular 8.2
2

No to będziemy mieć WyderERP :)

#pdk

1
cw napisał(a):

Poza tym to są tysiące roboczogodzin, doliczając do tego stworzenie sensownej dokumentacji dla administratorów i użytkowników, Trzeba przeprowadzić wiele testów sprawdzających program pod względem merytorycznym (np. czy rozliczenia VAT do urzędów skarbowych są prawidłowe) więc kto to będzie robił za free i kto za to będzie brał odpowiedzialniość (jak klientowi przyjdzie zapłacić zaległy podatek z odsetkami)?

Jak ustawa wywróci pół tematu (jak radosne miesiące 2019/20, poprzednio też), a wolontariusze projektu akurat maja urodzone dzieci, przeprowadzkę, znaleźli lepsze zajęcie itd ?

Kilka opensursowych aplikacji biznesowych tej klasy (apache ofbiz itd chyba nie bardzo się rozwija, a może zostały powoli uśmiercone)

1
SzymKelo napisał(a):
szydlak napisał(a):

Jak już coś tam ruszyło to jaka technologia?

Na chwilę obecną:

  1. Backend:
    1.1. WebAPI (REST): .Net Core,
    1.2. ORM: EntityFramework,
    1.3. DB: MS SQL Server,
  2. Frontend:
    2.1. WebSite: Angular 8.2

Widzę **zaledwie **pasjonatów weba.

W najmniejszym stopniu nie dyskutujecie, jak np. będą realizowane reguły biznesowe, proszę panów "architektów", jak będą się miały do kodu "sztywnego".
Dla największych i wiodących w swoich branżach, gdy aplikacja jest w jednej jedynej sztuce,się realizuje w software-housie w Javie czy C# czy w czy to jest.
Dla MSP nie ma innej szansy, kod biznesowy powstaje na wdrożeniu i nie jest "back-portowany" do centrali. Tzw "architektura" nie wymienia żadnego narzędzia do tego.

Pominę, że moim zdaniem (wiem że są koledzy myślący podobnie, nie pamiętam ksywek), dualizm back / front w sensie angular jest wymyślony aby większą łyżeczką jeść klienta, zadowolonego za latające animacje, dwukrotnie developować formatki, walidację i jedynie Partia wie co jeszcze.
Tani, łatwy w utrzymaniu i wieloletnie eksploatacji system MŚP moim zdaniem nie może iść tą ścieżką.

0
AnyKtokolwiek napisał(a):
cw napisał(a):

Poza tym to są tysiące roboczogodzin, doliczając do tego stworzenie sensownej dokumentacji dla administratorów i użytkowników, Trzeba przeprowadzić wiele testów sprawdzających program pod względem merytorycznym (np. czy rozliczenia VAT do urzędów skarbowych są prawidłowe) więc kto to będzie robił za free i kto za to będzie brał odpowiedzialniość (jak klientowi przyjdzie zapłacić zaległy podatek z odsetkami)?

Jak ustawa wywróci pół tematu (jak radosne miesiące 2019/20, poprzednio też), a wolontariusze projektu akurat maja urodzone dzieci, przeprowadzkę, znaleźli lepsze zajęcie itd ?

Kilka opensursowych aplikacji biznesowych tej klasy (apache ofbiz itd chyba nie bardzo się rozwija, a może zostały powoli uśmiercone)

Wszystko zależy od tego jaka społeczność rozwija projekt. Nie wszystkim wolontariuszom rodzą się dzieci w tym samym momencie. Ryzyko nie dostępności wolontariuszy, w dużym uproszczeniu, jest takie samo, jak brak pracowników na etacie - wszyscy są na chorobowych, urlopach macierzyńskich/tacierzyńskich, a tak w ogóle to nikt nie chce pracować w firmie, bo za mało płaci :).

Zarówno projekty realizowane przez firmy jak i przez społeczności mają swoje plusy i minusy. Wszystko zależy od tego jaka to firma lub jaka to społeczność.

AnyKtokolwiek napisał(a):
SzymKelo napisał(a):
szydlak napisał(a):

Jak już coś tam ruszyło to jaka technologia?

Na chwilę obecną:

  1. Backend:
    1.1. WebAPI (REST): .Net Core,
    1.2. ORM: EntityFramework,
    1.3. DB: MS SQL Server,
  2. Frontend:
    2.1. WebSite: Angular 8.2

Widzę **zaledwie **pasjonatów weba.

W najmniejszym stopniu nie dyskutujecie, jak np. będą realizowane reguły biznesowe, proszę panów "architektów", jak będą się miały do kodu "sztywnego".
Dla największych i wiodących w swoich branżach, gdy aplikacja jest w jednej jedynej sztuce,się realizuje w software-housie w Javie czy C# czy w czy to jest.
Dla MSP nie ma innej szansy, kod biznesowy powstaje na wdrożeniu i nie jest "back-portowany" do centrali. Tzw "architektura" nie wymienia żadnego narzędzia do tego.

Pominę, że moim zdaniem (wiem że są koledzy myślący podobnie, nie pamiętam ksywek), dualizm back / front w sensie angular jest wymyślony aby większą łyżeczką jeść klienta, zadowolonego za latające animacje, dwukrotnie developować formatki, walidację i jedynie Partia wie co jeszcze.
Tani, łatwy w utrzymaniu i wieloletnie eksploatacji system MŚP moim zdaniem nie może iść tą ścieżką.

To wszystko zależy od szeroko pojętej architektury i kierunku jej rozwoju. Wiele firm MŚP jest skłonna przenieść lub już przeniosła swoje systemy do chmury. Inne firmy, wykupują IaaS i instalują je OnPremis. Coraz mniej form stać już na utrzymanie własnych serwerowni (np. na potrzeby baz danych) ale te które mają, mają też infrastrukturę do instalacji systemu OnPremis na "własnym" sprzęcie. Oczywiście, systemy "przeglądarkowe" nie pokryją ich wszystkich potrzeb, stąd użycie UWP, które będzie mogło pracować w offline - choć dziś i tak wszystko jest online :).

Taniość, łatwość/elastyczność i prostota z reguły nie idzie w parze. Każde rozwiązanie jest kwestią kompromisu, tego co możemy, tego co umiemy a tego na co nas stać :).
Jednak generalna zasada, jest jak zawsze żywa - "w kupie siła" :). Im większa społeczność zaangażuje się w projekt, tym większą wiedzą/umiejętnościami będzie dysponować, co przełoży się na jakość rozwiązania jednocześnie będzie miała większe moce przerobowe i będzie dysponować większą dostępnością.

Jeśli zaś chodzi o "architekturę" systemu, to wszystko zależy od osób, które będą tworzyły system. Może to być np. bardzo cienki klient w architekturze HATEOAS, który jest pozbawiony wszelkich walidatorów (może za wyjątkiem walidacji kontraktów). Jest wiele możliwości - wszystko zależy od ludzi i ich pomysłowości :).

1

ja proponuję podejść do projektu z trochę innej strony - znajdź co najmniej jedną firmę, która wyrazi chęć przejścia na tego typu rozwiązanie.

2

Jest jakiś wysiłek Apache OfBiz (nie widzę żadnych śladów przyjęcia, chyba martwy), był jakiś polski ERP od wydawcy czasopisma programistyczno-linuksowego (sto lat temu, nie pamiętam). Nawet się go trochę uczyłem, aby oferować klientom. Nic z tego. . Nie widzę w tym żadnego rynku.
O wdrożeniach tej klasy (i dobrze) nie decydują programiści, tylko zarządzający, i opensource nie jest walorem.

1 użytkowników online, w tym zalogowanych: 0, gości: 1