Salesforce-packagingmodellen voor ISV's: 1GP vs 2GP vs Unmanaged

Voor een ISV die een commercieel AppExchange-product bouwt, is het packagingmodel een eenrichtingsdeur: je namespace, je upgradepad en je IP-bescherming liggen allemaal vast door deze ene vroege beslissing. Second-Generation managed packages (2GP) zijn tegenwoordig de juiste standaard voor bijna elk nieuw commercieel product. First-Generation (1GP) blijft voorbehouden aan legacy-uitzonderingen, en unmanaged packages vallen helemaal af voor alles wat je wilt verkopen.

Wat is het verschil tussen 1GP, 2GP en unmanaged packages?

Een unmanaged package heeft geen namespace en levert volledig bewerkbare metadata. Dat is prima voor opensource-templates of een eenmalige deployment, maar zodra het binnen is, is elk component niet meer te onderscheiden van de eigen aanpassingen van de klant. Je verliest de mogelijkheid om wat je hebt gebouwd te herkennen, te ondersteunen of veilig te upgraden.

Een managed package, of het nu 1GP of 2GP is, heeft een namespace en is afgeschermd. Klanten installeren en gebruiken het, maar kunnen de interne onderdelen niet rechtstreeks bewerken. Dat maakt het een product in plaats van een eenmalige deployment: jij bepaalt het releasetempo en Salesforce bewaakt de grens voor je.

Het verschil tussen 1GP en 2GP gaat over tooling en org-afhankelijkheid. 1GP-packages worden gebouwd en geversioneerd in een speciale packaging org, die een permanent en onvervangbaar onderdeel van je releasepipeline wordt. 2GP-packages zijn brongestuurd, worden vanuit versiebeheer gebouwd met de Salesforce CLI en hebben helemaal geen vaste packaging org nodig. Daarom stuurt Salesforce nieuwe ISV's al jaren richting 2GP.

Waarom is je namespace een permanente beslissing?

Zodra een namespace is geregistreerd op een Developer Edition-org en gebruikt in een uitgebracht package, kan die niet meer worden hernoemd, naar een andere org worden overgezet of opnieuw worden gebruikt. Elke Apex-klasse, elk custom field en elk object dat je product ooit levert, draagt die prefix voor altijd in elke klant-org. Typefouten, onhandige afkortingen en overhaaste naamkeuzes krijgen geen tweede kans. Plan de namespace als een productnaam, niet als technische bijzaak.

Hoe werken IP-bescherming en licenties echt?

Managed packages compileren Apex naar bytecode die klanten niet kunnen bekijken of bewerken. Dat is de basis-IP-bescherming die elk commercieel product nodig heeft voordat het in de buurt komt van de AppExchange Security Review. Unmanaged packages bieden daar niets van: je bedrijfslogica wordt geleverd als gewone, leesbare en kopieerbare metadata.

Licenties zijn een aparte laag. Om seats, trials en vervaldatums echt te meten, koppel je je package aan een License Management App (LMA), die installaties bijhoudt tegenover je leads en opportunities. Dat werkt alleen goed met managed packages: er is geen betrouwbare manier om rechten te licentiëren en af te dwingen op iets wat een klant vrij kan bewerken.

En unlocked packages?

Unlocked packages zitten tussen deze werelden in: met namespace en versiebeheer zoals 2GP, maar met bewerkbare metadata en zonder licentiehandhaving. Ze zijn gemaakt voor interne deployment over meerdere orgs binnen één bedrijf, niet voor verkoop aan onbekenden op de AppExchange. Gebruik ze niet als shortcut om commerciële packaging te omzeilen.

Welk packagingmodel past bij de fase van je ISV?

• Vandaag een nieuw AppExchange-product bouwen: gebruik 2GP. Versiebeheer via de CLI, ancestry tracking voor upgrades en geen afhankelijkheid van een kwetsbare packaging org.
• Een ouder 1GP-product overnemen of onderhouden: blijf op 1GP tot er een doordacht migratieplan is. Namespace en abonneebestand gaan mee, maar de conversie kent echte technische beperkingen.
• Gratis, bewerkbare tooling of templates distribueren: unmanaged is hier legitiem, juist omdat je geen IP beschermt en geen upgrades in rekening brengt.
• Deployments standaardiseren over je eigen orgs: unlocked packages, geen managed packages die voor doorverkoop zijn gebouwd.

Een verkeerde keuze is duur om terug te draaien. Daarom begint het productontwikkelingswerk van Tekunda met AppExchange-partners met precies deze beslissing, nog voordat er één component wordt gebouwd, want elke keuze daarna over governance, testen en releases hangt ervan af.

FAQ

Kan ik later overstappen van unmanaged naar managed?

Niet rechtstreeks. Je bouwt de componenten opnieuw in een managed package met namespace en voert een echte klantmigratie uit, omdat de onderliggende metadata en ID's niet netjes meekomen.

Kan ik een 1GP-package omzetten naar 2GP?

Ja, Salesforce ondersteunt het omzetten van 1GP managed packages naar 2GP met behoud van dezelfde namespace en abonnee-orgs, al vraagt dat om zorgvuldige planning rond package ancestry en bestaande installaties.

Heb ik een namespace nodig als ik niet op de AppExchange verkoop?

Alleen als je een managed of unlocked package over meerdere orgs distribueert. Een enkele interne deployment via unmanaged metadata of change sets heeft er geen nodig.

Is 2GP verplicht voor een AppExchange-vermelding?

Nee, 1GP-packages worden nog steeds ondersteund en vermeld, maar de toolinginvesteringen van Salesforce zitten volledig in 2GP, en de meeste nieuwe ISV-builds beginnen daar het best. Praat met Tekunda of bekijk de blog als je deze beslissing voor een komende build afweegt.