Revenue and paid features
Aug. 16th, 2019 10:55 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
powerful_dusk_88623 posting in ![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}
keppariAlthough Keppari will be incorporated as a US non-profit, the main revenue stream will not be from donations. For long-term stability and accountability to users, payments for paid accounts and paid features will be the main income source. Based on the cost of similar services with premium account tiers, I'm tentatively thinking $3-4/month or $36/year, with a discount for paying for a full year at once. I still need to find an attorney with non-profit experience, but I believe fees for paid accounts and features would not be tax deductible the way a donation would be, since it would be a fee for service similar to purchasing a physical good. This would also probably mean paying sales tax.
For comparison, here are the costs for paid accounts with similar services:
Dreamwidth paid account: $35/year
Dreamwidth premium: $50/year
Reddit premium: $72/year
Reddit gold (prior to 2017?): $30/year
Wordpress.com personal: $60/year
Pillowfort paid account: will update if they announce
Based on conversations with DW's denise, payments will initially be handled through a combination of PayPal, Stripe, and other mainstream payment processors until the organization can build a chargeback history to negotiate with another payment processor who will be more stable. Using PayPal, Stripe, etc runs the risk of being cut off for hosting adult content, but denise advised that cycling payments through different processors and making the payment system processor agnostic will make this a bit less likely. Pillowfort used PayPal from early 2016 through early 2019 before changing processors.
I'm also looking at funding through Patreon, which seems to allow funding for this kind of model and shouldn't have problems with the content, since the Patreon donations would be for the development of the site, not for accessing adult content. Automating Patreon donation integration with the site would require building a hook to their API, which uses a different authorization system than what Keppari currently uses. (Patreon uses OAuth, Keppari uses Devise). This shouldn't be too much of a problem, but would require building.
Issues with curated ad hosting
Discussion on FFA
I've given some thought to an internal ad system like Ravelry's, with ads focused on the userbase, but there's two issues with that. One is that it would require a lot of screening and management, and the other is that the attorney I've spoken with said it could run into both copyright issues and FOSTA/SESTA issues depending on what's advertised. If the ads are screened in-house it could open up liability issues if an ad went up that shouldn't have, and it would take a lot of specialized screening labor regardless.
It's not so much NSFW ads as ads that advertise something a rightsholder might come after. Like say someone runs an ad for their Redbubble site and uses an image of their fanart for the public domain Alice and Wonderland. If Disney comes after that, like they've come after artists who've sold prints for fanart of the original Alice in Wonderland, that would put the platform that served the ad in the middle and possibly open the platform to liability for having made money off of an ad for what Disney argues is copyright infringing content. Or if there's an ad for someone's Patreon where they post cosplay nudes, that could get into FOSTA/SESTA liability territory for advertising content that profits off what might be classed as sex trafficking and exploitation depending on whose attention it comes to. Those are the kinds of gray area ads that would take a judgement call and would still possibly cause trouble.
I am keeping this on the backburner, and any internal ads would have to be 1) shown to guest and free users only, 2) not displayed alongside NSFW content and 3) not animated or using tracking cookies or javascript. I'm going to reach out to Ryan North of the now-defunct Project Wonderful and the Ravelry advertising contact to ask for advice. (See Ravelry's advertising guidelines here)
Issues with a site marketplace
Discussion on FFA
Regarding a system like Deviantart's, where users can sell prints and other items and the site takes a cut, it would take a lot of infrastructure to contract with a print on demand firm and deal with disputed charges and all that. I'm just not sure if the potential revenue is worth it if it means either depending on lots of specialized volunteer labor or eventually hiring an employee.
Regarding a system like Etsy's, where users can list and advertise merchandise without the site being responsible for production, I'm very hesitant about it for a lot of reasons, the copyright one being the biggest. Putting aside the physical object problem for a service like redbubble or society6, somewhere like etsy needs a way to handle seller-buyer disputes, chargebacks for returned merch, etc. Even if the merch were purely digital, like setting up a service to facilitate digital commissions, I can imagine it being a headache if the site had to get involved when someone didn't deliver commissions, stopped communicating, or if the buyer was unsatisfied with the final commission. It seems like more headache than the potential return is worth.
A preliminary list of possible paid features and pricing
All prices below are hypotheticals I'm using to estimate and are in no way final. The features below are ones that are non-essential, create additional server load, and/or require extra storage space.
Easy and cheap, probably around $1 each / year
A tag viewer
Similar to xkit's tag viewer, see all tags a reblogged post has been tagged with. Either display in a popup modal like xkit or in a separate list like reblogs and likes currently. Might have a tag-cloud setup to avoid scrolling through lots of repeated tags, with an option to click and see users who reblogged with that tag. Might give paid users the option of allowing other users to see the tags on the paid user's posts
CSS customization
For accessibility reasons, free users should be able to do a limited amount of css customization. Paying for CSS customization would increase the length of the customization file and the number of attributes allowed by the filter. Customized CSS would still always be able to be overridden by a viewing user's own style.
Multiple user icons
Much like LJ and DW. Free users can upload one icon and pay to add more, increasing in batches of 20-50 for $1 or so.
Increased messaging limits
Free users are going to have some limit on number of messages stored in mailbox, something like most recent 1000 messages. Paying a one-time fee would let users keep all past messages. This should be pretty nominal cost-wise; images aren't allowed in messages, so it's all db text storage.
Post series
This would allow users to make a series of connected posts with navigation links directly on the post similar to AO3's work series. The series navigation links would be visible directly on the post when it's reblogged. Series and series links would persist after the paid time expires.
Comment tracking
Allow users to get dash notifications for comment threads on public posts they don't own.
Increased image upload limits (one time)
Because free users will by necessity be limited in the amount of images they can upload, users will have the option to buy more image space for themselves or others. This would probably be around $1GB or a bit more, to help subsidize free user uploads. I might build a gifting feature that allows users to gift their allocated image space to others, but in a way that reduces overall image uploads, ie, for every 10MB of space gifted, only 5MB of space is received. Once image space is purchased, it would not expire and images uploaded would not be taken down.
Increased individual image sizes
Free users are currently limited to 2MB per individual image and 5 images in an image set. This might be bundled with the above increase of image upload limits. Users would be allowed to upload higher-quality images and the images would remain high quality once the payment period expired. Pricing for this depends on bandwidth costs.
Gift points
I'm tentatively thinking of a payment system where paid features are accounted in site points, so that users can buy points to gift each other. Then the gifted user can use their points to get the features they want, rather than being gifted a specific feature. This would also make it easier to allow volunteers to accrue nominal thank-you points for doing things like translating and answering support.
Less easy and less cheap
A tumblr importer ~$5 one-time
This comes up a lot in wishlists for a post-tumblr fandom site, but may become moot if either Tumblr's data gets lost after the Automattic sale, or if Automattic cleans up the tumblr API like they say they want to. As of December 2018, the tumblr API was causing lots of hanging errors for exports, and the exported files were often in the range of 4-8GB, so pricing would have to reflect the storage space required. An importer should try to 1) pre-populate the tags 2) preview the first image in the set 3) not import reblogged content or only import a preview of reblogged content. The API may not be able to distinguish between original and reblogged posts. The importer would probably require a developer key to log in a user to get their hidden/flagged posts, but tumblr has historically been pretty unfriendly about developer keys.
Opt-in link pingbacks
This would notify a user if their post is linked in someone else's post, if the author of the second post opts in to allowing pingbacks. The author of the first post would have the option of displaying pingbacks on the post alongside comments.
Custom blog sort
Users would have the option of displaying their blog by default by some order other than chronologically backwards. Options might include chronologically forwards, most popular first, most commented first, original posts only, or a custom X number of ordered sticky posts.
Custom dash views
Users would have the option to create new tabs on the dashboard, with all of Fandom 1 in one tab, all of Fandom 2 in another, and all RL content in another. Building this would require reworking how subscriptions currently work.
Personal analytics
Free users already get activity notifications, but paid personal analytics might include a network graph of reblogs, performance of likes and reblogs on each post over time, view rates, etc.
Post queue
Much like tumblr's, with a scheduling option to post at specific time. This would be a paid feature because it requires more server load. Some limited version may be available for free users.
Sideblogs
Sideblogs would require a slight reworking of how the site handles identity currently, but it should be pretty doable to build a sideblog system where it's easy to switch which blog is the designated main blog, or switch between acting as one blog or the other. They would need to be funded somehow because they could upload additional images, but they would need to be attractive enough that users would want to make a sideblog instead of making a whole new account. One possibility would be deeply discounted additional image space, so that paying for a sideblog gets more image space than making a free account.
Community specific paid features in addition to the above
Opt-in site wide calendar for events
All communities can make events that members can join and RSVP to (exchanges, fest weeks, liveblog, challenges, etc), but paid communities could opt in to listing their events on a site-wide calendar with events tagged for discovery.
Completion badges
For an event, community mods could upload a small badge or banner image for the event, and choose to have the badge link to the community or a specific post. Mods then award the badge or image to users who participate in or complete the event (eg, exchanges and challenges). The user could choose to display the badge on their profile.
Community role labels
Much like Reddit's flair, mods or users can add a role label after a user's name to display on posts and comments in the community. Could be used for exchanges, RP, reference communities, etc (eg, beta, css expert, RP factions).
Community comment tags
This would allow mods to designate a tagset to be used on comment threads, to allow flexible use. Examples might be tags for prompt/fill on a kinkmeme or question/answer for a reference community.
Community post and comment search
Full-text search requires a lot of server load and indexing, and will be limited site wide.
For comparison, here are the costs for paid accounts with similar services:
Dreamwidth paid account: $35/year
Dreamwidth premium: $50/year
Reddit premium: $72/year
Reddit gold (prior to 2017?): $30/year
Wordpress.com personal: $60/year
Pillowfort paid account: will update if they announce
Based on conversations with DW's denise, payments will initially be handled through a combination of PayPal, Stripe, and other mainstream payment processors until the organization can build a chargeback history to negotiate with another payment processor who will be more stable. Using PayPal, Stripe, etc runs the risk of being cut off for hosting adult content, but denise advised that cycling payments through different processors and making the payment system processor agnostic will make this a bit less likely. Pillowfort used PayPal from early 2016 through early 2019 before changing processors.
I'm also looking at funding through Patreon, which seems to allow funding for this kind of model and shouldn't have problems with the content, since the Patreon donations would be for the development of the site, not for accessing adult content. Automating Patreon donation integration with the site would require building a hook to their API, which uses a different authorization system than what Keppari currently uses. (Patreon uses OAuth, Keppari uses Devise). This shouldn't be too much of a problem, but would require building.
Issues with curated ad hosting
Discussion on FFA
I've given some thought to an internal ad system like Ravelry's, with ads focused on the userbase, but there's two issues with that. One is that it would require a lot of screening and management, and the other is that the attorney I've spoken with said it could run into both copyright issues and FOSTA/SESTA issues depending on what's advertised. If the ads are screened in-house it could open up liability issues if an ad went up that shouldn't have, and it would take a lot of specialized screening labor regardless.
It's not so much NSFW ads as ads that advertise something a rightsholder might come after. Like say someone runs an ad for their Redbubble site and uses an image of their fanart for the public domain Alice and Wonderland. If Disney comes after that, like they've come after artists who've sold prints for fanart of the original Alice in Wonderland, that would put the platform that served the ad in the middle and possibly open the platform to liability for having made money off of an ad for what Disney argues is copyright infringing content. Or if there's an ad for someone's Patreon where they post cosplay nudes, that could get into FOSTA/SESTA liability territory for advertising content that profits off what might be classed as sex trafficking and exploitation depending on whose attention it comes to. Those are the kinds of gray area ads that would take a judgement call and would still possibly cause trouble.
I am keeping this on the backburner, and any internal ads would have to be 1) shown to guest and free users only, 2) not displayed alongside NSFW content and 3) not animated or using tracking cookies or javascript. I'm going to reach out to Ryan North of the now-defunct Project Wonderful and the Ravelry advertising contact to ask for advice. (See Ravelry's advertising guidelines here)
Issues with a site marketplace
Discussion on FFA
Regarding a system like Deviantart's, where users can sell prints and other items and the site takes a cut, it would take a lot of infrastructure to contract with a print on demand firm and deal with disputed charges and all that. I'm just not sure if the potential revenue is worth it if it means either depending on lots of specialized volunteer labor or eventually hiring an employee.
Regarding a system like Etsy's, where users can list and advertise merchandise without the site being responsible for production, I'm very hesitant about it for a lot of reasons, the copyright one being the biggest. Putting aside the physical object problem for a service like redbubble or society6, somewhere like etsy needs a way to handle seller-buyer disputes, chargebacks for returned merch, etc. Even if the merch were purely digital, like setting up a service to facilitate digital commissions, I can imagine it being a headache if the site had to get involved when someone didn't deliver commissions, stopped communicating, or if the buyer was unsatisfied with the final commission. It seems like more headache than the potential return is worth.
A preliminary list of possible paid features and pricing
All prices below are hypotheticals I'm using to estimate and are in no way final. The features below are ones that are non-essential, create additional server load, and/or require extra storage space.
Easy and cheap, probably around $1 each / year
A tag viewer
Similar to xkit's tag viewer, see all tags a reblogged post has been tagged with. Either display in a popup modal like xkit or in a separate list like reblogs and likes currently. Might have a tag-cloud setup to avoid scrolling through lots of repeated tags, with an option to click and see users who reblogged with that tag. Might give paid users the option of allowing other users to see the tags on the paid user's posts
CSS customization
For accessibility reasons, free users should be able to do a limited amount of css customization. Paying for CSS customization would increase the length of the customization file and the number of attributes allowed by the filter. Customized CSS would still always be able to be overridden by a viewing user's own style.
Multiple user icons
Much like LJ and DW. Free users can upload one icon and pay to add more, increasing in batches of 20-50 for $1 or so.
Increased messaging limits
Free users are going to have some limit on number of messages stored in mailbox, something like most recent 1000 messages. Paying a one-time fee would let users keep all past messages. This should be pretty nominal cost-wise; images aren't allowed in messages, so it's all db text storage.
Post series
This would allow users to make a series of connected posts with navigation links directly on the post similar to AO3's work series. The series navigation links would be visible directly on the post when it's reblogged. Series and series links would persist after the paid time expires.
Comment tracking
Allow users to get dash notifications for comment threads on public posts they don't own.
Increased image upload limits (one time)
Because free users will by necessity be limited in the amount of images they can upload, users will have the option to buy more image space for themselves or others. This would probably be around $1GB or a bit more, to help subsidize free user uploads. I might build a gifting feature that allows users to gift their allocated image space to others, but in a way that reduces overall image uploads, ie, for every 10MB of space gifted, only 5MB of space is received. Once image space is purchased, it would not expire and images uploaded would not be taken down.
Increased individual image sizes
Free users are currently limited to 2MB per individual image and 5 images in an image set. This might be bundled with the above increase of image upload limits. Users would be allowed to upload higher-quality images and the images would remain high quality once the payment period expired. Pricing for this depends on bandwidth costs.
Gift points
I'm tentatively thinking of a payment system where paid features are accounted in site points, so that users can buy points to gift each other. Then the gifted user can use their points to get the features they want, rather than being gifted a specific feature. This would also make it easier to allow volunteers to accrue nominal thank-you points for doing things like translating and answering support.
Less easy and less cheap
A tumblr importer ~$5 one-time
This comes up a lot in wishlists for a post-tumblr fandom site, but may become moot if either Tumblr's data gets lost after the Automattic sale, or if Automattic cleans up the tumblr API like they say they want to. As of December 2018, the tumblr API was causing lots of hanging errors for exports, and the exported files were often in the range of 4-8GB, so pricing would have to reflect the storage space required. An importer should try to 1) pre-populate the tags 2) preview the first image in the set 3) not import reblogged content or only import a preview of reblogged content. The API may not be able to distinguish between original and reblogged posts. The importer would probably require a developer key to log in a user to get their hidden/flagged posts, but tumblr has historically been pretty unfriendly about developer keys.
Opt-in link pingbacks
This would notify a user if their post is linked in someone else's post, if the author of the second post opts in to allowing pingbacks. The author of the first post would have the option of displaying pingbacks on the post alongside comments.
Custom blog sort
Users would have the option of displaying their blog by default by some order other than chronologically backwards. Options might include chronologically forwards, most popular first, most commented first, original posts only, or a custom X number of ordered sticky posts.
Custom dash views
Users would have the option to create new tabs on the dashboard, with all of Fandom 1 in one tab, all of Fandom 2 in another, and all RL content in another. Building this would require reworking how subscriptions currently work.
Personal analytics
Free users already get activity notifications, but paid personal analytics might include a network graph of reblogs, performance of likes and reblogs on each post over time, view rates, etc.
Post queue
Much like tumblr's, with a scheduling option to post at specific time. This would be a paid feature because it requires more server load. Some limited version may be available for free users.
Sideblogs
Sideblogs would require a slight reworking of how the site handles identity currently, but it should be pretty doable to build a sideblog system where it's easy to switch which blog is the designated main blog, or switch between acting as one blog or the other. They would need to be funded somehow because they could upload additional images, but they would need to be attractive enough that users would want to make a sideblog instead of making a whole new account. One possibility would be deeply discounted additional image space, so that paying for a sideblog gets more image space than making a free account.
Community specific paid features in addition to the above
Opt-in site wide calendar for events
All communities can make events that members can join and RSVP to (exchanges, fest weeks, liveblog, challenges, etc), but paid communities could opt in to listing their events on a site-wide calendar with events tagged for discovery.
Completion badges
For an event, community mods could upload a small badge or banner image for the event, and choose to have the badge link to the community or a specific post. Mods then award the badge or image to users who participate in or complete the event (eg, exchanges and challenges). The user could choose to display the badge on their profile.
Community role labels
Much like Reddit's flair, mods or users can add a role label after a user's name to display on posts and comments in the community. Could be used for exchanges, RP, reference communities, etc (eg, beta, css expert, RP factions).
Community comment tags
This would allow mods to designate a tagset to be used on comment threads, to allow flexible use. Examples might be tags for prompt/fill on a kinkmeme or question/answer for a reference community.
Community post and comment search
Full-text search requires a lot of server load and indexing, and will be limited site wide.
