I lead developer relations strategy at Fastly, and I’m currently working on figuring out a more structured way to look at our support for add-ons: libraries, frameworks and integrations that run on top of Fastly.
Examples include
observability tools like OpenTelemetry
application frameworks like Express.js, Next.JS, Nuxt or Remix,
programming languages (such as TypeScript) that transpile to languages we already support,
tools you use in your development process like VS Code plugins,
plugins that run within other platforms and help them integrate with Fastly, like Wordpress, Drupal and Magento.
modules that perform useful functions within an edge application, like ESI, image transformation, authentication or templating.
Some of these are things we make and maintain, some are third party stuff, but one thing all of these things share is they are not Fastly products and don’t form part of our primary service. Essentially, when you buy Fastly service, you are not buying support for these things. Yet, many people run services on Fastly precisely because these things work really well.
So I’m now looking at all the ways we can show support for these kinds of add-ons, and help customers succeed with them, as well as have the confidence to invest time and money in Fastly knowing that it will work out.
Here are the kinds of support that I’ve come up with so far:
Kept up to date by Fastly
Gets fixed if it breaks
Guarantee that support level won’t fall without formal process
Example usage provided in docs
Overview information provided in docs
Officially recognised within the ecosystem
Fastly customer support engineers trained to help with it
Public issue tracking for Fastly-maintained components
Compatible with all native Fastly features
Of course, the more of this support we commit to providing for every thing you might want to use with Fastly, the fewer things we can actually support. So my question is: for the addon/library/framework/plugin that you care about, what do you expect from us? What’s the minimum you would consider as ‘support’?
I love the idea of working towards a shared definition of support in how we integrate with ecosystem tech. This is such a tricky thing to negotiate with any developer tooling because the possibilities are endless and the tech you’re integrating with is essentially beyond your control!
Honestly keeping the stuff the team builds maintained and up to date is all I think I’d expect, and even then there can be very reasonable cases where you can’t justify the resources, perhaps if it’s a legacy integration and isn’t receiving much usage. Beyond that, clear communication about changes in support level are also great, at least then people know about changes they’ll need to respond to. So I think I’d see the first three items on the list as top priority…
Inclusion in learning resources and support is a huge bonus imo, mega helpful but not something I’d expect by default!
Am very curious to hear other takes on this… any comparisions with other dev products might help provide context too. What do you expect when you adopt a product, especially if you use it on the basis of an integration that lets you make best use of it…?
I would like so share some of my personal experience. In past, I used to work on geospatial web applications and many times that ecosystem feels like patchwork. Meaning, we relied heavily on tools without which creating our apps on that platform would have been near impossible. Similar to Fastly Labs some of the best tools were initially experimental built by a company (like Mapbox). Naturally, over the course of months and years some tools got community traction, and some didn’t.
To me support means looking for obvious indicators if a project is active and healthy - “Can I confidently say that this tool will be around long-enough for me use reliably?” All things that you’ve listed in the kinds of support absolutely provide that confidence.
Other signals that influence my decision include:
Frequency of updates and last update: There may be official docs, but if a library is stale I’ll think twice before considering to use it.
Maintainers on the project: Are majority of contributions made by single or multiple people?
Awareness of who is using it: Knowing that there are products/customers using the tool reassures that it will be actively maintained
Trainings and learning resources: 100% agree with Sue’s comment.
I definitely agree with the motivation here, but having been in the position of supporting things like this in prior roles (including things marked as “Labs”)… in the end these support statements are only a guide, and if a paying customer decides to adopt something that is marked as ‘minimum support’ and then has a problem with it, you’ll end up providing more than ‘minimum’ support
I’m Gustaf, principal engineer from Ingka Digital.
This is not an easy problem…
I think the biggest challenge is around governance and communication. Here I see two parameters:
A Tech Radar:y categorisation/visualisation, where you communicate for example Adopt/Trial/Assess/Hold
Supported/maintained by Fastly or Community
Things can change quite quickly in the technology space. It reminds me of this picture:
For example, things based on standards are much more safer bets than new web frameworks.
I would categorise the examples from Andrew like this:
Adopt
Open Telemetry (standard) – Fastly
ESI (standard proposal, existing Varnish capability) – Fastly
Authentication (based on OAuth, standard) – Fastly
Trial
TypeScript – Fastly
VS Code plugin – Fastly
Assess
Templating libraries – Community
Application frameworks – Community
Plugins – Community
Hold
…
Additional thoughts:
“Community” would involve both community contributors and Fastly contributors. Investment/involvement/contribution from Fastly is chosen depending on the value/effort/volatility/risk
Things in Trial could be ok to not have full support, but it needs to be stated what level of support is included and what’s not
Thanks for the feedback on this! As a starting point, I decided to narrow the scope a bit and focus on things that Fastly has released as open source projects on our GitHub. This obviously doesn’t encompass all add-ons, and notably excludes projects that we contribute to in other GitHub orgs or on other code hosting platforms, and any code written or managed by third parties. However, it does encompass a lot of projects that fit into the scope of what this topic is about.
After a major clean up exercise, we’re now down to a much more manageable number of public repos all of which are now of value to developers, and we set about categorising and tagging them. We then published a page where we index all of them together:
This has enabled me to develop a framework of tiers that can be used to guide expectations around the way Fastly interacts with the community for any particular project, which is at the bottom of the above page, but here’s a snapshot:
This gets us a bit of forward progress. Using this we can now have a way to talk about expectations in a concrete way, and can iterate on both the definitions of the tiers, and the rationale for including things in them.
One aspect we need to continue to work on is the extent to which we place something in a particular tier because of a strategic reason, rather than because that’s simply a reflection of the reality on the ground. For now, classifications that we’ve applied to our existing projects reflect reality, not strategy, and the next step is to figure out what the strategy should be and how far the reality is away from it
