Give each plugin or asset pack one named owner, usually the person on the team that uses it most, and give engineering a shared review rule. Without an owner, nobody notices a vendor update or an advisory. Studios add components from several disciplines, so ownership must be explicit.
Why this goes wrong in studios
Plugins and packs arrive through different doors. A programmer adds a package to the manifest. A tech artist installs an editor plugin. A designer drops in a sample project. A producer buys a pack. Epic's documentation shows that plugins can be installed in the engine folder or the project folder, so a plugin might not even be visible in the repository. See engine or project level.
A decision guide
| Component type | Likely owner | Review by |
|---|---|---|
| Engine packages | Lead programmer | Another programmer |
| Code plugins with source | Programmer who integrated it | Lead programmer |
| Editor plugins and addons | Tech artist or tools programmer | Programmer, for editor scripts |
| Art and audio packs | Art or audio lead | Producer, for license questions |
| Native libraries | Platform programmer | Lead programmer |
| Web template scripts | Web or marketing engineer | Security contact |
| Console SDK and port code | Platform lead | Studio head, per agreements |
Rules that make ownership real
- Every entry in the inventory has one owner. Shared owners are no owners.
- New components need a pull request that adds the inventory row.
- The owner checks release notes on a fixed schedule, such as monthly.
- When an advisory hits, the owner answers within a day whether the studio is affected. Reachability analysis helps decide whether vulnerable code is actually called.
- Owners leaving the studio hand over components in writing.
What the review rule looks at
For editor code, review for scripts that run on load. Unity documents an attribute that runs static constructors when a project loads, and Godot's documentation warns that tool scripts have no protection against misuse. For native libraries, ask the vendor for a component list. See native plug-ins.
Keep it light
A spreadsheet is enough. A monthly fifteen minute check where owners confirm versions and flag stale vendors catches most problems. If a plugin is dormant, apply the vendor gone quiet plan.
Making the rules stick
Ownership works when it is visible. Put the owner column in the inventory and review it at the monthly check. When someone adds a component without an owner, the pull request reviewer asks for one before approving. It takes thirty seconds and prevents most orphaned components.
For small studios where one person does everything, the same table still helps. It shows which hats the person wears and which components would be orphaned if they left. That alone is worth the effort.
Escalation
When an owner and a lead disagree on whether to update a component, use a simple tiebreaker: the risk to shipped players decides. A known flaw that is reachable in a live game outranks a feature freeze. Write that rule down in advance so the argument is short.
Onboarding new hires
Give every new hire the inventory on day one and name the components they will own within their first month. It teaches the stack and spreads the load.
Quick check
Can two people co-own a component?
It is better to name one owner and one backup. Shared ownership usually means nobody checks.
What if the owner leaves?
Hand over in writing and reassign the entry before the last day.
Sources
- Plugins in Unreal Engine, Epic documentation
- InitializeOnLoadAttribute, Unity 6.0 Scripting API
- Running code in the editor, Godot documentation
Last reviewed: 19 October 2026.
