diff --git a/doc/forum/Alternative_modes_for_annex_repos.mdwn b/doc/forum/Alternative_modes_for_annex_repos.mdwn
new file mode 100644
index 0000000000..6d707d3b14
--- /dev/null
+++ b/doc/forum/Alternative_modes_for_annex_repos.mdwn
@@ -0,0 +1,35 @@
+I have given a lot of thought and experimentation to how git-annex could be used for large projects where there is a desire to distribute files to many users, but where only a minority of users would would actually push key changes.
+
+The first option would be to have an annexless mode, where a local repo either has no uuid, or where the git-annex branch is not stored in the default namespace.
+
+This is for cases where the client only cares that a file exists in the repo and that it has been verified.
+
+One possibility could be `git-annex-get --no-init`, which would not init a local repo, but would get and verify a file. The existence of a file would simply be if the file exists. Only upon making a change can a could be fully inited.
+
+Or even better, in a restricted environment where git-annex is not available, this case is simple enough that getting a key from a url could be done with a shellscript. The url could be extracted from the upstream git-annex branch without checking it out, and the symlinks used for verification. However, there is a chance that the upstream git-annex branch may not be stable (like if it is not propagated after a mirror), so one could "shrinkwrap" keys and store their remote url locations in a .gitattributes file or somewhere else in the same branch. If key changes are desired, it can be fairly effortlessly upgraded to an actual git-annex repo.
+
+A step up from a completely annexless repo would be a hypothetical local-only git-annex repo, where git-annex only uses a git-annex branch locally.
+
+There could be a `git-annex-init --local` option which creates a `local/git-annex` branch, for local tracking, but would not sync to the server by default.
+
+In this mode, the upstream git-annex branch would just be pulled and kept read-only, and `local/git-annex` would keep local differences. The `local/git-annex` would just use the union driver to combine upstream changes with local changes. Upgrading to a full git-annex repo would be as easy as creating a new `git-annex` branch at the same commit id as `local/git-annex`
+
+
+So, in summary, I have considered two modes:
+
+Fully annex-less mode, which is simple enough to be implemented completely without git-annex, useful for restricted environments. Optionally, can use a kind of shinkwrapping to externalize key URLs to a file in the branch to guarantee that the fetch location is stored.
+
+Secondly is local mode, where a `local/git-annex` branch is downstream from a git-annex branch, and in order to sync changes back to the server, the repo is upgraded.
+
+Both of these modes could easily be upgraded to a full git-annex repo on demand.
+
+I think this is useful when considering large scale usage.
+
+
+Most of this functionality is something that is probably best suited for a wrapper.
+
+In terms of any any potential core changes to git-annex, it may be as simple as having a GIT_ANNEX_BRANCH environment variable, analogous to the GIT_DIR variable for git.
+
+Has anyone given any thought to scenarios like this?
+
+I think there are cases where developers use git-lfs and something like this might be a better fit. And also with making git-annex repos more generally available and portable.