@marrus_sh@mastodon.social / @u2764@icosahedron.website
It will always be the case that larger instances will have more advertising power for drawing in new users than smaller instances. Furthermore, larger instances will, in general, have better administration, a larger community, and newer features than smaller instances. This makes big instances an appealing target for new users.
I don't see this as a flaw, I see it as a requirement.
Right now the ease at which one can find new users to follow is largely dependent on how large one's instance is:
It is far easier to find new people to follow on mastodon.social than icosahedron.website, for example.
So long as there are multiple competing large instances (aka no one instance has a monopoly, as is the case currently), the downsides of large instances are manageable, and they serve to familiarize users with the ecosystem and (I think, ideally) funnel them into smaller, more community-focused instances later.
This model will be the premise from which I will be making future points, so let's set up some terminology: I'll call large instances core instances and small instances community instances; there are, of course, also single-user instances in addition to these.
In order for this model to work successfully, however, it is important that switching instances be a fairly seamless operation. Being able to import / export old toots is not a requirement (although I think being able to download a database of your toots is important for other reasons); however, the following features are important:
- Being able to import/export follower lists, block lists, mute lists
- Being able to canonically declare that an account has changed location
One of the strengths of federation, and a notable way to get people using the Mastodon software, is the ability to create specialized instances with a targeted community. Some examples of this include:
- Instances dedicated to certain artforms, hobbies, or skills
- Instances dedicated to particular fandoms
- Instances used for educational purposes, or in a classroom environment
- Instances used by businesses for professional reasons
Specialized instances have a very different purpose from a more general-use instance, and are a point where the email metaphor breaks down: You would never choose your email server for its community. Consequently, they have some particular needs.
Here are some things I see as requirements for proper specialized instance support:
-
The per-instance ability to turn off the local timeline, the global timeline, or both. A global timeline makes considerably less sense when on a specialized instance dedicated to a specific topic. Conversely, for extremely general-use instances, instance owners might want to disable a local timeline to promote federation and prevent cliquey behaviour.
-
The ability to disable federation altogether, or easily enable federation only to a whitelisted list of servers. The need for this should be obvious when you consider using Mastodon in a K-12 educational setting. Roleplay or support-group servers may also find this feature valuable.
-
The ability to communicate instance culture to clients. Some things this might include:
- The title of the instance
- An instance logo
- Instance colours (there would need to be a standard regarding this)
- Localization settings (to allow specialized terminology for posts, boosts, and so forth)
- Custom links to about pages, blogs, terms, et cetera
- Given (1) and (2) above, what kinds of federation are supported
Of course, communicating these things between instances might be useful as well.
-
The ability to extend Mastodon with plugins. Mastodon will never be able to handle every specialized instance's needs. Some instances might, for example, want integration with SoundCloud, YouTube, or other platforms that would be beyond the scope of Mastodon proper. There should be a (documented, accessible) means of extending Mastodon built into the main server engine, both with respect to the frontend and the backend (especially, imo, regarding the User Settings page).
The idea of having a revenue stream and profitability is an uncomfortable one for a fair number of folks in the FOSS crowd, but it is also a necessity given the fact that (a) the labour costs of the Mastodon project, if done well, are fairly high, and (b) that labour needs to be compensated in some manner. (Also (c), if Mastodon is to compete with large financial entities, attempting to do so without a revenue stream is folly.)
Here are some specific things that the Mastodon ecosystem needs a revenue stream to address:
-
Mastodon needs a legal team. For the following reasons: (a) to provide legal advice and education to instance owners and administrators; (b) to take the burden of writing ToSes and possibly CoCs off of instance owners; (c) to deal with legal challenges from larger, corporate entities (Facebook, Twitter, etc).
-
Mastodon needs a PR staff. Word-of-mouth communication and grassroots organization works fine for now, but eventually schisms will happen and (if successful) large, corporate organizations with large PR departments will begin actively campaigning against us. We need to be able to formulate a response.
-
Mastodon should provide training to instance owners. If Mastodon wants to make owning and running an instance something anyone can do, then it needs to provide owners with training about community management, sensitivity, and moderation.
-
Core Mastodon instances need a dedicated moderation team. For community instances, volunteer community moderation works fine. However, once the user count reaches a certain threshold, having a dedicated support staff to deal with moderation (and Support) becomes a must.
-
Mastodon needs fulltime devs. You could argue that, as a FOSS project, Mastodon doesn't need fulltime devs, but let's all agree that it would be nice and leave it at that.
Obviously, if you have a revenue stream, you will also eventually need a nonprofit Foundation, a governance model, good administration, et cetera, but for now let's just focus on where that money is coming from and how to get it. Mastodon is free software, which means that the primary site for monetization lies not with the software itself, but with individual instances. It is, for obvious reasons, to instances' benefit to donate to help fund the above ventures. Of course, this means that instances themselves must have ways of attaining a revenue stream.
The question of whether instances themselves should be non-profit or for-profit is to me a moot question, as for-profit instances are inevitable if the software is successful. If we want that money coming back to us (the FOSS project) instead of for-profit entities creating their own implementations and keeping the money for themselves (less ideal) then we will have to accommodate a revenue stream model into the Mastodon software eventually. Another advantage to doing this ourselves is that we then hold sway over which kinds of revenue aqcuisition are acceptible and which kinds are not.
Here are some thoughts on how Mastodon instances might attain a revenue stream, and furthermore how the Mastodon software might accommodate (or not accommodate) them.
- Donations. Donations (and volunteer work) will likely be the primary source of revenue for community instances, but will likely become insufficient for core instances as they have to deal with larger moderation and administrative problems.
- Aesthetic changes. This includes paid themes, customization options, et cetera. Of course, this probably requires allowing instances to support multiple frontends before any progress can be made on this option. Users should never have to pay for accessibility, so charging money for (for example) a high-contrast theme would be inappropriate.
- Account badging. “Supporter” badges and the like are one means of encouraging users to give money to the project. Giving supporters additional features over everyday users would be inappropriate, however. (Note that account badging need not necessarily be tied to monitization, and being able to badge accounts might be seen as a useful feature for other, completely benign purposes.)
- Grants and organizations. Believe it or not there are a lot of people who don't much like Twitter, and some of those people undoubtedly have money and are in charge of foundations and might be willing to donate to help take it down. For-profit organizations who use the Mastodon software for their own purposes furthermore might be willing to fund its continued development.
With all of the above, there is of course the fear that instance staff will preference donating members (or organizations) over everyday users when making moderation decisions; ie that moderators or developers can be “bought off”. This is a problem of capitalism. Unfortunately, the Mastodon project exists in a world beset by capitalism.
The Mastodon software should probably have a terms of use / license that clearly specifies what forms of monitization are or aren't acceptable. This, contradictorily, requires having a legal team (both to create the license and to enforce it) and thus, a revenue stream.