Skip to:
Content

BuddyPress.org

Opened 14 years ago

Closed 12 years ago

#2708 closed defect (bug) (fixed)

Update recommended plugins list in readme.txt

Reported by: djpaul's profile DJPaul Owned by: boonebgorges's profile boonebgorges
Milestone: Priority: major
Severity: major Version:
Component: Core Keywords:
Cc:

Description

The list in readme.txt will point to an area on BP.org where we can control the list of recommended plugins to allow us to update the list between releases.

The new bp-admin pages have a screen for this, so we can parse in the RSS too.

Change History (29)

#1 @boonebgorges
13 years ago

I'd like to restart this discussion if possible. DJPaul, is your suggestion that we take all of the plugins out of the readme.txt altogether, replacing them with a link to a dynamic page? In any case, how do we decide which plugins get the placement?

#2 @Dennissmolek
13 years ago

I agree to remove the links from readme all together. A list of ones most users use, or simply have the highest ranked plugins on a page. You can always divide it by BP-Recommended and BP-Community-Recommended.

#3 @DJPaul
13 years ago

  • Owner DJPaul deleted
  • Status changed from new to assigned

#4 @DJPaul
13 years ago

  • Priority changed from normal to minor

#5 @DJPaul
13 years ago

Since the idea of the dashboard page for BuddyPress never made it in, I suggest we continue with the readme.txt list for 1.3 and punt this ticket. John / Boone?

#6 @boonebgorges
13 years ago

I say we just remove the list altogether. Replace with:

==

BuddyPress boasts an ever growing array of new features developed by the awesome plugin development community. Visit http://buddypress.org/extend/plugins to learn more.

==

What do you think?

#7 @Dennissmolek
13 years ago

I agree with Boone, the best plugins will be the ones with the most downloads.

#8 @boonebgorges
13 years ago

  • Owner set to boonebgorges

#9 @boonebgorges
13 years ago

DJPaul and I had a talk about this in the dev chat, and we agreed that the best method is to remove the list altogether. That way we don't have to make any potentially political decisions about this.

#10 @boonebgorges
13 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [4523]) Readme updates: removes list of popular plugins (fixes #2708); bumps tested-up-to WP version

#11 @boonebgorges
13 years ago

  • Milestone changed from 1.5 to 1.5.1
  • Resolution fixed deleted
  • Severity set to normal
  • Status changed from closed to reopened

Reopening as per dev chat.

#12 @boonebgorges
13 years ago

bpm team is concerned about linking to a 'buddypress' search; it shows a lot of old and spammy plugins.

Suggested solution: How about a static page, maintained by core devs, with a "contact us" box that lets people suggest plugins to be added to/removed from teh list

#13 @boonebgorges
13 years ago

  • Priority changed from minor to major
  • Severity changed from normal to major

#14 @boonebgorges
13 years ago

So here is the plan. I wrote a small plugin for buddypress.org that will allow super admins (the core devs) to store "recommended plugins" in a custom post type on the main buddypress.org site. Those plugins will then be displayed on http://buddypress.org/extend/plugins/, above the list of all plugins, under a special "recommended plugins" section.

People will be able to request that a plugin is added or subtracted from the list will be asked to post a new topic on the support forums.

Big upside to this strategy is that it will take effect immediately on deploy, because it's the very same page where readme.txt already points. Working with jjj at the moment to get it up and running.

#15 @foxly
13 years ago

Sounds like this could be a winner. Nice work guys .. :)

#16 @boonebgorges
13 years ago

(In [5209]) Adds 'recommended plugins' blurb to readme file, with link to new page. See #2708

#17 @boonebgorges
13 years ago

(In [5210]) Adds 'recommended plugins' blurb to readme file, with link to new page. See #2708

#18 @boonebgorges
13 years ago

  • Milestone changed from 1.5.1 to Future Release

We had some unforeseen problems with implementing the planned solution, so we're going a slightly different route (a new bp.org page with a hardcoded list of recommended plugins, compiled in part from the bp-media 1.5-compat list, and partially from my own knowledge of plugins). I would like to revisit this at some point down the line, for a better solution, so I'm moving it out of the milestone.

#19 follow-up: @foxly
13 years ago

"Easy Albums" is a commercial plugin. It's really just a wrapper for the Cincopa API http://www.cincopa.com/developer/start.aspx and requires users to have a Cincopa account to upload any kind of content. As posted on their sales page "Hosted on Cincopa cloud – no load on your server’s storage, CPU and bandwidth" Pricing as listed on Cincopa's site: http://www.cincopa.com/cincopamanager/paypal/plans.aspx

"Wang Guard" is a commercial plugin. It requires an API key to activate it. From their plugin repo page: "Now Free to everyone _for a limited time_!" (emphasis added).

In my opinion, we should not be listing commercial plugins on this page unless they are open-source and offer substantial amounts of free functionality.

#20 @boonebgorges
13 years ago

we should not be listing commercial plugins on this page unless they are open-source and offer substantial amounts of free functionality.

Agreed. Thanks for the heads up.

#21 in reply to: ↑ 19 @j.conti
13 years ago

Replying to foxly:

"Easy
"Wang Guard" is a commercial plugin. It requires an API key to activate it. From their plugin repo page: "Now Free to everyone _for a limited time_!" (emphasis added).

In my opinion, we should not be listing commercial plugins on this page unless they are open-source and offer substantial amounts of free funcionality

