This will also be easier when we have user interactions implemented. If you follow your friend Alice, and alice share a track (regardless of its licence/copyright), your instance would know about it!
I’m sorry I did not get back to you. I did not schedule this on the roadmap because both 0.18 and 0.19 were pretty loaded already. We could possibly split the feature in two:
- Handle external links for tracks/albums (by editing metadata manually or by leveraging databases like MusicBrainz when we can), and feature those links in the UI
- Work on the external players embedding
Working on 1. brings value, and is needed for 2. anyway. It may also overlap with Designing Artist profiles which would be a good thing! (less work ;)).
I cannot commit on a date for the implementation, but this post should give you more context about what’s going on
(I completely get what you mean, but I believed Discourse offer was unified and completely free? https://payments.discourse.org/pricing refers to the hosted version, not the sotfware itself unless I’m wrong).
I’m not sure if
paid features refer to the open-core model (like Gitlab, where one flavour of the software is free, and another one, with more feature, is paid) or to sponspored features.
To be frank, I’m very reluctant to split Funkwhale in two flavours (one paid, and one free), for two reasons.
The first one is a technical reason: maintaining a paid flavour of the software would add a lot of overhead, in many place. Roadmap, documentation, support, development, UI… All of these places (and other I’m forgetting) would need to handle the distinction between paid and free flavour, leading to duplication. It’s a lot of work.
The second one, which is the most important IMHO, is an ethical and political one: I want the work being done here to benefit to everyone. Having paying customers for the software would mean that some of the work would remained closed. This also raises concerns in terms of governance, because we would have to constantly arbiter between the needs of paying customers and non-paying users. Finally, it would mean your experience of the platform would depend on your financial resources. It makes me uncomfortable.
That doesn’t mean I don’t want the project to have the financial resources to grow and prosper though! On the contrary, I want that very much, as long as it’s not at the cost of the well-being of the community.
What is your opinion on sponsored features (someone pay for the implementation of a feature that can benefit to everyone)? Another popular option is to offer some paying hosting of the softare, so people pay for the service and not the software.