12. září 2017

Konečně máme svůj produkt ...

Je to už pár let (doslovně), co jsem zde psal naposledy, ale teď mě to nedá, abych se nepodělil o své pocity.

Začnu tím, co se nám povedlo – vytvořili jsme open source integrační framework vycházející z populárního řešení Apache Camel, jmenuje se OpenHub framework a vypouštíme ho do světa. Proč další ESB? Protože OpenHub framework je open source řešení, které přitom obsahuje „enterprise“ funkce, které jsou normálně dostupné pouze ve drahých řešeních od velkých firem nebo v placených verzích konkurenčních produktů.
Pokud vás zaujal OpenHub framework, pak se prosím podívejte na následující odkazy:
-       Web: www.openhub.cz

Já zde ale nechci psát o našem řešení, já se chci podělit o důvodech našeho počínání, co vše jsme museli po cestě řešit, co se nám povedlo, ale také nepovedlo ...

Integrační projekty jsem začal řešit někdy v roce 2014, mají svoje specifika, není to stejné jako vyvíjet „normální“ aplikace s GUI. Hned na prvním projektu se sešla super skupinka lidí, se kterou jsme po letech založili firmu OpenWise Solutions. Od začátku naším cílem bylo „vytvořit produkt, na který budeme hrdý“ (pro začátek aspoň nějaký produkt ...). Aspoň u mě osobně to vycházelo z toho, že přes deset let jsem dělal na projektech pro různé zákazníky a už mě trochu začalo vadit, jak je každý projekt „jednorázový“, jak skoro vždy je málo času udělat věci pořádně nebo jak musím spolupracovat s lidmi, se kterými ani nechci spolupracovat. Produktový vývoj (aspoň v mé představě) má vyšší cíle – vymyslet resp. vytvořit kvalitní aplikaci/řešení, které opakovaně bude moci někdo další používat a v ideálním případě za to ještě zaplatí. A přitom dělat s lidmi, se kterými člověk chce dělat, hrát si s kódem podle svých měřítek kvality atd. 

Postupně jak jsme dělali integrační projekty, tak se nám různé věci začali na projektech opakovat, a proto přišlo logické rozhodnutí, abychom tyto věci dali někam bokem, do vlastní knihovny, kterou budeme postupně rozšiřovat. Snahou bylo začít nový integrační projekt tam, kde jsme ten předchozí skončili, nemuseli zdlouhavě vše znovu nastavovat a připravovat. Tak vznikl zárodek OpenHub frameworku – nejdřívě interní knihovna, poté interní projekt, veřejný open source projekt a nyní produkt k veřejnému použití.

Asi nejzajímavější zkušenost máme s tím, jak „jednoduché“ je produkt dotáhnout po technické stránce ve srovnání s tím jak to dotáhnout úplně celé, tj. připravit nějakou obchodní strategii, vytvořit obchodní web, dokumentaci vyladit apod. Když člověk něco programuje, tak ví přesně co je nutné udělat, aby se dostal k cíli, ale při plánování obchodní strategie je sice možné se opřít o řadu analýz a dat, ale pořád je tam tak velká míra nejistoty, že jsem sám ve velkém očekávání jak to bude dále pokračovat.

Dotažení samotného (technického) produktu do finálního stavu je kapitola sama pro sebe. Člověk zvyklý na projektové zakázky je často překvapený co vše a do jaké míry detailu musí řešit. Nestačí pouze, že něco má fungovat dle požadavků zákazníka, ale musí to fungovat prostě pro všechny možné požadavky, které člověk ani nezná – správně navrhnout architekturu celého řešení, vydefinovat API s citem proto, aby bylo dostatečně flexibilní pro možné realizace, ale zase dostatečně omezující z pohledu interní implementace a dalšího rozvoje API nebo dotáhnout a vyladit dokumentaci, která nebude jen popisem funkčnosti, ale bude nabízet i pohled pro člověka, který řešení moc nezná a chce ho začít používat. Testování a kvalita kódu je při vývoji produktu něco tak samozřejmého, že o tom netřeba snad ani psát. Často to je jediná možnost jak si sám ověřit, že něco funguje před tím, než to někdo začně reálně používat na projektu. 

