I think we're losing most potential contributors before they make their first contribution

Development
1

Continuing what I said here:

I think we’re losing people at pretty “easy” parts of the contributor acquisition funnel.

Awareness

Not much to do here for a free project. Having users who love your project and think it would meet other people’s needs would create organic marketing. Currently, I hardly ever bring up beets, and even more rarely do I recommend it, because it’s so complicated and niche.

Interest

This is where I think we lose a lot of people. Beets is focused on local music files, which are going extinct.

My pitch, very much welcome to criticism, is this:

“Beets can organize your music library easily and safely. When you want more advanced control, you can fine-tune it to your liking, including:”

(the list from https://beets.io/ )

Going along with getting more casual users to use beets, what’s the reward for them? There are some great bullet points on beets.io, but they are geeky (that’s the audience for beets after all!). Maybe it’s worth mentioning surface-level features?

  • Download cover art and lyrics
  • Import your local music files to Spotify playlists. (I took a quick look at doing this within Spotify, but there doesn’t seem to be an option?)
  • Visualize your music habits and get recommendations. (None of this functionality is in beets yet :stuck_out_tongue: )
  • (The rest of the existing list goes here.)

Consideration

This doesn’t quite work with a free product, but let’s call this the “on the fence” phase. A user is using beets but isn’t sure about importing their whole library to it. Beets has a bit of a learning curve on the UI/UX (and it’s command line based :O) but I don’t think this is why we don’t have contributors. Other cmd based tools seem to have contributors.

Purchase

Let’s pretend a user who imports all their library to beets has “bought” it.

But that’s about users of beets! What about contributors to code, docs, and tests? (I’m leaving out bug reports and graphics, because I don’t think there’s much overhead to submitting one.)

Theory: Most/all contributors to an open source project are users of it. That means a beets contributor has to go through all of the above, then face a new funnel:

Interest

This time, there has to be some feature or some bug fix a user can make that they want to do.

Discussion

They might or might not discuss it on our forums and get people’s ideas. If others support them, they might be more motivated. If there’s no interest, they may lose desire to continue. This is why I am so focused on creating a “community” within beets, to foster good will among users.

Consideration

Now, they try to implement it in the code. They look for what’s causing the problem or where they might add the feature. I think this is where we lose people too, because beets is hard to understand. I don’t think this is wrong or a problem, but I think we could ease people into beets better. “Good first issue” on github is a fantastic tag, and I’d like to help people along that journey into full contributors more. (And I’m still very much a novice. I now work in tech, but when I started, I didn’t, and everything was Greek to me.)

Pull request

This time, they submit a pull request.

Review

It is evaluated by maintainers and hopefully approved.

Repeat

Critically, the project cannot sustain itself if each contributor only contributes one time. We need repeat contributors to become intermediate/expert tier understanders of beets. These contributors repeatedly go through the code-change-funnel. Without high retention on this funnel, you eventually lose everyone.

TLDR: I think we’d have more beets contributors if we improved these areas:

  1. Interest: make “easy” changes to beets that make it useful to more people. As a longer term goal, make “hard” changes that differentiate it from Spotify and other streamers. The tagging and musicbrainz could be key. In many different domains, I see a dominant “convenient” player, but a strong minority that offers more control. Examples: Steam vs. emulators, Netflix vs. Blu-Rays, Twitter vs. Mastodon, Facebook/Twitter vs. Reddit, Discord vs. IRC. I don’t buy that “beets has almost no contributors because major players are just too convenient”.
  2. Make it easier to contribute to beets.
  3. As a distant third, make the community more welcoming, to make contributing more fun.
2

Thanks for the really interesting thoughts! I’m always enthused by these longer-term discussions of the project and its future phases.

To re-summarize the summary, I think there are 3 really interesting directions this discussion could go in:

  1. What ways could beets be more approachable to new (and more causal) users, without sacrificing the benefits it has for the “power user” crowd it has historically focused on? This could include reviving the idea of importer GUIs, etc.
  2. What would it take for beets to offer advantages over streaming (i.e., Spotify)? In this realm, the answer might be similar to other self-hosted streaming services, such as Navidrome (or the classics, like Ampache and Subsonic).
  3. What would make it easier to contribute to beets? (This is where I have the fewest ideas.)

Anyway, I think it would be fun to run in any of these directions and brainstorm cool ideas…

1 Like
3

hot take: Most people who were on the Internet in 1998-2013 has some MP3s on their computer. If 5-10% of those people have music that isn’t on streaming services, then beets has value. The ceiling on that 5-10% number is “what % of those people have so many files that it doesn’t make sense to manually fix the metadata?”.

Some attempt to document how to contribute:

With 55k lines of code as of 3 years ago, no wonder beets is so complicated:

4

While it will be nice to have more contributors, the bigger challenge in my mind is keeping folks engaged so that beets is not only used at the time of tagging. Integrating streaming services (such as Plex, Spotify, Apple Music) will keep the average user engaged and provide continuous value.

Thankfully, there seems to be some movement in that direction.

1 Like
5

There are some advantages. But it’s complex to set up and maintain. It will always be more complex than “pay someone $15/month and go to an app and play what you want,” unfortunately. But we could take steps to document and promote how to do something comparable with beets as a foundation, and why the effort of doing it might be worth it.

I wrote the beets-ibroadcast plugin because then you get all the benefits of beets, but also streamability from the cloud. You control your collection, but it is also available from all your devices without needing to host any server-side components (e.g. beets-web or Beetle).

Something that might help prospective new users would be a guide highlighting real-world use cases. We could also combine this with testimonials linking into those guides. My personal testimonial is:

  • I can manage all my music including great searchability and playlist building, which includes some obscure music not available from popular services like Spotify and Amazon Music (this is the beets part);
  • I can play any/all of it from any device (the iBroadcast + beets-ibroadcast part);
  • I can track my listening habits by scrobbling to ListenBrainz (via web-scrobbler browser plugin), and gain access to metrics from that.

I could make a “how-to” guide walking people through how to set up this scheme.

Furthermore, this model doesn’t require iBroadcast specifically, just some kind of upload-my-music-files-to-the-cloud or host-my-own-thing service. I have considered generalizing beets-ibroadcast into a beets-sync base plugin with extensions for specific services, but I don’t know of any/many other good+free cloud services someone might want to sync their collection to. Maybe YouTube Music, but only if there is demand…

Maybe… but pragmatically, the most appealing benefits are out of reach even with development effort. I can’t (easily) add any of my beets tracks to e.g. Amazon Music, and I can’t (legally) download tracks from such streaming services to add to my beets collection, and there is no player (that I know of) capable of tapping into both sources and exposing a seamless combined collection. I’m either in beets/iBroadcast world, or Amazon Music world, and they cannot be combined. Sure, we could write a plugin that matches beets tracks to their corresponding Amazon Music or Spotify track IDs, and syncs playlists between them, but all the tracks in question need to exist on the target streaming service.

I would caution against making a GUI-based importer as a first priority. It would be substantial additional code to maintain, and the interest will keep shrinking over time, because:

But beets does not have to be about only local music files. What if we separated concerns a bit more, such that the beets DB could include entries for tracks in people’s cloud libraries? Imagine sucking your Amazon Music library into beets, and being able to perform queries on it. Imagine being able to use plugins like beets-goingrunning to build playlists for any supported backend, whether it’s your local collection or Spotify or Amazon Music or whatever? There are many beets plugins that ultimately do not care about files at all, only what’s in the database. Generalizing beets in this direction would broaden the appeal, and we might start netting contributions from folks who don’t even collect music files, but only curate cloud collections. Another benefit would be that users could switch cloud services much more easily, because they could sync down a cloud library to beets, then sync it up to a different cloud service, and only lose the songs that aren’t present on the new cloud.

How about some long-term requirements gathering? What do we wish we could do with our music? And how could improvements to beets help achieve those wishes—in a FOSS way, and uniquely compared to all the commercial stuff like Plex? Here is my personal wish list:

  1. Ultimate import i.e. metadata enrichment. For every track and album, know its ID on every metadata platform (MusicBrainz, Discogs, etc.) and every streaming service (Spotify et al.). Pull down all available metadata from all of those platforms and services, and put it in my beets DB, so I can do the most useful things with music I care about!

  2. Ultimate export i.e. sharing. From my beets DB, which is the central authority for music I care about, be able to export local playlists, as well as cloud libraries + playlists. Maybe (legal challenges aside) even upload metadata to a shared FOSS cloud resource (MusicBrainz, ideally—or would we need a beets DB online?), so that we don’t all have to repeat this effort in parallel forever.

  3. (1) and (2), but for all media I care about—movies, TV shows, podcasts, etc.—not only music.

I think beets can become more successful over time if we take steps toward this vision.

2 Likes
6

no player (that I know of) capable of tapping into both sources and exposing a seamless combined collection.

I think this is part of the gimmick with the audiophile service Roon. What is Roon? : Everything You Need to Be Roon Ready | World Wide Stereo

the beets DB could include entries for tracks in people’s cloud libraries?

I wonder if there’s room for collab with listenbrainz or musicbrainz?

curate cloud collections

In audio communities, people make lists like “Rolling Stone top 500 albums”, “my favorite electronic of 2022”, “whimsicore essentials”. This could be really cool. Musicbrainz supports collections which may be similar.

or every track and album, know its ID on every metadata platform (MusicBrainz, Discogs, etc.) and every streaming service (Spotify et al.)

Musicbrainz has been trying to do this for ages, but it’s not clear if most users care. I think too much wheel-reinventing happens in music communities today.

(1) and (2), but for all media I care about—movies, TV shows, podcasts, etc.—not only music.

I’d have to see more of the pitch here. Podcasts maybe, but movies and TV have very little commonalities with the beets data model, typical consumption (repeat listen vs. less frequent rewatching), data formats, and consumption model (watch and delete? vs. keep forever).

My personal wishlist for expanding the beets appeal is taking the manual tagging and throwing it into the sun. The return on time investment is not there unless you are really particular about knowing whether you have the 1984 or 1992 master of The Wall. We should focus on matching release groups, not releases. The false matches happen more on popular tracks, which is what normal people are matching most of the time.

But beets does not have to be about only local music files.

This has been a small conflict for me over the last ~3 years - understanding where beets ends and other projects should come into play.

Back in 2017, I got into beets with simple goals:

  1. Make all my scrobbles of the same track (recording, in Musicbrainz terms) map back to one track. So make all my tags “musicbrainz grade”, i.e. no “feat.” in title, no “remaster” in release title.
  2. Make my playlist display (in Foobar2000 then and now, but this is not a requirement) show a uniform view. (Same as #1, everything should match.)
  3. Make my file folders and files uniform.
  4. Automate or semi-automate the import process so all new music conforms to 1-3.

Since 2017, my already large music collection has exploded. My new goals, which replace the old ones, are:

  1. Basic smart playlist creation. I want to tag my top 50 albums and always have those with me. I want playlists for my favorite genres so I don’t get stuck in feedback loops playing what I remember.
  2. Curate my library, slicing it in interesting ways. Basically, make playlists, but this can be more advanced than playlisting. This is something that streamers have started doing and have only gotten better at over time. The difference is there isn’t much of a “library” on the unlimited streamers (Spotify, Deezer etc.). I.e. there’s little difference between “a track you’ve heard” and “a track in the streamer’s library”. I don’t think an open source $0 project can compete with the machine learning people at the streamers, but I do think it can provide interesting (good) results by focusing more on the human angle (tags, ratings, user’s scrobble data). This ML vs. human curation debate comes up now and then, I’ve read a few non-technical articles on the topic.
  3. Have a way to play my library on my Android phone. I thought I would use convert for this, but the case for streaming + seamless local caching on the phone is getting better thanks to people on these forums.
  4. Have a way to use those curated slices on Android.
  5. automate the import process. luckily I’m much handier in python/automation than I was.

As for my original goals:

  1. Make all my scrobbles of the same track (recording, in Musicbrainz terms) map back to one track. I hope someday that ML will be good enough to do NER to fix my historical scrobbles. It’s too much of a pain and the time to fix vs. value to me isn’t worth it.
  2. Don’t care enough Make my playlist display (in Foobar2000 then and now, but this is not a requirement) show a uniform view. (Same as #1, everything should match.)
  3. Symlinks and playlists should replace the need to look at raw files Make my file folders and files uniform.

Aside: I see Musicbrainz got Google summer of code contributors.

As a Google Summer of Code’22 contributor, I worked for MetaBrainz, on the MusicBrainz Android app and added a music playback feature to the app, which we call BrainzPlayer.

Is SoC worth exploring for 23? Google Summer of Code - Wikipedia

Does anyone know anyone at MetaBrainz? I wonder what allows MetaBrainz/MusicBrainz to achieve a critical mass of people while beets doesn’t have many contributors. Or is this even true? the activity graphs look similar for the last month.

1 Like