Aarzel niet om het wiel opnieuw uit te vinden als u wilt dat uw software met open source componenten langer meegaat.

Het probleem: een klant wil een applicatie met een bepaalde functionaliteit en wil dit gisteren. Wat je doet is op zoek gaan naar een plug-and-play oplossing, bibliotheken en/of extensies. Je vertelt je klant dat je het kunt, klant is blij, je doet het. U neemt bijvoorbeeld Wordpress, selecteert en configureert enkele plugins. Probleem opgelost, of wel?

Ja, het probleem is opgelost, maar voor hoe lang? Na enkele maanden wordt Wordpress geüpdatet vanwege een kwetsbaarheid. Dan werken sommige plugins of thema's ineens niet meer. Dan gaat PHP naar PHP 7.4 en weer werken sommige plugins of thema's niet meer. Uiteindelijk dwingt dit u of uw klant om oudere, vaak kwetsbare, versies van software te draaien. Maar dit kan ook uw business model zijn, updates.

Grote technische bedrijven dwingen tot verandering om de concurrentie uit te schakelen

Het ontwikkelen van software die een paar jaar meegaat is erg moeilijk. Standaardveranderingen worden vaak geïnitieerd door grote technische bedrijven. Natuurlijk willen ze de standaarden veranderen. Ze noemen het verbetering, ze noemen het vooruitgang, maar het is gewoon essentieel voor hun bedrijf om nieuwe functies toe te voegen, en oude te stoppen. Het is een perfecte en legitieme manier om de concurrentie uit te schakelen.

Kijk bijvoorbeeld wat Google doet met Android. Elk jaar brengen ze een nieuwe versie uit. En alle telefoonfabrikanten moeten volgen. Is de nieuwe versie beter? Meestal niet! Ze doen grote herschrijvingen van bepaalde delen van de code, dus als je had geprobeerd te begrijpen en gewend was geraakt aan de internals van versie X is je kennis niets waard als de volgende versie wordt uitgebracht. Ja, ze introduceren ook nieuwe kwetsbaarheden, maar dit zijn gewoon fouten. Een miljarden softwarebedrijf heeft natuurlijk niet de middelen om hun software grondig te analyseren en te testen. Google dwingt ook websites om HTTPS te gebruiken. Ik weet dat dit voor veel niet-technologische mensen een goed idee is. Maar nu gebruiken veel websites certificaten van Letsencrypt, een andere afhankelijkheid. En Letsencrypt concurrenten zijn niet toegestaan, dank u allen!

Open source ontwikkelaars creëren verandering

Ik wil zeggen dat ik erg blij ben met de beschikbaarheid van open source software. Ik respecteer de open source -ontwikkelaars en -gemeenschappen zeer. Zonder hen zou de software die we vandaag de dag gebruiken totaal anders zijn. Open source software dwingt grote techneuten om na te denken over veranderingen, om nieuwe versies te blijven ontwikkelen, om voorop te blijven lopen. In veel opzichten creëren open source ontwikkelaars vaak veranderingen zonder dat ze het weten.

De levensduur van open source software is vaak korter dan die van commerciële software.

Als u de open source software gebruikt om uw applicaties te bouwen, heeft u vele redenen om heel voorzichtig te zijn. Zoals veel mensen hebben gezegd, is het erg moeilijk om geld te verdienen met open source software en projecten. Open source software wordt vaak ontwikkeld door één of enkele personen omdat ze het nodig hebben voor iets en het dan delen met de wereld, in feite het weggeven ervan. Veel ontwikkelaars hopen dat andere mensen betrokken raken bij hun project, maar vaak is dat niet het geval. Na verloop van tijd begint de ontwikkelaar aan andere projecten te werken, of krijgt hij een tijdrovende klus en heeft hij niet de tijd om zijn software te onderhouden. Je kunt dit de donkere kant van open source software noemen.

Laten we eens kijken naar de software die ik gebruik voor deze website

Deze website is gebouwd met Python 3, de framework Flask, enkele Flask uitbreidingen, SQLAlchemy, Bootstrap 4, jQuery, MariaDb. Zal Python 3 de komende vijf jaar overleven? Ik hoop het. Python 2 was een vergissing omdat het essentiële functionaliteit miste. De beheerders van Python hebben besloten om Python 3 niet achterwaarts compatibel te maken met Python 2. Om deze reden zou Python 2 moeten voortleven als een onafhankelijke taal van Python 3, maar de gemeenschap besloot het niet meer te ondersteunen. Niet goed, maar ik kan dit begrijpen. De belangrijkste reden is dat de gemeenschap geen geld verdient aan het ondersteunen van Python , dus ze gaan voor Python 3. Python 2 is een heel goed voorbeeld van wat er mis kan gaan met open source software.

Zal Flask de komende vijf jaar overleven? Ik hoop het, maar ik ben bang. De maker en hoofdontwikkelaar van Flask zal de komende jaren wellicht zijn tijd aan andere projecten willen besteden. Kunnen andere personen het overnemen? Ik ben niet overtuigd. Flask extensies zijn een ander ding. Ze worden meestal door individuen ontwikkeld. Flask werd in 2010 geïntroduceerd en een groot aantal extensies zijn al jaren niet meer geüpdatet, wat zal het lot zijn van de extensies die u vandaag met uw product aanbiedt?

