Home » Content Matters! » Beter Versiebeheer Voor Content Management Systems?

Beter Versiebeheer Voor Content Management Systems?

Voor de meeste ontwikkelaars is de zaak duidelijk: je hebt een versiebeheersysteem (VCS = Version Control System) voor broncode en bijbehorende bestanden nodig, en dat VCS moet bij voorkeur worden geïntegreerd in je editor. Versiebeheer voor artikelen, blog posts, technische documenten, wetten, persberichten, romans, poëzie, handleidingen, etc. is vaak beperkt tot het opslaan van een versie van de tekst met een nieuwe naam waarin een tijdstempel of een volgnummer zijn opgenomen.

In ‘The Meta-Story: How Wired Published Its GitHub Story on GitHub‘ schrijven de Wired-redacteuren over hun eigen ervaringen met Git en GitHub. Voor een ontwikkelaar is hun conclusie niet zo verrassend: samen-schrijven is niet altijd eenvoudig, of het nu gaat om een tijdschriftartikel of een stukje programmacode. Je zou zelfs kunnen zeggen: “hoe meer (medewerkers), hoe rommeliger“! Vergis je niet: gedistribueerde versiebeheersystemen (DVCS) zoals Git en Mercurial maken het werk al makkelijker dan de oudere gecentraliseerde tools, maar zelfs dan zal het niet eenvoudig zijn – samenwerken gaat over mensen, en gereedschap kan het proces soms eerder belemmeren dat het te helpen.

Hoe dan ook, ik heb het hier over dit onderwerp omdat ik er sinds vele jaren van overtuigd ben dat een goed content management systeem (CMS) uitgebreide faciliteiten voor versiebeheer moet omvatten. Ik denk niet dat ik met woorden speel als ik zeg dat programmeurs hun source code (onder versiebeheer, natuurlijk) “publiceren” in een andere vorm. Die andere vorm  kan een gecompileerd programma of een code library zijn, of ondersteunende bestanden voor hun toepassingen. We zien hier enkele opeenvolgende fasen: opslag van de invoer onder versiebeheer, transformatie van de invoer, en publicatie. Merk op hoe die fasen zijn vrij gelijkaardig aan wat er gebeurt in veel content management systemen, met uitzondering van de woorden “onder versiebeheer”?

Jawel, tools zoals WordPress houden de historiek bij van de opeenvolgende versies van een bericht. Dat is OK voor een bericht op een blog – meestal verander je een blog post niet meer eens hij is gepubliceerd. Maar hoe zit dat met een document dat wordt geschreven door meerdere auteurs binnen een onderneming? In zijn bestaanscyclus kan een dergelijk document worden onderworpen aan een reeks bewerkingen die niet als een eenvoudige, lineaire lijst van opeenvolgende versies kan beschreven worden. Het antwoord op de vraag “Welke versie van het document diende als basis voor deze bewerking?” hoeft niet noodzakelijk de laatst bewaarde versie te zijn. Een DVCS kan alle informatie over parallelle en weer samenvloeiende versies op een compacte en veilige manier opslaan.

Wat ik voorstel is dus een samengaan van CMS en DVCS. Vraag me alleen niet hoe dergelijke tool er moet gaan uitzien in termen van de gebruikersinterface – CMS en DVCS zijn apart al ingewikkelde toepassingen, zodat hun samenvoeging wel eens een monster zou kunnen creëren dat niemand wil gebruiken!

Hebben alle huidige en toekomstige CMS deze injectie van DVCS nodig? Niet per se, want zoals wel meer gebeurt luidt het juiste antwoord: “het hangt ervan af” .

Neem blogging tools , bijvoorbeeld. Een blog is per definitie de uitdrukking van een (persoonlijke of groeps-) kijk op de wereld, en de commentaren op een blog post zijn een vorm van gesprek, en niet één enkel document. Voor blogs is de te volgen weg beschreven door Dave Winer (natuurlijk!) In zijn post “What kind of blogging do we want?: iedere schrijver heeft zijn of haar eigen gereedschap-met-repository, en een blogpagina met commentaar wordt dan opgebouwd door de ‘blog engine’ die de nodige stukken tekst ophaalt uit de repositories die deelnamen aan de specifieke discussie. Elk tool kan dan zelf beslissen of (en welk) versiebeheer het toepast, volgens de eisen of wensen van elke deelnemer.

Enterprise Content Management (ECM) systemen, aan de andere kant van het spectrum, hebben absoluut versiebeheer-voorzieningen nodig, en de bestaande ECM systemen bieden dan ook een vorm van versiebeheer aan. Maar de aangeboden functionaliteiten zijn meestal heel eenvoudig. Neem Microsoft SharePoint, bijvoorbeeld: het kent kladversies en finale versies, en het kan vele opeenvolgende versies opslaan, indien het daartoe geconfigureerd wordt. Maar SharePoint kent geen vertakkingen en geen samenvoegingen van versies, om maar die twee aspecten te noemen die elke doorgewinterde ontwikkelaar vaak gebruikt. Hier kan meer versiebeheer een zeer welkome aanvulling zijn.

Zullen ECM-leveranciers betere versiecontrolesystemen in hun produkten opnemen? We zullen zien…

Maar ik ben zeker niet de enige die de voordelen ziet van (gedistribueerd) versiebeheer in andere authoring tools dan software- ontwikkelomgevingen.

Lees bijvoorbeeld deze “Wish List for a Powerful Collaborative Writing Platform“, waarin auteur Konrad Lawson begint bij Github om te eindigen met een platform dat “.…would allow us to incorporate a variety of rich content hopefully without destroying our ability to work offline with most of our local materials when we have to“. En kijk ook naar Wired’s artikel “Donglegate Controversy Yields Only One Winner: GitHub“, dat erop lijkt te wijzen dat GitHub het niet erg zou vinden om deel uit te maken van een ECM-oplossing met veel meer versiebeheerfuncties dan er vandaag beschikbaar zijn.

Het zal interessant zijn om te zien hoe dit verhaal zich in de komende jaren verder ontwikkelt; sommige van de nieuwe “authoring tools” die ik een paar dagen geleden opsomde zouden zich wel eens heel goed kunnen ontwikkelen tot een instrument zoals Konrad Lawson het zich voorstelt.

(Oorspronkelijk gepubliceerd op mijn Engelstalige blog, op 4 november 2013)

Advertenties

Geef een reactie

Gelieve met een van deze methodes in te loggen om je reactie te plaatsen:

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s