diff --git a/docs/admin.md b/docs/admin.md
index 4a7ea2b4d..a52b8df1e 100644
--- a/docs/admin.md
+++ b/docs/admin.md
@@ -8,11 +8,11 @@ __GCP__: On GCE/GKE, the Ingress controller runs on the
 master. If you wish to stop this controller and run another instance on your
 nodes instead, you can do so by following this [example](/examples/deployment/gce).
 
-__OSS__: You can deploy an OSS Ingress controller by simply
+__generic__: You can deploy a genric (nginx or haproxy) Ingress controller by simply
 running it as a pod in your cluster, as shown in the [examples](/examples/deployment).
 Please note that you must specify the `ingress.class`
 [annotation](/examples/PREREQUISITES.md#ingress-class) if you're running on a
-cloudprovider, or the cloudprovider controller will fight the OSS controller
+cloudprovider, or the cloudprovider controller will fight the nginx controller
 for the Ingress.
 
 __AWS__: Until we have an AWS ALB Ingress controller, you can deploy the nginx
@@ -20,10 +20,10 @@ Ingress controller behind an ELB on AWS, as shows in the [next section](#stacked
 
 ## Stacked deployments
 
-__Behind a LoadBalancer Service__: You can deploy an OSS controller behind a
+__Behind a LoadBalancer Service__: You can deploy an generic controller behind a
 Service of `Type=LoadBalancer`, by following this [example](/examples/static-ip/nginx#acquiring-an-ip).
-More specifically, first create a LoadBalancer Service that selects the OSS
-controller pods, then start the OSS controller with the `--publish-service`
+More specifically, first create a LoadBalancer Service that selects the generic
+controller pods, then start the generic controller with the `--publish-service`
 flag.
 
 
@@ -37,8 +37,8 @@ TODO: Write an example
 
 ## Daemonset
 
-Neither a single pod or bank of OSS controllers scales with the cluster size.
-If you create a daemonset of OSS Ingress controllers, every new node
+Neither a single pod or bank of generic controllers scales with the cluster size.
+If you create a daemonset of generic Ingress controllers, every new node
 automatically gets an instance of the controller listening on the specified
 ports.
 
@@ -46,7 +46,7 @@ TODO: Write an example
 
 ## Intra-cluster Ingress
 
-Since OSS Ingress controllers run in pods, you can deploy them as intra-cluster
+Since generic Ingress controllers run in pods, you can deploy them as intra-cluster
 proxies by just not exposing them on a `hostPort` and putting them behind a
 Service of `Type=ClusterIP`.
 
diff --git a/examples/PREREQUISITES.md b/examples/PREREQUISITES.md
index 5881f9045..a2c12ad2a 100644
--- a/examples/PREREQUISITES.md
+++ b/examples/PREREQUISITES.md
@@ -10,12 +10,12 @@ Unless you're running on a cloudprovider that supports Ingress out of the box
 
 ## Firewall rules
 
-If you're using a bare-metal controller (eg the nginx ingress controller), you
+If you're using a generic controller (eg the nginx ingress controller), you
 will need to create a firewall rule that targets port 80/443 on the specific VMs
 the nginx controller is running on. On cloudproviders, the respective backend
 will auto-create firewall rules for your Ingress.
 
-If you'd like to auto-create firewall rules for an OSS Ingress controller,
+If you'd like to auto-create firewall rules for an Ingress controller,
 you can put it behind a Service of `Type=Loadbalancer` as shown in
 [this example](/examples/static-ip/nginx#acquiring-an-ip).