Hetzelfde geldt voor SQLAlchemy, een prachtig stukje software, ORM zoals het hoort. Maar wat gebeurt er als de maker besluit te stoppen en iets anders te doen? Bootstrap is open source en ze lijken een beleid te hebben om verder te gaan met het breken van eerdere versies. Ik ben nu op Bootstrap 4 maar neem aan dat u op Bootstrap 3 was en moest migreren naar Bootstrap 4. Geen gemakkelijke taak. Bootstrap kondigde al versie 5 aan, die zonder jQuery zal werken. Ik kijk uit naar deze migratie ... NIET.

jQuery wordt erg veel gebruikt, maar zal proberen om de veranderingen bij te houden die door de grote technologie worden geforceerd. Ik kan alleen maar hopen dat ze de capaciteit hebben om dit te doen. Projecten als jQuery-UI en jQuery-Mobile zijn min of meer dood. En dan is er nog MariaDb. Ik geloof dat ze hier minstens vijf jaar blijven omdat ze een zeer goed product leveren. Ik denk ook dat Oracle wil dat ze bestaan, omdat ze de Oracle -ontwikkelingen stimuleren. MariaDb verkoopt ook ondersteuning, maakt geld, heel belangrijk.

Moet u de software open source gebruiken om uw volgende applicatie te ontwikkelen?

Is software van commerciële organisaties beter? In veel gevallen is het antwoord nee. Maar je krijgt wel ondersteuning en het is voor hen essentieel om up-to-date te blijven. Toch denk ik dat het een goede keuze is om open source componenten te gebruiken om nieuwe software te maken. Maar alleen als je eerst het levensprobleem van de componenten grondig onderzoekt. En natuurlijk moet je eerst de licenties controleren.

Het minimaliseren van risicovolle afhankelijkheden door het schrijven van uw eigen componenten

Vele jaren geleden nam ik een project over dat in Perl werd geschreven. Toen PHP aankwam bouwde ik mijn eigen kleine framework en zette deze om in PHP. Omdat ik geen bibliotheken gebruikte was alles onder mijn controle. Gelukkig bleek PHP redelijk achterwaarts compatibel te zijn, wat betekent dat het niet veel moeite kostte om naar nieuwe versies te migreren. Veel PHP frameworks kwamen en gingen weg, maar mijn PHP software draait nog steeds. Maar natuurlijk kon het alleen overleven omdat ik er was. Ik zie vaak op websites als Stackoverflow opmerkingen dat je het wiel niet opnieuw moet uitvinden. Maar je eigen componenten ontwikkelen is vaak NIET het wiel opnieuw uitvinden!

• u kunt gebruik maken van kennis van reeds bestaande soortgelijke projecten
• je kunt het opgeblazen gevoel weglaten
• U kunt ontbrekende functionaliteit toevoegen in plaats van iemand te bestrijden die de code ontloopt.
• u kunt moeilijk te begrijpen code van anderen overslaan...
• u kunt uw componenten zelf updaten in plaats van te wachten op anderen...
• je leert veel door te kijken naar code van anderen

Ik las op het internet dat sommige mensen dat een soort arrogantie vinden als iemand besluit om zijn eigen component te schrijven. Ik ben het daar helemaal niet mee eens, er is geen zwart-wit en het is aan jou of je team om te beslissen wanneer je je eigen component gaat bouwen. Er zijn veel redenen om het niet te doen, maar ook veel redenen om het te doen. Weeg ze zorgvuldig.

Twee componenten die ik recentelijk heb gebouwd: datepicker en Jinja Bootstrap macro

In een eerder project heb ik de jQuery datepicker gebruikt. Leuk, maar ... na enige tijd had ik functionaliteit nodig zoals het verhuizen naar een andere maand zonder een datum te selecteren. Dat was het begin van veel hoofdbrekens om hieromtrent en andere beperkingen de hele tijd te werken. Voor deze website heb ik ook een datepicker nodig, deze moet geïntegreerd zijn met Flask en WTForms en deze moet voldoen aan de Content Security Policy. Dit laatste kan worden opgelost door de datepickerparameters uit Python te exporteren als application/json.
De Jinja Bootstrap macro moet het zeer eenvoudig maken om allerlei formulieren te genereren, het moet flexibel zijn en een breed scala aan velden ondersteunen, waaronder mijn eigen datepicker. Ik heb een hekel aan het bouwen van formulieren 'met de hand', d.w.z. het apart zetten van alle formuliervelden in een sjabloon wanneer dit met een beetje extra moeite in de macro kan worden gedaan door gewoon te schrijven:

{{ bootstrap_form(demo_form, id='demo_form') }}

Omdat ik beide componenten van vitaal belang acht voor mijn toekomstige inspanningen, heb ik besloten om beide zelf te schrijven.

Samenvatting

Wanneer u uw software bouwt met open source componenten neemt u vaak meer risico's dan wanneer u commerciële componenten gebruikt. Luister niet naar anderen, neem uw eigen beslissingen en wees niet bang om uw eigen componenten te schrijven. Wanneer u uw eigen componenten schrijft, is de belangrijkste regel om het leesbaar te houden zodat anderen het kunnen begrijpen. Een probleem met veel open source componenten is dat ze geoptimaliseerd zijn. Dat is mooi, maar optimalisatie vertaalt zich vaak niet naar leesbaarheid. Tegenwoordig zijn computers en telefoons veel krachtiger en moeten optimalisaties alleen worden overwogen als ze absoluut noodzakelijk zijn.

Links / credits

How to make money from open source software
https://www.cio.com/article/3178621/how-to-make-money-from-open-source-software.html

Open Source, SaaS and Monetization
https://lucumr.pocoo.org/2019/11/4/open-source-and-saas/

REINVENT THE WHEEL | meaning in the Cambridge English Dictionary
https://dictionary.cambridge.org/dictionary/english/reinvent-the-wheel