Salesforce-Packaging für ISVs: 1GP vs. 2GP vs. Unmanaged

Für einen ISV, der ein kommerzielles AppExchange-Produkt baut, ist das Packaging-Modell eine Einbahnstraße: Namespace, Upgrade-Pfad und IP-Schutz werden alle durch diese eine frühe Entscheidung festgelegt. Managed Packages der zweiten Generation (2GP) sind heute für fast jedes neue kommerzielle Produkt die richtige Standardwahl. Die erste Generation (1GP) bleibt Altfällen vorbehalten, und Unmanaged Packages scheiden für alles aus, was Sie verkaufen wollen.

Was ist der Unterschied zwischen 1GP-, 2GP- und Unmanaged Packages?

Ein Unmanaged Package hat keinen Namespace und liefert vollständig bearbeitbare Metadaten. Das ist für Open-Source-Templates oder ein einmaliges Deployment in Ordnung, aber sobald es angekommen ist, lässt sich jede Komponente nicht mehr von den eigenen Anpassungen des Kunden unterscheiden. Sie verlieren die Möglichkeit, das Gebaute zu identifizieren, zu unterstützen oder sicher zu aktualisieren.

Ein Managed Package, ob 1GP oder 2GP, hat einen Namespace und ist gesperrt. Kunden installieren und nutzen es, können die internen Bestandteile aber nicht direkt bearbeiten. Genau das macht es zu einem Produkt statt zu einem einmaligen Deployment: Sie steuern den Release-Takt, und Salesforce setzt die Grenze für Sie durch.

Der Unterschied zwischen 1GP und 2GP liegt bei Tooling und Org-Abhängigkeit. 1GP-Packages werden in einer eigenen Packaging Org gebaut und versioniert, die zu einem dauerhaften, unersetzlichen Teil Ihrer Release-Pipeline wird. 2GP-Packages sind quellgesteuert, werden mit der Salesforce CLI aus der Versionskontrolle gebaut und brauchen überhaupt keine dauerhafte Packaging Org. Deshalb lenkt Salesforce neue ISVs seit Jahren in Richtung 2GP.

Warum ist Ihr Namespace eine endgültige Entscheidung?

Sobald ein Namespace auf einer Developer Edition Org registriert und in einem veröffentlichten Package verwendet wurde, lässt er sich weder umbenennen noch auf eine andere Org übertragen oder wiederverwenden. Jede Apex-Klasse, jedes Custom Field und jedes Objekt, das Ihr Produkt jemals ausliefert, trägt dieses Präfix für immer in jeder Kunden-Org. Tippfehler, ungeschickte Abkürzungen und übereilte Namen bekommen keine zweite Chance. Planen Sie den Namespace wie einen Produktnamen, nicht wie ein technisches Detail.

Wie funktionieren IP-Schutz und Lizenzierung wirklich?

Managed Packages kompilieren Apex zu Bytecode, den Kunden weder einsehen noch bearbeiten können. Das ist der grundlegende IP-Schutz, den jedes kommerzielle Produkt braucht, bevor es in die Nähe der AppExchange Security Review kommt. Unmanaged Packages bieten nichts davon: Ihre Geschäftslogik wird als offene, lesbare und kopierbare Metadaten ausgeliefert.

Lizenzierung ist eine völlig eigene Ebene. Um Seats, Testphasen und Abläufe tatsächlich zu messen, verbinden Sie Ihr Package mit einer License Management App (LMA), die Installationen mit Ihren Leads und Opportunities abgleicht. Das funktioniert sauber nur mit Managed Packages: Für etwas, das ein Kunde frei bearbeiten kann, gibt es keinen verlässlichen Weg, Berechtigungen zu lizenzieren und durchzusetzen.

Und Unlocked Packages?

Unlocked Packages liegen zwischen diesen Welten: Namespace und Versionskontrolle wie bei 2GP, aber bearbeitbare Metadaten und keine Lizenzdurchsetzung. Sie sind für das interne Deployment über mehrere Orgs innerhalb eines Unternehmens gemacht, nicht für den Verkauf an Fremde auf AppExchange. Nutzen Sie sie nicht als Abkürzung, um kommerzielles Packaging zu umgehen.

Welches Packaging-Modell passt zur Phase Ihres ISV?

• Heute ein neues AppExchange-Produkt bauen: Nutzen Sie 2GP. Versionierung über die CLI, Ancestry Tracking für Upgrades und keine Abhängigkeit von einer anfälligen Packaging Org.
• Ein älteres 1GP-Produkt übernehmen oder pflegen: Bleiben Sie bei 1GP, bis ein durchdachter Migrationsplan steht. Namespace und Abonnentenbasis bleiben erhalten, aber die Umstellung hat echte technische Einschränkungen.
• Kostenlose, bearbeitbare Tools oder Templates verteilen: Unmanaged ist hier legitim, gerade weil Sie kein IP schützen und keine Upgrades berechnen.
• Deployments über die eigenen Orgs standardisieren: Unlocked Packages, keine für den Weiterverkauf gebauten Managed Packages.

Ein Fehler hier ist teuer zu korrigieren. Deshalb beginnt die Produktentwicklung von Tekunda mit AppExchange-Partnern genau mit dieser Entscheidung, noch bevor eine einzige Komponente gebaut wird, denn jede spätere Wahl bei Governance, Tests und Releases hängt von ihr ab.

FAQ

Kann ich später von Unmanaged zu Managed wechseln?

Nicht direkt. Sie bauen die Komponenten in einem Managed Package mit Namespace neu auf und führen eine echte Kundenmigration durch, weil die zugrunde liegenden Metadaten und IDs nicht sauber übernommen werden.

Kann ich ein 1GP-Package in 2GP umwandeln?

Ja, Salesforce unterstützt die Umwandlung von 1GP Managed Packages in 2GP unter Beibehaltung desselben Namespace und derselben Abonnenten-Orgs, allerdings erfordert das sorgfältige Planung rund um Package Ancestry und bestehende Installationen.

Brauche ich einen Namespace, wenn ich nicht auf AppExchange verkaufe?

Nur wenn Sie ein Managed oder Unlocked Package über mehrere Orgs verteilen. Ein einzelnes internes Deployment über Unmanaged-Metadaten oder Change Sets braucht keinen.

Ist 2GP für ein AppExchange-Listing erforderlich?

Nein, 1GP-Packages werden weiterhin unterstützt und gelistet, aber die Tooling-Investitionen von Salesforce liegen klar bei 2GP, und die meisten neuen ISV-Projekte sollten dort beginnen. Sprechen Sie mit Tekunda oder stöbern Sie im Blog, wenn Sie diese Entscheidung für ein kommendes Projekt abwägen.