I have loved using Spotify for many years and I greatly appreciate what S4D has provided me both as a developer and as a Spotify customer up until now, and it's one of the many reasons I enjoy and recommend Spotify constantly. So for me, today is a very sad day...
Just to echo much of what has already been said... I'm sorry to say, this is utterly heartbreaking news.
And, the fact that this thread exists indicates that some of you at Spotify agree! So please, speak up and help save S4D!
Please S4D team, you absolutely need to support individuals, not just companies! Even if you simply provide different quotas based on the 'type' of the partner (e.g. individual, start-up, SMC, enterprise etc.), a quota limit that grows with time / MAUs, or even go as far as requiring a code audit / code access pending a quota extension, honestly anything at all to avoid cutting out your most passionate developers who simply want to support your community and provide value to Spotify's customers!
250k MAU is an absurd threshold - even for established companies - to have to surpass to even begin thinking of integrating with Spotify. Have you even thought of start-ups? What about apps in active development that at their core are designed to rely on integration with Spotify? Potentially your most valuable demographic right there? These apps will never get off the ground without Spotify's support!
Please think about what type of partner is likely to bring the most innovation to the S4D platform and ultimately the most value to your customers... Is it going to be large, established products with their own red tape surrounding external integrations, who are likely less inclined to integrate with Spotify anyway (and even then as an afterthought) if they've already reached this threshold under their own effective business model, and even less likely to innovate and create novel ideas and experiences for your customers? Or is it likely to be the individuals and startups who are actively seeking to integrate / partner with you early on to deliver fresh content and new experiences to YOUR customers with a clear plan in mind?
I can already see a few huge categories of SDAs that will die with this update (and likely already make up far more than the "less than 1%" of developers this change was stated to impact). To name just one: apps developed to support one-off / annual music events and festivals.
For example, here's one fictitious scenario to consider to illustrate my point:
- Glastonbury Festival (the largest music festival in the UK, which is even televised nationwide) wants to use your Web API to show festival goers which performers they might like to go and see based on their Spotify top artists. A great use that demonstrates the power of S4D and Spotify's commitment to engage and provide value to their customers, right?
- In line with the S4D requirements, displayed content links back to Spotify, potentially generating many new sign-ups and subscription sales. It's unclear from the blog post what is considered "commercial viability". I don't think it should be important - what about non-profits?
- Glastonbury runs once a year and sells 200k tickets. Assume 90% of attendees use the app (making ~180k MAU for one month of the year and little to no traffic the rest of the year).
- Glastonbury applies ahead of their festival for extended quota access but are denied because their app doesn't meet MUA requirements ahead of the festival (or even after!).
- Result: Even the largest festival in the UK doesn't qualify for your new S4D requirements! Surely this isn't Spotify's aim?
To be clear, I do understand the reasoning behind the review of how some SDAs may have been implemented out-of-line with what's been expected of a SDA per the docs, but I think it's absurd to completely kill the S4D platform for small entities and passionate developers who might have a well thought out idea that could snowball into a prosperous partnership with Spotify in future and only wish to support Spotify and build something cool, even if their apps are well developed, robust, and 100% in line with the guidelines. Furthermore, many developers may not even have a goal of commercial viability (although it's unclear what exactly this means) so why on earth is there a requirement to turn a profit at all?!.
If conforming with "basic security, privacy, and licensing standards" is the primary concern, there are so many other ways to deal with this, like: reviewing SDAs thoroughly or requiring stricter integration only once they hit a threshold of connected customers, stricter or more thorough implementation requirements and reviews, providing open-source code examples for developers to use, clearer do's / dont's in the docs, more frequent SDA requirement reviews (e.g. re-apply yearly), template user agreements, 'verified' or 'unverified' SDA labelling in the OAuth flow with differing agreements based on the developer's relationship with Spotify... the list goes on. But blanket banning everyone but the largest for-profit companies will only harm the S4D community and stifle innovation on a platform with SO much potential. This seems like an incredibly drastic and restrictive change (equivalent to shooting yourself in the foot) in response to a completely different problem that exists altogether. On the other hand, if it is indeed Spotify's intention to only consider integrating such companies as part of the vaguely worded "evolving business needs" and "platform strategy" and (despite its huge size and great team working behind it) doesn't consider supporting smaller developers as "[investing] resources effectively", then this is a very sad day and there's not much we can do.
At the crux of it, I personally don't understand why SDAs can't be more thoroughly vetted only once they have received a nominal number of connected users (say 1,000 at a minimum). This happy medium would allow smaller individuals and companies to continue to develop and bring innovation to S4D whilst protecting Spotify (and the majority of their customers) from apps that don't 100% align with Spotifys developer guidelines / business goals. This way, the resources used (in terms of API requests made by apps, as well as manpower at Spotify to review apps) is minimised whilst still managing to support everyone! For example with this approach, developers can now create functional apps from scratch without hinderance for a small audience. If an app makes it to the nominal number of users (e.g 1,000) then there's a clear use case for it and it's worth pursuing further quota extension by working with Spotify to ensure their implementation is correct and aligns well with Spotify. By this point in the SDA development lifecycle, the developers will be well-informed of the docs, SDA terms etc. (and may already be moving to make a profit) and so liaison with these individuals will be far more efficient than say a company who already meets requirements but are just starting out on the S4D platform. Spotify's workload is greatly reduced by only needing to thoroughly vet apps that reach this threshold and can prioritise time spent reviewing these in further depth. Spotify can continue to occasionally vet smaller apps nearing the threshold prioritising larger apps etc. to maximise protecting customers from any SDA that doesn't 100% align with the guidelines etc. Please consider this approach!
Lastly, I must say all the innovative and useful SDAs I've ever used have been published by individuals (at least initially before their growth). With this update, you're clipping the wings of potential partners before they've even got off the ground!
In short, the update to your requirements introduces a nonsensical amount of red tape, which instead of affecting "less than 1%" of developers will in fact affect the other 99% of developers, stopping them dead in their tracks and looking to turn to another platform, and will absolutely kill the S4D community. It's so sad to see that this has happened! And I hope some time in the near future you will reflect on these requirements and revive your developer community.
Thanks so much to the staff at Spotify who have given us the opportunity to talk about this change! @ThePodfather