Hi, WangGuard is Like Akismet.

WangGuard is free and will be free for personal use, now is free for commercial use and in a future who make money with their site, they will have to pay. But I repeat, for personal use Always will be free.

There isnot difference between a Free API key or a commercial API key.

Please, WangGuard IS NOT a commercial plugin or a commercial service, you will have to pay if you make money with your site, if you don't make money, you don't have to pay for the plugin and/or service.

Regards

#22 @j.conti
13 years ago

I wrote a post to explain what is WangGuard and how it works.

http://wangguard.org/2011/12/26/welcome-to-wangguard-welcome-to-the-revolution/

Please read the post and you will see that you can not say or think that WangGuard is a commercial plugin. WangGuard is not a commercial service.

Thank you

#23 @j.conti
13 years ago

Please, we want to talk about this.

You marked WangGuard as commercial on this ticket and here http://codex.buddypress.org/releases/1-5-plugin-compatibility/

We received emails from Many people than dont make money with their sites and asking us how much they will to pay on a future, referring to post above. Our answer, NOTHING is free if you dont make money with your site <$200

We are sure that many people are not installing WangGuard because they think they have to pay for it on a near future and tickets like this and post like that are not helpful.

Plese, I need to know your opinion.

Thank you

#24 @boonebgorges
13 years ago

j.conti - It's the holiday season in the US and UK, and the core devs are on vacation with their families. Please be patient.

Thanks for the clarification about WangGuard's business model. I think foxly's right that we should only be including plugins that are either 100% free or offer a significant amount of free functionality. It sounds like WangGuard falls into this category, and I know that WangGuard is a legitimately popular plugin for use with BP, so I'm going to add it to the list.

#25 @foxly
13 years ago

With regards to the link http://codex.buddypress.org/releases/1-5-plugin-compatibility/ in your previous TRAC post:

Your plugin was marked as a "commercial" because, once a user reaches a certain level of traffic, they have to pay to access your API. Although your plugin page states that you offer a "Free API Key for personal use" and you've updated your plugin page with the text "Now free for everyone for a limited time", you're still selling a commercial service: access to your API. Without access to your API, the plugin stops working.

Being a commercial plugin is usually a good thing. It means you have a source of money to pay developers to keep updating your plugin, and it means you have a group of paying customers that you're accountable to. For a site owner, that means your plugin is far more likely to be kept up to date and working. Of the "free" plugins we tested, over 60% had at least one significant problem on BP 1.5. Of the "commercial" plugins we've tested, 100% either worked on the first try or were fixed within a matter of days.

If large numbers of users are contacting you asking "When do I have to start paying to use this plugin?" it means that you aren't doing a good enough job of explaining where you switch between "free" and "paid". You need to define *exactly* when you start charging people money in a way that's not open to interpretation.

BAD:
"Free API Key for personal use" ...(what is personal use?)
"Now free for everyone for a limited time" ...(what is a limited time?)
"Free if you make less than $200 a year from your site" ...(how do you check?)

GOOD:
"50,000 free API hits per month."
"Completely free until March 31, 2012"

Take a look at the examples below to see how big companies like Google, Amazon, and Pusher explain the pricing on their API's:

EXAMPLES:
http://pusher.com/pricing
http://mailchimp.com/pricing/
http://aws.amazon.com/cloudfront/pricing/
http://code.google.com/apis/predict/docs/pricing.html

Overall it looks like you've worked hard on your plugin and are starting to establish yourself in the BP community. Once you've updated your documentation to clearly explain your pricing structure, you'll probably start to see a lot more people trying your service.

Thanks!

F

#26 @j.conti
13 years ago

boonebgorges Yes, I know is holidays, sorry. I only add the comments :)

foxly, the limit (maybe) will be around 15,000 - 20,000 queries month, thats 500 - 666 queries day (666 registration day). Is a very high number of queries.

Are $200/month not year, thats means $2,400/year I can not know If a user reaches this amount. I have to trust the good will, but this is also the reason for limiting the queries. A person who has 666+ daily registrations, he must make more than $200/month, isn't it?

"Now free for everyone for a limited time" -> Always free for who don't reach 666 registration daily or who make less than $200/month. Limited time... I don't know, more than 7 moth, less than 2 years. We want to reach some task with the server and with the plugin, we have a lot of work with the plugin improving user management, sub sites management, more safety in the registration page, moderation of the users who register on the site (with and without WangGuard detection), etc. and many other things I can not explain.

Thanks for the recommendations. I will look at how to put this in the readme.txt

#27 @modemlooper
13 years ago

Funny how WordPress.org lists commercial themes but not one plugin and everyone wonders why developers can barely make a cent while theme developers are raking in thousands.

Who cares if the plugin is paid. I'm creating a pro version of BP mobile will that get it blacklisted? As Foxly stated, I do agree it should be very clear what is free. Personal use is the wrong wording for a social software like BuddyPress. You should just have two versions listed; the free and the paid.

Version 2, edited 13 years ago by modemlooper (previous) (next) (diff)

#28 @j.conti
13 years ago

modemlooper WangGuard operating philosophy is the same as Akismet. does not make sense to create two different plugin. All the functionality of the plugin are the same for paid and free, just change the number of queries month.

#29 @boonebgorges
12 years ago

  • Milestone Future Release deleted
  • Resolution set to fixed
  • Status changed from reopened to closed

I think this is resolved.

Note: See TracTickets for help on using tickets.