This page is a short description of how we define our costs, for the purposes of guiding our pricing and budget writing activities.
Service costs¶
These are the most obvious costs that are tied directly to our Managed JupyterHub Service. We break them into these categories:
Cloud engineering and operations. Deploying, configuring, and operating the cloud infrastructure.
Cloud infrastructure support. Operating our support channels and responding to inquiries there, as well as responding to and resolving incidents.
Community guidance. Community guidance, documentation, and use case training for our hubs. This includes communications and guidance for community representatives.
Impact costs¶
Upstream costs: The extra cost we incur by doing our work with upstream communities as well as supporting those communities throughout our work.
Subsidizing communities with fewer resources: We often provide steep discounts in order to make our service more sustainable for communities that cannot afford to pay. To make up for this cost, we must increase our margin for wealthier communities and grant opportunities.
Sustainability costs¶
These are costs associated with making our service and operations more sustainable and future-proof.
Self-improvement costs. Investments into our infrastructure and systems, to create better and more reliable cloud services.
Financial buffer. Allows us to grow without financial strain, and allows us to withstand financial hardship.
Organizational leadership costs. The cost of our leadership and administrative teams to ensure that our organizational is functional and gets its work done.
Case study: Cost model of an engineer for the hub service¶
The following is a case study for how we used cost categories like the above to define our team’s cost of an engineer. It it likely out of date but shown here for illustrative purposes.
At present, we choose monthly hub fees based on assumptions about how many hubs an engineer can operate and support. We assume this is the primary bottleneck that limits our capacity. This gives us an “engineering cost per hub” and we use this as a base to estimate the extra fees we need to charge to cover the non-engineering roles that are needed for the service.
Cost of a 2i2c engineer. If we assume that a 2i2c engineer is paid
$140,000/year, with a30%benefits markup. This covers the design, development, and ongoing operation of cloud infrastructure for 2i2c’s hubs.Community support fees. We add a
10%markup to cover 2i2c’s extra costs in providing ongoing support and community guidance for our hubs. This includes communications and guidance for community representatives as well as support for hub issues.Open source support fees. We add a
10%markup to cover 2i2c’s extra costs in ongoing open source engagement and support. This includes upstreaming contributions to open source projects, community engagement and leadership, and collaboration and planning.Fiscal sponsor fees. We add a
15%markup to cover the fee of our fiscal sponsor, Code for Science and Society (for see Fiscal sponsorship and non-profit status for information about the services that CS&S provides).
The result is roughly $250,000 annually for each engineering position.
The fees for each hub are thus determined by dividing this annual cost by the estimated number of hubs of a given type that we can realistically support.