Wat is de vork een 'vork'?

De afgelopen dagen heeft u waarschijnlijk het woord 'vork"vaker dan je kunt tellen. Facebook heeft dit gesplitst (hoewel dat niet het geval was), Amazon heeft dat gesplitst, het Chrome-team heeft het hele web gesplitst, enzovoort, enzovoort. Terwijl iedereen het heeft over wie wie forking maakt, doet niemand de moeite om uit te leggen wat forking precies is en waarom zoveel mensen er een probleem mee hebben.

Forking, of shattering, kreeg een beetje een slechte reputatie 20 jaar of zo geleden, omdat het de neiging had om ontwikkelaars op te splitsen in afzonderlijke facties die de code niet met elkaar deelden. In de dagen van zaken als de splitsing van Gnu-Emacs / XEmacs, was dit belangrijk omdat er lang niet zoveel mensen waren die in staat waren om te werken op deze grote, open-sourceprojecten, en met twee branches of forks betekende het dat het langer duurt om functies toe te voegen en problemen op te lossen voor beide zijkanten. In sommige gevallen gebeurt dit nog steeds, ik weet het zeker, maar voor het grootste deel zijn er genoeg ontwikkelaars die de leegte kunnen vullen die is achtergelaten door degenen met een aparte visie en code zullen splitsen om deze te volgen. Maar sommige mensen vergeten het nooit, en het stigma dat aan forking forkers kleeft, wordt doorgegeven. Dit alles gezegd hebbende, kunnen we niet doen alsof er geen slechte vorken zijn. We hoeven alleen maar voorbij de handeling zelf te kijken voordat we onze beslissingen nemen.

Ik ken een paar van jullie die weten wat dit allemaal betekent, en ze proberen gewoon al het lawaai te negeren, maar voor velen is het verwarrend. Laten we proberen dat op te lossen.

Denk aan Android een heleboel code. Er zijn twee delen: de open-source delen, dat is wat AOSP is, en de propriëtaire delen die Google voor zichzelf houdt. Als iemand Google Android wil gebruiken en er wijzigingen in wil aanbrengen, zal hij de code downloaden om als basis te gebruiken en er zijn eigen project mee opzetten. Samsung doet dat, HTC doet dat en je favoriete ROM-ontwikkelaar doet het misschien. Elke keer dat iemand een bestaande code pakt, en een onafhankelijk (dat is een belangrijk onderscheid) project daarop gebaseerd, hebben ze een splitsing gemaakt. Veel ontwikkelaars zullen de code uitchecken, delen ervan bewerken en hun wijzigingen vervolgens in hun geheel stroomopwaarts sturen, wat geen vork is.

Amazon trok nogal wat wenkbrauwen op toen Android werd gevorkt om het besturingssysteem voor de Kindle Fire-lijn te bouwen. Maar aan de open-source kant was het niet anders dan wat Motorola deed met de Cliq, of HTC deed met de Hero - of wat Samsung nu doet voor de Galaxy-serie. Dit is hoeveel grote open-sourceprojecten werken. Elke leverancier (behalve misschien Amazon) werkt met dezelfde basisprincipes, waarbij hij waarschijnlijk bugs rapporteert en reparaties stroomopwaarts indient om zo zijn eigen kijk op het eindproduct te creëren.

Facebook heeft Android niet geforkst. Het gebruikte het Android-intentiesysteem (een manier waarop apps met elkaar kunnen samenwerken en delen op Android) en bouwde een grote app die bovendien een vervangend huis bevat. In hun sandbox kunnen ze doen wat ze willen of moeten doen, en zolang ze de intenties van Android gebruiken, kunnen ze communiceren met de rest van het systeem. Als je technisch wilt worden, heeft HTC mogelijk Android gevorkt om beter te werken met Facebook Home in de HTC First, omdat het enkele wijzigingen noemt die zijn aangebracht voor een betere compatibiliteit. We zullen meer weten over wat ze hebben gedaan als de telefoon eruit druppelt.

Forking code is in ieder geval niet altijd een slechte zaak en verdient niet alle negativiteit die je hoort als iemand het noemt. Industrie-analist Stephen O'Grady vat het mooi samen I denk:

Het is echter vermeldenswaard dat vanuit het oogpunt van de klant, vorken of varianten niet universeel slecht zijn. Hoewel de verschillende Android-versies ongelukkige ontwerpbeslissingen kunnen vertegenwoordigen van de kant van de verantwoordelijke leveranciers deze applicaties zijn in de overgrote meerderheid van de gevallen compatibel van apparaat tot apparaat, uitgaande van de versie gelijkwaardigheid.

Het hebben van apps die compatibel zijn van apparaat tot apparaat, is de reden waarom Android is ontworpen. Forking-code zorgt er niet voor dat dit niet gebeurt. Maar andere dingen doen.

De andere kant van Android

In China kun je een telefoon kopen bij een provider die Android draait, maar geen Google-services heeft? Net als de Kindle Fire is het gebouwd op basis van de Android-code van Google (soms niet gewijzigd), maar het is niet ingediend en getest om Google-compatibel te zijn en bevat zaken als Gmail of Google Play. Die apps, en de verschillende systeembestanden die ze nodig hebben, zijn niet open-source en je kunt ze niet zomaar opnemen zonder toestemming van Google.

Afgezien van een "andere" (ik ga niet zeggen dat het "slechter" is, alleen anders) gebruikerservaring zonder deze apps, kunnen ze eruitzien en aanvoelen als een Android-telefoon die u bij Verizon of AT&T koopt. Ze kunnen er ook heel anders uitzien en aanvoelen, zoals Amazon heeft gedaan. Maar dit komt niet doordat ze de Android-code van Google hebben afgesplitst - het was een bewuste beslissing om geen Google "gecertificeerd" apparaat te maken. Google presenteert Android als een applicatieplatform en een set app-frameworks. Als de servicetoepassingen van Google niet worden meegerekend, is het niet minder een app-platform. We stellen ons natuurlijk voor dat Google liever alle Android- en Android-apparaten de services van Google laat gebruiken, maar er is geen vaste regel die zegt dat een leverancier het moet doen.

Apparaten maken zonder de apps van Google heeft niets te maken met het forken van Android. Het kan apparaten minder aantrekkelijk maken, of op een dag zou de ultieme Android-telefoon kunnen worden gebouwd zonder de apps van Google, maar het kan gebeuren zonder code te forceren. We zijn allemaal schuldig aan het samenvoegen van de twee dingen, maar we zouden het niet moeten doen.

Forking is gewoon een ding

Het is niet goed dat OEM's Android uitdelen en met de code aan hun eigen project werken. Het is niet erg dat OEM's Android uitdelen en met de code aan hun eigen project werken. Het is gewoon een ding dat ze allemaal doen.

Afgezien van de Nexus-fanclub, kun je me niet vertellen dat Samsung of HTC Android heeft verpest door de code te forken en erop voort te bouwen. Ze voegden functies toe terwijl alles compatibel bleef, zodat applicaties die voor "Android" zijn gebouwd volgens de richtlijnen voor ontwikkelaars prima zullen werken. En ze leveren consequent apparaten die mensen willen kopen. Ik denk dat dit precies is wat Google in gedachten had voor Android. Ze wisten dat uiteindelijk iemand iets verder zou gaan en iets zou maken dat niet volledig "Android" -compatibel is, maar dat is oké. Gebruikers van die apparaten zijn nog steeds op internet en de mobiele web-apps van Google zijn behoorlijk behoorlijk.

Hopelijk weet je nu wat meer over wat mensen bedoelen als ze het hebben over het forken van Android.