---
tags: managed-hub-service
---

# This document has been moved to [this google doc](https://docs.google.com/document/d/1R3ovKIcHCpE7A77ovrXntRc2XkmK8nnZgVhUMWDT4vQ/edit?usp=sharing) to facilitate feedback from others.

Below are a few sections that are more 2i2c-facing and weren't included in the public feedback document.

### Observations and background on the tiers and pricing

> These are some more free-form notes and ideas that we've collected along the way.

1. Chris and Jim, with important inputs from the 2i2c team, CS&S and other sources, collaborated to develop these tiers and pricing.
2. 2i2c aims to sustainably offer hubs-as-a-service and advance on our mission. We are currently serving some organizations that wish to pay us and we have prospective customers who wish to understand the costs of 2i2c service.
3. The design space for the various offerings we can imagine is huge. The alpha strives to define three hub flavors (and a bespoke service tier) that address common scenarios. The complexity of operating hubs on infrastructure owned by the customer is priced with a 50% markup charge.
4. This is an <span style="color:red">alpha</span> offering and can be changed later. We wish for the alpha to confirm two hypotheses:
+ _product-market fit_: These kinds of hubs can be sold at these prices to education and research customers.
+ _sustainability_: Revenue from the sale of these hubs covers 2i2c's costs.
5. The alpha may reveal additional costs (e.g. sales, revenue collection, admin, development). Engineering advances might allow 2i2c to become more efficient and effectively operate more hubs-per-engineer.
6. We need instrumentation to handle cloud billing for hubs operated by 2i2c. This might be challenging. Can we use Prometheus or other tools to quantify `monthly-average-number-of-simutaneous-users` for THIS_HUB on THAT_CLUSTER? If we can do that, it seems we should be able to prorate the cluster costs across the various hubs while sharing data that transparently explains the cloud costs to each customer.
7. Observations on the 50% markup changed when service is operated on customer-owned infrastructure:
+ What's the ideal end-state for 2i2c and the communities we serve? Customers can more easily leave 2i2c when they own their infrastructure. Should the option to easily leave, that is to easily exercise the right to replicate, be priced? Are there financial instruments to price this?
+ The cloud vendor(s) are a disengaged third party in these transactions. What do the cloud vendors aim to achieve by giving credits? Can the cloud vendors reduce or minimize the added complexity arising with customer-owned-infrastructure?
+ Does 2i2c's cost to operate customer-owned-infrastructure differ across cloud vendors? Charging differently across vendors may create incentives for the cloud vendors to improve and reduce complexity for 2i2c.
+ Will cloud vendors provide credits to 2i2c for SOME_COLLEGE to receive 2i2c service for a term-limited pilot? Will cloud vendors activate their sales teams to sell 2i2c service and their cloud services? 2i2c can grow fast if we can establish sales partnership agreements with AWS, Google and Microsoft to sell our services to research and education customers.