And the concept of offering Cake as a service with the examples in the last point is just amazing. I am not sure I was able to wrap my head around it completely, but it definitely sounds ambitious.
I'm not even sure I have wrapped my head around that completely. ;) The more I think about it, though, the more sense it seems to make - so here's a more detailed explanation using one of the random examples from above just to give the idea:
A hypothetical gardening app allows users to plan their garden, for example by adding both existing and planned plants and trees to a list, which will then create a calendar or list of things to do in the next weeks ("prune trees this month", "buy and plant X now if you want them to bloom next year", ...). These to-do list items may come with short tutorials, but might leave open some questions: How do I best prune tree X? If I take a cutting of plant Y, do I grow it in water, in soil, or wait until next year?
These questions could be posed in some sort of forum where other app users can see them and reply - but building a whole system like that from scratch, just for a smallish special interest app, might easily become prohibitive. Enabling users to talk to each other is not a core feature of this app, so it probably won't ever be added - even though it might increase adoption (and avoid churn) to some degree.
Now, with an open API, the app developer could do the following:
1. On the screen for some plant X, display the top ten results of a Cake search for the name of the plant in Cake's "gardening" topic. For example, here's a discussion about roses: https://www.cake.co/conversations/Nfw8Tft/dealing-with-roses
Just displaying these results and opening them in a web browser is an easy thing to implement, so the app developer might want to offer this for free (as long as accessing Cake's APIs to do this is free for them).
2. Because keeping users in your app is better than leading them elsewhere, a logical next step would be to display the content of those conversations in-app as well. Getting all conversation data via API and displaying it in the app's own layout sounds like a reasonable thing to attempt as well. This would replace visits to Cake with API calls, though, so the Cake team would probably want to allow this only if it is beneficial to them (ads in conversations, ...).
3. The user went in there with a question of their own. Not all questions will be answered by already existing conversations, so the next idea is to allow the user to post as well. Add a "Question not answered?" button to the end of the conversation list, and allow users to pose a question themselves. In this case, the user would perhaps be offered to add 4 topics to their conversation, with the fifth one always being "gardening".
The app developer might want to offer this as a "pro" feature in a paid or ad-supported variant of their app, because properly integrating with Cake (authentication, display of available topics, proper formatting of posts, ...) sounds like something that needs a little more work - but is still easier to do than to create and maintain a forum system yourself.
The app developer would benefit from being able to outsource some of the workload that is not central to their own app - and from having access to people that might have answers but aren't using the app themselves. Meanwhile, Cake would benefit because this gets or keeps conversations going - and perhaps because users who already use Cake somewhere are more likely to discuss other things here as well.