Jak to tak bývá, tak jsme si na začátku dali do fronty spoustu nové funkčnosti do nové verze, kterou jsme nakonec museli škrtat, protože bychom takto žádnou verzi nikdy nevydali. Rozhodnutí o nové verzi padlo někdy v listopadu s cílem do konce března mít vývoj ukončený a jen ladit. Nicméně ještě v červenci jsme vyvíjeli, ladili a některé funkčnosti přesouvali do další (minor) verze. Už nám bylo jasné, že musíme být na sebe přísní, dělat jen opravdu ty nutné věci, které vedou k dokončení verze, nic jiného. Také jsme ke konci změnili strategii tím, že jsme vydali nejdříve beta verzi, protože jsme si uvědomili, že těch změn je tam opravdu hodně a bude chvíli žádoucí, aby si to sedlo, abychom dostali zpětnou vazbu od ostatních z reálných projektů. I když máme stále hodně práce před sebou, tak úleva z vydané verze byla opravdu znát.

Vývoj probíhal (většinou) po večerech v pěti lidech. To mělo jednu velkou výhodu i nevýhodu – výhodou bylo to, že nás to muselo bavit, protože jsme to dělali převážně ve svém volném čase. A to myslím, že je u těch nových věcí vidět, že každý se to snažil dělat dle svého nejlepšího přesvědčení, že jsme měli čas věci rozmýšlet, fungovalo vzájemné review návrhů i kódu, prostě žádný stress z termínu. Nevýhodou bylo, že už to bylo dlouhé a časem se nám po večerech už moc dělat nechtělo – dostavila se únava a nechuť. To jsme částěčně řešili tím, že někdo začal vyvíjet OpenHub během své denní pracovní náplně, někdo si dal přestávku a pak se do toho zase pustil.

Je to pár dní, co jsme spustili produktový web www.openhub.cz, odreleasovali beta verzi a jsme zvědaví jak se to bude vyvíjet dál. Rádi bychom, aby to někdo další začal používat, v lepším případě nám pomohl s vývojem a úplně v ideálním případě, aby si od nás někdo koupil support nebo vývojový balíček. Nicméně i bez toho, že bychom na tom začali vydělávat velké peníze, tak to pro nás má řadu výhod – otevírá nám to cestu k novým projektům, protože je to celkem velká konkurenční výhoda, když můžete říci, že používáte vlastní integrační řešení (navíc open source, rozšířitelné, žadný vendor lock-in, žadné licenční poplatky, s možností využití všech nástrojů, které běhají s Apache Camel atd.), které dle potřeb umíte rozšířit a rychle zafixovat v případě chyby. Navíc nikdo nebude efektivněji vývíjet než vy sám, když znáte každý šroubek celého řešení ...

Podařilo se nám dotáhnout jednu věc až do cíle a máme spoustu nových zkušeností a znalostí. A to se počítá! :)

2 komentáře:

Petr Flídr řekl(a)...

Gratuluji k vytrvalosti. Mám 2 dotazy:
1) Proč o produktu ještě nemáte post na linkedin?
2) Jaké jsou hlavní důvody, proč by někdo další měl použít právě Váš produkt, namísto třeba WSO2 ESB?

Petr řekl(a)...

1) na LinkedIn urcite informaci budeme davat, ale delame to postupne - jednak kvuli zpetne vazbe, abychom mohli postupne vylepsovat a pak taky vse merime a sledujeme
2) odpoved je slozitejsi, zkusim strucne odpovedet:
- osobne jsem vyzkousel radu integracnich frameworku a nejlepsi je podle me Camel. Hlavni duvody je velikost komunity, mnozstvi nastroju a rozsireni tretich stran, podpora RadHatu, staly rozvoj a take z pohledu kodu a dokumentace me to prijde celkem kvalitni (nikoliv jako je clovek zvykly u zdrojaku Springu, ale neni to tak hrozne)
- WSO2 sice pusobi na prvni pohled, ze maji pro vsechno neco, ze to cele dohromady bude pekne fungovat, ale moje zkusenost je takova, ze jsme meli problem kdykoliv jsme potrebovali neco rozsirit, zmenit, delat jinak. Kvalita jejich kodu me prijde podprumerna
- a proc OpenHub a ne Camel nebo jine open-source projekty? Camel je vlastne routing engine, nikoliv kompletni reseni k nasazeni. My jsme vyladili aplikacni stack a pridali spoustu novych funkci. Zejmena kolem zpracovani asynchronnich zprav je toho tolik, ze neznam jiny open-source reseni, ktere by to takto podporovalo. Podpora clusteru je dalsi vec. Prehled vsech tech duvodu je zde: https://openhubframework.atlassian.net/wiki/spaces/OHF/pages/33600/Why+OpenHub+framework