From 59d3d8f92bf44cf4386aea6e7e9423e20126e62f Mon Sep 17 00:00:00 2001
From: AbstractionFactory
 <179820029+abstractionfactory@users.noreply.github.com>
Date: Fri, 7 Feb 2025 15:04:55 +0100
Subject: [PATCH] Added potential alternatives

Signed-off-by: AbstractionFactory <179820029+abstractionfactory@users.noreply.github.com>
---
 rfc/20241206-oci-registries.md | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/rfc/20241206-oci-registries.md b/rfc/20241206-oci-registries.md
index 99586b2bc1..7579455deb 100644
--- a/rfc/20241206-oci-registries.md
+++ b/rfc/20241206-oci-registries.md
@@ -41,3 +41,13 @@ The following additional sections discuss potential implementation details of th
 9. [Authentication-related implementation details](20241206-oci-registries/9-auth-implementation-details.md)
 10. [Provider installation implementation details](20241206-oci-registries/10-provider-implementation-details.md)
 11. [Module installation implementation details](20241206-oci-registries/11-module-implementation-details.md)
+
+## Potential alternatives
+
+OCI resolves a very real pain-point for enterprise users wanting to run a private registry. A potential alternative would be, of course, making the use of a private registry easier, or creating a tool that can maintain a private registry purely based on static files. On that note, we could also implement running the OpenTofu Registry on the same dataset privately, which has been [documented in this issue](https://github.com/opentofu/registry/issues/1518).
+
+These solutions would also work towards the goal of making the ecosystem fully decentralized.
+
+That being said, neither of these solutions are as convenient as OCI since the infrastructure for this protocol is ubiquitous and cheap. 
+
+## Future plans
\ No newline at end of file