A quick intro for those who don’t know me. Hi! I’m Jeremy. I’ve been in the tech industry for almost 20 years as a developer, company founder, and now consultant. Originally I’m from Seattle, but have been in Berlin for the past 3 years. I’m also a huge music nerd and have been deep in the electronic music community since 1998.
Melissa brought me into the Resonate circle about 8 months ago. For the past couple of those, I’ve been working to understand and improve how Resonate does product development and how we can get to a fully functioning DSP.
Over the past few weeks, I’ve put together a handful of recommendations that I think could help Resonate be more focused, effective, and better at activating volunteers to help build the product. These recommendations are laid out in the document below in the form of proposals that the coop can consider and adopt as it sees fit. The document is public and it accepts comments so feedback is very welcome!
I do have some thoughts about the refactor, but it’s probably worth discussing them in a call (which I think is the plan for next Wednesday).
My main concern is that I’m not sure the “migration off of wordpress mysql” will be that simple. I’ve been poking around the tracks-api, dashboard/api, and user-api and it looks like there’s still a lot of dependence on the mysql tables (specifically the wordpress user and user_meta tables) in there. I also have concerns about maintaining two API platforms (id & user-api) in a language that no one currently on the dev team is super comfortable with.
Outside of that, I think switching the data to the postgres should be fairly easy.
Cross-pollinating this post here, as it discusses this proposal heavily (along with underscoring its importance as a means of unblocking the mobile and desktop apps):
I agree with so many of the proposals, but one which stands out to me is renaming our development efforts as “product” efforts. While coding is essential, development should be viewed here as not limited to code – and the term product brings valuable focus as well. The co-op will benefit much from bringing more folks and skillsets together as a Product Team; excited for that.
thanks for pulling this together and sharing @Jeremy !
for further context, these recommendations have been requested by the @directors and i and this document is something that we’ve needed for a long time. i believe tackling these questions as a community would bode well for us as develop our a roadmap towards a fully functioning DSP.
i completely encourage others to join the conversation because these discussions are crucial in us determining the direction of our platform and cooperative.
@maintainers@brndnkng In this spirit of Proposal #7 – to rename “Platform Team” to “Product Team”, how do y’all feel about the Platform category of the forum being renamed Product? Seems clearer, especially since we now have a Product Backlog.
It’s a small thing, but could be psychologically important. “Platform Team” implies that the product is one supporting part of the overall ecosystem to be balanced with other parts. Resonate is currently a product company without a product. The product needs to be the top priority above all else until there’s a credible MVP. Renaming the team along with some of the previous proposals should help narrow the focus.
I went through your recommendations again. Many thanks for this.
I don’t disagree with short/medium terms recommendations but I don’t really see why we need to phase out user api and id server.
It seems widely believed that golang was chosen because we just had more funds at the time. That’s really weird way to think. It was purely practical choice. Choosing react/node seems purely ideological imho. Is that better? Auth0 was suggested in 2018 to get away from wp auth system but instead we just setup our own oauth2 server for more flexibility. No need to ask members to change their password or to use yet another wp plugin. The only issue was how fast we were able to sync wp user base and the oauth2 server db. This situation latest a long time. Far too long.
The new website took years of polishing and content changes when everything else was being built and at some point waiting for it.
Now it seems we want to go backwards, ditching systems which have reached operational status. I don’t feel like we can afford that.
I have been using choo believing it to be more approachable than react. Now, I get that we cannot scale with this this anymore. The tooling, browserify based… is just out of date.
I feel like react/node is a almost a solution to a nonproblem. There’s no need to build a new react based player when we already have beam. It’s time to spread the word about it.
We can focus on the backend. The catalog API is a good idea, as an evolution of the tracks api. It can easily share a database with the user api. We can use react to replace the dashboard for artists. The id server is mostly forms and there’s more forms to add. Let’s find the best solution for forms. My intuition is web components. Thoughts on this?
Can we agree what kind of player we want? Is stream2own a bad idea, should we go full subscription based? Where can we discuss that? Or did I miss something…
I’m not going to fight against everyone tech choices. I’ll leave to you all to decide as I’m not going to participate in the future developments. I hope this message added some more context to the why/how at Resonate.
