BitNami offers a variety of development and production stacks that make it quick and easy to set up a localhost-based development environment or even provision a production-based server with a full suite of tools. If you are familiar with the better known MAMP, offered by the German company appsolute GmbH, then you should have no issues using BitNami’s version instead.

What are the benefits of using BitNami’s MAMPStack?

First, as of the date of this article, their stack is up to date. It is compiled and built with the most recent, stable versions of PHP, Apache, MySQL, and phpmyadmin. Second, they offer a very easy-to-install PostgreSQL addon module that integrates into the MAMPStack. This provides the opportunity to use an alternative database, even leveraging PHP’s PDO extension to create a truly SQL-agnostic application. It should not be too hard in the future to add support for other open source SQL-based RDBMSs like Percona or even Drizzle. Third, they seem very responsive to their user community.

Why would you want to integrate MongoDB into your MAMPStack?

The days when a RDBMS could be the end all and be all of your backend are over. For more on this point, read part three of my five-part Smartup series, Web 3.0 Smartups: Moving Beyond the Relational Database.

In short, in the Social Web, smartups cannot use a RDBMS as their only backend tool for every job. A RDBMS is not a universal tool. In fact, RDBMSs — MySQL in particular — are overused and often misused.

Let’s Get Started!

Integrating MongoDB into your BitNami MAMPStack is a relatively straightforward process — at least if you are a developer accustomed to building and modifying your dev stacks. Reading this article will take you some time. But, once you fully understand this process, it should take no more than fifteen minutes to install and configure MongoDB to work within your BitNami MAMPStack.

How do I know? Because before posting this article, I deleted my BitNami MAMPStack using the uninstall.app application with which it ships. This deleted all the work I did in integrating MongoDB into the stack. I then reinstalled the stack and repeated the process below. Of course, I had backup copies of the BitNami MAMPStack because there is no need to redownload that. But, I did go through the entire below process. Total time? Thirteen minutes and four point six seconds — and that is with two MAMPStack server restarts. Bam!

Disclaimer: Before you begin, you agree that you have read this disclaimer and the next one and agree with them. You understand that you are entirely on your own with this process. If you are not comfortable with UNIX commands, if you have never worked within Terminal before, if you do not know how the steps listed below will affect your computer, and if you do not know how to fix any issues that may arise out of trying out these steps, then do not proceed. I am not responsible for what happens to your computer as a result of these suggested techniques. You have been warned. Proceed at your own risk.

Disclaimer 2: This process should not be used on production servers. It is only suitable for a development environment running on localhost.

A. Compiling the MongoDB PHP Driver From Source

Grab the very latest version of the MongoDB PHP Driver. Download the tarball version.

(Note: Although you can try installing the driver using PHP’s PECL command, I’ve had spotty luck with that approach in the past when attempting to install MongoDB into a third-party dev stack. The driver did not always get installed in the proper location. Sometimes it got installed in the extension directory of the default version of PHP that ships with OS X. When that happens, you have to uninstall the driver and try reinstalling it into the proper directory. As this has proven unreliable in the past, I find it easiest to compile from source then move the extension into the proper location within the MAMPStack. It just takes a few more minutes but ensures that everything is in its proper place.)

Drag the tarball out of your Downloads folder onto your desktop. Then double click on the mongo-x.x.x.tar tarball to extract the files. This will create the driver folder. Open up Terminal and navigate to that folder. Each line below starting with a “$” indicates a new terminal command. Before beginning, see the notes below the ordered list. Enter these commands one at a time in Terminal:

1. $ cd /Users/{your_user_name}/Desktop

2. $ ls

3. $ cd mongo-x.x.x

4. $ cd mongo-x.x.x

5. $ sudo /Applications/mampstack-5.3.9-0/php/bin/phpize

6. $ ./configure

7. $ sudo make install

Terminal Notes

Step 1: Replace {your_user_name} with the name of your mac account user. It is the name that appears within the /Users folder.

Step 2: The list command will allow you to double check the MongoDB file folder name which you will enter in the next step.

Step 3: Switch to the directory that contains your MongoDB PHP Driver and associated files. Replace the x.x.x with the version number of the driver which should be the same as that listed for the folder name.

Step 4: This seems like a repeat of above, but if you inspect the folder structure of the driver download, you will see what is going on. This switches into the directory within the downloaded folder that contains the actual driver source files. It is within this directory that you run the compile commands.

Step 5: The phpize command prepares the build environment for PHP extensions — in this case, for building the MongoDB PHP Driver extension (mongo.so). You will be prompted to enter your administrator password. This is your mac user account password (assuming that you are the owner of the mac).

When the screen of output is finished, you will have a compiled MongoDB Driver extension located in the modules directory of the driver folder. Look in /mongo-x.x.x/mongo-x.x.x/modules for the extension named mongo.so. Copy that extension into the following folder in your BitNami MAMPStack directory:

mampstack-5.3.9-0/php/lib/php/extensions

Now you need to add the following to your listed extensions within the php.ini file. In the BitNami MAMPStack, the php.ini file can be found here:

mampstack-5.3.9-0/php/etc

Open the php.ini file in your favorite IDE and add this to the “Dynamic Extensions” section of the file, just below the last active extension:

extension=mongo.so

Save and close the php.ini file.

Now, before continuing on to the next step, if your MAMPStack server is running, stop it and then restart it. Visit your phpinfo page to make sure that the MongoDB PHP Driver has been installed and is active. If you don’t know what a phpinfo page is, visit this link. (I made my PHP Info Page and placed it at root level in the apache2/htdocs folder before I began this process.) Run your phpinfo page and look for the “Configuration” section in the output. Now scroll down until you see “mongo”. Check to make sure the version number is what you expect.

If you do not see “mongo” listed, or the version number is incorrect, you’ll have to start the process again — but first you will need to delete the mongo.so file from BitNami MAMPStack’s PHP extension folder. However, if everything looks fine, you’re ready for the next section below — part two.

B. Adding and configuring the MongoDB Database

In this section, we’ll setup the MongoDB backend and make sure that it is functioning properly.

Follow these simple steps:

1. Download the most recent, stable OS X 64-bit binary version of MongoDB. Double click the tarball to extract the files.
2. Create a new folder called “mongo” in BitNami MAMPStack’s root. When you are done, you will have this directory structure: mampstack-5.3.9-0/mongo
3. Create three subfolders in this newly-created mongo folder, setting their permissions to 775:

   bin

   data

   tmp

   Within the newly-created data directory, add the following subfolder with permissions set to 775 as well:

   db

4. Install the MongoDB files you’ve just downloaded and extracted into the mampstack-5.3.9-0/mongo/bin. Make sure you install just the contents of the bin folder within the downloaded MongoDB folder and not the bin folder too.
5. Next, you’ll create a configuration file for mongoDB. This file will tell mongo where to store data, log errors, and which directory to use for temporary stuff. In your favorite IDE, create a new file named mongodb.conf in the root directory of your mongo install ( mampstack-5.3.9-0/mongo ). In that file, add the following:

   # Store data in default MongoDB directory structure, /data/db/
   dbpath = /Applications/mampstack-5.3.9-0/mongo/data/db
   
   # Set location where all MongoDB errors should be logged.
   # This should create a log file if it does not exist
   logpath = /Applications/mampstack-5.3.9-0/mongo/mongodb.log
   
   # Set location of pid file; this should create one if it does not exist
   pidfilepath = /Applications/mampstack-5.3.9-0/mongo/tmp/mongo.pid
   
   # Only accept local connections
   bind_ip = 127.0.0.1

   Save and close your newly-created mongodb.conf file.

6. To launch MongoDB server, open up terminal and type the following command all on one line. However, as we have just made significant additions and changes to the basic, out-of-the-box BitNami MAMPStack, you need to restart your BitNami MAMPStack servers to make sure all the changes are picked up.

   Once the MAMPStack servers have restarted, type this into Terminal — place your cursor in the box and copy the entire string as it does extend beyond the margins of the box:

   sudo /Applications/mampstack-5.3.9-0/mongo/bin/mongod --config=/Applications/mampstack-5.3.9-0/mongo/mongodb.conf

   Please note: From now on, this is how you will start your mongod server.

7. Test your MongoDB install to make sure that the server is running. By default, MongoDB listens to port 27017. You can verify which port MongoDB is listening to by looking up the configuration settings of your MongoDB PHP Driver in the PHP Info page. However, Mongo’s Web-based admin console listens to port 28017. Therefore by visiting “localhost:28017” in your browser, you can see if you have a connection. If you do, you’re all set!

To learn more about starting and stopping the MongoDB server (Mongod), see this resource.

(Note: You could install MongoDB into your /usr/local/ directory and then symlink the binaries out of the /usr/local/mongo/bin folder to the BitNami MAMPStack. However, the idea in this method is to keep all the applications bundled under the same master folder — your BitNami MAMPStack. That way, uninstalling the stack is very simple. You just delete the BitNami MAMPStack folder from your /Applications directory. The method presented here also makes it easy to move this application setup to another machine. Finally, although it is normally not an issue, with this method you do not have to worry about potential problems when upgrading your OS.)

C. Download and install phpMoAdmin

We are almost finished! If you’ve successfully completed parts one and two above, congratulations! You have integrated MongoDB to run inside of your BitNami MAMPStack. This last step will provide you with a tool to manage MongoDB.

Just as you use phpmyadmin to administer and manage your MySQL databases, MongoDB has several database admin tools written in PHP. We’re going to be installing phpMoAdmin. Grab the most recent stable version.

Once you’ve downloaded a copy, unzip it if it did not automatically unzip. Next, create a new folder within Apache’s htdocs folder called phpmoadmin. Copy the moadmin.php file into this new folder.

Done! You now can access this very simple, but useful MongoDB admin tool by visiting “localhost:8080/phpmoadmin/moadmin.php” in your browser.

Alternatively, you can use MongoHub or RockMongo to administer your MongoDB backend. I suggest checking all three out and deciding which one you like best.

Why are we using phpMoAdmin? It offers the most recently-updated version out of the three and it is simple to install as it is a single, small file. For this article, it is sufficient. However, the other tools may provide better GUIs and a stronger set of features. So, you should check them out and decide which one you like best.

Don’t Forget to Give Thanks!

That’s it!

You can further expand your BitNami MAMPStack by setting up VHOSTs in your Apache config file, but that is beyond this article. If you’re interested in that, see the documentation in the /apache2/manual folder.

Finally, please remember to give back to the open source community as it provides you with high-quality, powerful software with many freedoms — and often free as in cost, too. Share this article, write your own, create a version of this article for Linux distros or Windows, volunteer time to an open source project, contribute bug fixes, thank BitNami for their services, or donate to help fund an open source project. Free and Open Source Software (FOSS) needs your support!

Now go out there and create the next, greatest Smartup!

More resources

• Learn more about MongoDB
• MongoDB books
• Blending the Doctrine ORM with the Doctrine MongoDB ODM

After much debate, I decided to place BP Privacy in the WordPress Plugin Repository as that is the easiest place for the community to access it. Placing it elsewhere might result in it being quickly forgotten.

Please be advised that as of this post and release, I am no longer developing or supporting this plugin. Therefore, with this release ends my BuddyPress Privacy journey. BP Privacy is now in the hands of the community. It is up to someone, or preferably a team of developers, to fork BP Privacy, reshape it to their vision, and help it grow to meet the community’s needs.

This means that if you have issues with the plugin your only recourse is to read the BuddyPress Privacy Manual (start with the Site Administrator’s Guide section) or hire a developer. I am not for hire so please do not contact me. Also, I will not be answering any emails about BP Privacy, including requests for suggestions on competent developers to hire. Please use the BuddyPress Support forums instead.

Visit this link to download BP Privacy!

Even More Details

For a detailed history of BP Privacy, read my article, BP Privacy: History and Lessons Learned from Developing a Major BuddyPress Component.

BP Privacy’s Future

The current version of this plugin was to be released as v1.0 but I have reverted the version numbering to pre-release status. Therefore it should be treated as a pre-release version and not used in a production environment.

Before installing and using this plugin, you should fully and carefully read the plugin’s readme.txt file, the disclaimer.txt file, and the BuddyPress Privacy Manual that comes bundled with the plugin.

Also, please see the future.txt file which contains the roadmap features for BP Privacy’s further development. The items listed under v1.0-RC2 were originally planned for multiple version releases–some under v1.0.x and some under v1.1. These features have been gathered under v1.0-RC2 to suggest that they should be developed, fully tested, and rolled out before someone else (or some team) releases a production-ready fork of this plugin. It will take that long for a developer or team of developers to sufficiently understand the inner workings of this plugin before they can claim that their forked-version is production ready.

Enjoy and best of luck!

Note: Comments are turned on but I will not be allowing any comments asking for support as I am not providing support. I also will not be allowing through any negative comments. This is not a public forum.

It is important to state up front that there are many wonderful, helpful, supportive, knowledgeable, community-minded members in the greater WordPress community. If you are an active participant within this community, you already understand that fact.

Of course, a great community of supportive, fun-loving people does not guarantee that you will face few challenges with your WordPress or BuddyPress projects—whether that is starting and running a community, designing themes, or developing plugins.

This is the story about the challenges I have faced in bringing BP Privacy to fruition. It is just one developer’s journey and, as such, should not be construed as anything more than my perspective.

I hope that those who manage to read through this entire, long article walk away with not only a better understanding of some of the difficulties BP Privacy has faced, but also a feel for how they might want to approach taking on similar open source projects in the future.

Genesis of the Idea

In the beginning, there was an idea that BuddyPress needed privacy. Well, that idea was not present at the genesis of BuddyPress as it does not offer core privacy, but the idea was hatched in the early pre-RC2 release days of the BuddyPress project by two very active community leaders—one of whom was me.

At the inception of this project, BP Privacy had two developers. That’s right. I had a project partner. This partner was a key BuddyPress member and very interested in coding his first BP plugin. We teamed up on this project as we realized the complexity of the task at hand and that it would be beneficial to have a project partner.

We had a number of discussions about how we should tackle this project. I set up a subversion repository on my dedicated server for the project and gave him access. I started the long, tedious process of learning, really understanding, the inner workings of BuddyPress. After all, BP Privacy would not be a typical plugin. It had to interact with all the core BuddyPress components. It had to monitor and take control of output based on an individual’s desires. We both realized that BP Privacy was going to be a major, foundational component in its own right—even though it would be a third-party plugin.

However, as weeks passed into months, my project partner’s schedule did not allow him to participate. So, I told him that I was just going to get started and that he could join in at any time.

So that is the humble, less than exciting beginning of BP Privacy. It started with a two-person project team but ended up becoming a solo effort.

BP Privacy Timeline

On the BP Privacy site, I state in a blog post that this journey has been 16-months long. Of course, that was posted basically October 1, 2010. So as of the date on this post, the process is nearing 20 months. The reality, however, is that this project had its inception even earlier, almost two years ago.

Here is a blow-by-blow timetable for BP Privacy and some of the key factors and issues at each point along the way:

Project idea inception: Early April 2009. My project partner and I began discussing BP Privacy (what was at that time called BPAz or BP-Authz)

First code written: June 23, 2009. This was two months after hatching the concept. It was the point when my project partner determined his schedule would not allow him to participate. So, I started coding the project on my own.

First public beta release: December 5, 2009. Only four months and two weeks after the first code block was written, I released a very solid public beta version to the community. Note that before that public beta release, there was a small, select group of private alpha testers.

This was a very solid beta version with only a few minor bugs. It worked perfectly with BuddyPress v1.1.3, offering privacy filtering for four of BuddyPress’ then core components. But the rug was about to be pulled out from underneath the project.

Codebase and platform concerns arise: January 2, 2010. As BuddyPress 1.2 was fast approaching release, it became clear that a major BP Privacy code refactoring would be required. A good portion of the previous 4 months of work would need to be reevaluated and much rewritten. As I looked at the time commitment involved, I realized I needed to try a new approach.

Not surprisingly, this approach failed. It only raised about $175 dollars. Without a big financial boost to help me focus on BP Privacy, I had to turn my attention elsewhere for awhile.

Late spring through early fall of 2010: The BuddyPress project experienced critical uncertainties in my opinion. These uncertainties made me question its long-term health. During this time, the development of BP Privacy progressively slowed down, practically grinding to a halt in late summer of 2010 as I awaited a few, final core patches I had submitted months before to be accepted.

Due to these factors, nine months passed with very little development time being invested.

Announcement of Public Release (v1.0): September 30, 2010. I was privy to some promising developments in the world of BuddyPress that gave me hope that BuddyPress might actually weather the storm. So, after almost nine months of greatly reduced activity on my part, I went out on a limb, venturing back into the BP Privacy project on a more serious level once again.

I created the BP Privacy site and made an announcement on that new site that BP Privacy would be released on November 8, 2010. This is the first officially-advertised date given for the release of the public, production-ready version (v1.0).

A few weeks later came the news for which I had been waiting. The BuddyPress community had a shot of adrenaline and renewed hope. We welcomed the announcement that Paul Gibbs and Boone Gorges had been “promoted” to core committers.

Of course, November 8, 2010 came and went. I continued working on BP Privacy as time permitted as I patiently awaited the release of BuddyPress 1.2.7 which was finally released on December 22, 2010.

BP Privacy’s Future: See the end of this article.

Time Invested and Anticipated Returns

Projects of the magnitude of BP Privacy require a considerable time commitment. Whereas it is difficult to be absolutely precise, I have a pretty accurate estimate as to the number of hours I’ve invested in BP Privacy. My total time spent to date working on BP Privacy is 1450 hours.

What kinds of activities go into a project that would require such a time commitment? A great number of essential activities such as: emails, forum and IRC discussions, support of alpha and beta1 testers, writing and submitting core patches required to bring privacy services to BuddyPress, debating a number of these patches, studying and thoroughly understanding the inner workings of BP, keeping up to date with codebase changes in BP Trac, writing tools that were necessary in figuring out some unexpected behaviors with BuddyPress’ action and filter hooks, continuous and exhaustive testing of BP Privacy, and writing detailed documentation. Of course, all of this is on top of the actual coding of the component itself which has required (so far) two major refactorings of the codebase.

What will I earn for all of this effort? Zero. Okay, I had a total of about $225 in donations to help support development ($175 as mentioned above plus $50 received before that post). I am very grateful to all who donated, to my select testers, and to everyone who offered support in other ways.

This means that I will have earned just shy of 16 cents per hour working on BP Privacy. So, the next time you question the commitment and contribution of those who actively volunteer in the open source world, remember that number. Of course, if all the additional hours of time that I’ve donated on the BP support forums, IRC, via email, Twitter, and Skype are included, that total would undoubtably be about half of that.

Financially, I would have been better off spending that time working at McDonalds. It is ironic that the vast majority of people who will benefit from my work will not even contribute enough for me to buy a Big Mac. By the way, I do not eat at McDonalds so please don’t send coupons. In fact, I am not interested in any more donations.

Why do I have a section emphasizing the monetary aspects of BP Privacy? Because like the vast majority of people, I need to pay bills, put food on my family’s table, and save for the future. How many of you can donate 1450 hours of time creating free products or services for others to use?

I am a vocal advocate of the open source model, as anyone who reads my blog and tweets would know. I have volunteered a thousand hours plus of my time answering questions on the BuddyPress community support forums, via email, in IRC, on the phone, and via Skype. None of those hours are included in my total time spent on BP Privacy. Like many active members of the community, I give in more ways than just creating plugins.

The reality for me is that this community and its open source model does not make it possible to earn even a small part of my living in a way that I prefer—coding great-quality GPLed plugins that provide needed services to others.

As I do not take on client work–I’ve discussed this fact with people many times before–I need another means with which to recoup some of the time I have invested in coding open source software for the community. If you really want to learn more about this point, please read this post about this issue from my perspective—and read the comments for a fascinating discussion.

Lessons Learned

Here are a few lessons learned that may help other WordPress and BuddyPress developers have a better experience with offering GPLed software to the greater community.

Work on Projects that Give You Energy, Not Sap Your Strength: By and large, I have lost more energy working on the BP Privacy project than I have gained. It has been exceedingly frustrating at times. To be honest, if this were not something desperately needed for the BuddyPress platform, I would have dropped this project a year ago.

At the time I started coding BP Privacy, I was planning on using BuddyPress as the foundation of my startup, and privacy was key to that vision. So it made sense to continue BP Privacy and then release the component to the greater community once it was ready. Had I any idea how vocal the negative minority would be as they impatiently waited for me to provide them with high-quality, free-as-in-cost software, I would have canned the community release a long time ago and just worked on it for my private use.

The Vocal, Negative Minority: It is important to realize that more likely than not, the vast majority of users will be happy about your work, or at least indifferent. Unfortunately, human nature makes us more vocal when we’re displeased than when we are pleased. It is a minority of users that will be anywhere from disappointed to obsessively outraged. It will be this minority that will be most vocal. If you release your work to the community, expect to have a greater volume of “I hate you” than “I love you” feedback from your user base.

Whereas community members may appreciate your volunteer help on various support forums, and paying clients may love you, when it comes to freely-contributed plugins, don’t expect the same rosy reception.

Don’t Expect Donations: Based on the vast majority of all plugin developers’ experience, ninety-nine percent (and realistically more) of all users will never donate to your efforts. There are many plugin developers who have written about this. Here are just a few articles to shed some light on this issue. Again, read the comments to get a more balanced perspective on this issue as there are good points on both sides:

• Have you made a donation to your WordPress Plugin Developer?
• Do we do enough to support WordPress Plugin Developers?
• Open Source Motivations

The donation model is not broken, for the vast majority of creators, it never worked to begin with. I have tried many tactics to increase donation conversions. My plugins and appropriate blog posts all had obvious donate badges. But that has not made a difference. Donating to something that is freely available apparently also goes against human nature.

Plugin support: Unless you clearly and explicitly state that there will be zero support offered for your plugin (at a minimum that should be communicated in the readme.txt file) then it is your moral obligation to offer some level of support if you release a plugin to the community—which includes forking an existing plugin.

Therefore, expect there to be questions that must be answered, that user issues will take away time from your other projects, and possibly impact your paid work and family obligations. There will be users who claim they are having a problem with your plugin when in actuality it will be caused by something other than your plugin. No matter how hard you try to communicate that it is not an issue with your plugin, in these people’s minds, you will still be the party at “fault”.

It is for this reason that some plugin developers fully exercise their GPL rights. Please note that if you plan to charge for support, you should be aware of a potential issue.

Since all WordPress plugins and themes need to be licensed under then same GPL version as WordPress itself–GPL version 2–you do not technically have the freedom or right to charge support fees. That explicit freedom and right was added later in GPL version 3. (Compare the last paragraph of Section 1 of GPL version 2 to the last paragraph of Section 4 of GPL version 3).

Therefore, if you are planning on charging for support, you are operating outside the freedoms of the GPL version 2. You would be wise to seek legal counsel.

Disclaimer: You should seek legal counsel if you have questions or concerns about your freedoms and rights under the GPL. I am not a lawyer and the information presented is my opinion only.

With Plugin Popularity Comes Possible Trouble: I do not envy plugin developers with high download counts. I know that that means one of two things: they are at the first stage of the plugin’s support lifecycle where they are spending an inordinate amount of their time supporting the plugin (probably for free), or they will soon be entering the final stage of the plugin’s support lifecycle where they discontinue support and future development as their time commitment to the project cannot be sustained.

It is for these two reasons that I always donate to plugin developers whose software I use and only use plugins that I am sufficiently interested in as I expect that one day I will have to maintain them myself.

Plugin development should not be a popularity contest, he or she who has the highest plugin download count often does not win. Do not release a plugin for praise and glory. That rarely happens. What really happens is the more popular your plugin becomes, the greater the potential for you to lose control over your time. This can lead to a rather unpleasant, overall experience with your project.

Alpha & Beta testing: If you have limited time to work on your project, then it is best to make the alpha and maybe first beta version private releases. Provide copies only to those people who you believe will genuinely test it and provide you with useful feedback. It is better to have a small, focused group of testers than a horde of quasi-interested and knowledgeable testers.

The exception to this lesson would be if you have a team of developers who can share the responsibilities of managing a public alpha and beta test. But, if you are a solo developer, you could be in for a world of hurt if you set your pre-release software free for any and all to test.

Bugs will continue to be found even after you’ve released the first public version. You have to go no farther than WordPress or BuddyPress Trac to see how many bugs still exist in those stable, public products. That is the nature of all software. No matter how mature a software product, there will always be bugs, some of them serious.

Develop on a Developer-stable Version: Although BuddyPress v1.0 was the first official public release deemed suitable for general use, it was far from stable from a developer’s standpoint. This is evidenced by the fact that significant changes occurred between BP 1.0 and BP 1.1 that caused developers some grief and then even greater changes occurred between BP 1.1 and BP 1.2.

In my opinion, BP 1.2 should have been then first public release. In other words, BP 1.2 is really v1.0 in my mind. Now, with BP 1.3 close at hand, I’m concerned that developers (and possibly even users) will be faced with difficult upgrade challenges. Although, Paul, Boone, and John have been working hard to make the transition to BP 1.3 as painless as possible. So, perhaps my concerns are not valid. Whatever the reality, when the dust settles, BP 1.3 will become the first developer-stable version in my opinion.

Group or Solo effort: As should be obvious from the start of this article, you need to carefully vet your project partners. Although I had little data with which to make an honest assessment of my project partner’s suitability–the BuddyPress community was very new at the time–I nevertheless made a mistake at the start of this project. I should have quietly started by myself and only asked for interested project partners once I had some code to share and knew more about the skill sets of the various BP developers with whom I associated.

Communicate Less, Not More: This may come across as a hypocritical suggestion in light of some of the communication issues BuddyPress had last year. However, you need to differentiate BuddyPress as a developer platform and community from that of developing a BP plugin. With the former, the community is what makes the project a success. With the later, only a few key people need to be kept apprised. Communication is essential to the former, whereas to the latter it is not necessary until the plugin is released.

When it comes to plugin development, it is better to surprise the community with a new release (especially the initial release) than it is to build up their expectations. Although there is a thrill with getting validation for your efforts at the start of a project, there is no way to know what challenges lie ahead and how difficult the task may be. Interest and attention in any project can quickly turn negative if there are seemingly few results to share. Blame will always go to you, whether the issues holding up your project are beyond your control or not. This is especially true for a project that is deemed very important or possibly even vital—such as BP Privacy.

Once a plugin is released to the world, then proactive communication and vigilant project management are crucial to the project’s continued success. But before the public release, communicating less might actually help the project succeed as you won’t be distracted by the negative vocal minority.

Promised Release Dates: As a follow up to the point above, it is best to never put a date on a release. You are working on a plugin, not the core foundation of WordPress or BuddyPress where it makes sense to have project deadlines and development freeze dates.

If you do communicate a release date, do not be overly concerned if you fail to meet it. You are generously working on GPLed software that will more than likely earn you little if any for your efforts invested. You are not beholden to anyone.

Even the BuddyPress project has difficulties meeting its promised release dates. As this article can witness, there are many factors that contribute to a missed release date. Some are beyond your control. From a community standpoint, it is best if people remain patient and remember that they are getting GPLed software that provides them many freedoms of use. The software will be released when its released.

Use of the WordPress Plugin Repository: The WP Plugin Repo is a great service to developers and the greater community. You should use this service if you are planning not to exercise your full GPL rights. However, do not use the Repo for releasing alpha, beta, or RC versions. Most users will have no clue what an alpha or beta version truly means. More importantly, most will not care. If it’s on the Repo they’ll expect it to work. You should make your plugins available on the Repo only when they are ready for full public release. Until then, use another service, or your own server, to make pre-release versions available to those whom you wish to have access.

When Will BP Privacy Be Released?

Over the past two months, I have been reassessing my role in this project. As you have found out from the above history, my time commitment and investment into this project have been substantial. I’ve decided that the time required to support and maintain this project, and the energy required to do it properly, is incompatible with me earning a semblance of a living. It has also taken too much focus away from my current startup.

This project started out as a team effort but unfortunately became a solo effort. I believe that this project needs to become a team effort again—as in a team of developers, not a team of testers.

To be clear, BP Privacy was never intended to be a core BuddyPress component—even though some of you think that was the case. I am not and have never been part of BuddyPress’ core development team. I was simply an active community volunteer, support forum moderator, and plugin developer.

As most of you know, I am a staunch privacy advocate. Since my first days with the BuddyPress project, I have believed that privacy was a necessary core feature. That has yet to be realized. Perhaps part of the BP Privacy codebase can serve that purpose in the future. Although it might make more sense to refactor BuddyPress, offering true core privacy as a component.

What does this all mean?

I will be releasing the fully-functioning BP Privacy codebase over the next several days, along with a very extensive manual (35+ pages). At that point, I will end my official involvement with the project, and as such, I will not be providing any support.

The project will be in the hands of the community. It will be available for anyone to use as is, expand upon, fork, or even merge into BuddyPress core. Perhaps a group of developers will adopt BP Privacy and maintain it as a community-based project.

Because of my decision to end my official involvement with the project, I’ve decide to back tag the version I’ll be releasing, making it a release candidate instead of a public, ready-for-production version. Therefore, it will be v1.0-RC1 instead of V1.0. It also means that I will not be placing it on the WordPress Plugin Repository per the reasons I mentioned at the end of the last section. It will be available for a short while on the BP Privacy site before that site is taken down. The link will go to some yet-to-be-determined public repository. I will also be placing the link within a BP support forum thread.

By the way, for any group of developers interested, I have registered the bp-privacy distribution name with the WP Repo. I would be more than willing to assign that over to another group, if that is possible, or at the bare minimum add other committers. But be advised that I will not be participating in the project anymore.

Once BP Privacy v1.0-RC1 is out, it will be up to each person to fully evaluate the plugin and decide for themselves whether or not to run it on a production site. Although in my exhaustive testing BP Privacy works very will under WP 3.0.4 and BP 1.2.7, you must decide for yourself the viability of its use in a production environment. Thus, please be advised, no matter what you do, you are on your own until (and if) a new group of developers takes the reigns of BP Privacy and assumes support and maintenance responsibilities.

As far as the upcoming release of BP 1.3, I have not fully tested the most recent BP trunk version in Trac. Therefore, I cannot say how much refactoring may be required. I may put some effort into that, but do not wait for me. You should take the initiative and bring it up to date on your own volition.

As far as the few people that have pre-purchased BuddyPress Privacy Support Plans, I will be refunding all the monies received over the next week. But first I will focus on getting BP Privacy out the door. I will also be refunding my two, wonderful advertising partners. Yes, your ads have been up on BP Privacy going on three months (I have only charged them for the first month), but you have not received the type of exposure that you had expected. It is only fair that you get full refunds as well.

I hope that BP Privacy finds a useful life going forward!

Nope. It is real. The reason is simple and practical.

This past Wednesday during the BuddyPress Developers’ Chat on IRC, it was decided that another subdecimal release of BP was necessary to provide a few fixes to some key bugs. BuddyPress v1.2.7 is scheduled to come out around the end of this coming week.

As I thought about this more and more over the past few days, I released that it is not a good practice to release a major new BuddyPress component targeted to a version of BuddyPress that will be obsolete a few days after launch. There is no way to determine how many additional changes to BuddyPress’ core files will be made over the next week—some of which could affect the operation of BP Privacy.

It would be foolish to release BP Privacy this coming Monday and then take a chance that it will play well with BP 1.2.7 when that comes out four or five days later. It could be an operations pain for my users and a support nightmare for me. So the prudent course of action is to postpone the release of BP Privacy pending the release of BP 1.2.7.

Therefore, BP Privacy will not be launching tomorrow, November 8, 2010. Instead, assuming BP 1.2.7 will be released as detailed in the link above–and that there are no major issues with it negatively affecting the operation of BP Privacy–the new launch date for BP Privacy will now be Monday, November 15, 2010.

It’s just one, short week. I’m just as eager to set this free as you are to get your hands on it. But prudence and patience must win out.

It’s Not a Total Loss

There are tangible benefits to this postponement. If you have not yet purchased a BuddyPress Privacy Component Support plan (BPCSP), this delay gives you an additional week to act. It will allow you another chance to get a great, permanent discount on support plans.

Furthermore, if you are a current advertiser on BP-Privacy.com, I’m going to give you the full month of December at no additional cost. I cannot justify having my ad clients paying for a full month but not having a full month’s worth of regular traffic. So, December is on me!

This offer for an extra month (December) of advertising will apply to the last two remaining ad spots if they are leased before BP Privacy launches on Monday, November 15, 2010.

This re-released version is what I call a plugin widget as it is a BuddyPress-specific widget and must be activated like other BP plugins. Widget installation is handled this way so that if BuddyPress is not activated, then this plugin widget will not be loaded—which could cause issues with your WP site. The widget does an internal check to see if BuddyPress is activated, if so then it continues loading. If not, it stops loading and will not be visible in the widget gallery. The widget is automatically activated sitewide so your other members will not see it in their plugins section if you’re running a multisite install.

Download BuddyPress Featured Members Plugin Widget and Donate!

You can download version 1.2 of the BuddyPress Featured Members Plugin Widget from the WordPress Plugin Repository. Even more excitingly, you can help me support this plugin, encourage me to create new ones, and enable me to keep living by selecting a sponsorship level below and clicking the “Pay Now” button. Thank you!

Sponsorship Levels

Supporter $15.00 Donor $25.00 Sponsor $50.00 Benefactor $100.00 Patron $250.00 Open Source Angel $500.00 Holy Cow! $1,000.00

If you are a corporate user, consultant, plugin developer, or theme designer and profit from using my plugin, please consider donating at one of the upper levels. Thank you!

Using the Plugin Widget

Please read the readme.txt file for installation and usage instructions. If you have any issues, please leave a comment in this post, or visit the support forum for this plugin widget.

I wrote a response but decided to share it here as I periodically receive similar DMs, PMs, and emails. So, the next time that someone asks my opinion on this issue, I can simply point them to this post and be done with it.

Although this topic seems to rear its ugly head periodically, it clearly will not die. This is not an attempt to reignite any of the heated debates of the past.

Please respectfully add your comments and thoughts. I will include all that stay civil.

My Response

You have specific freedoms with all GPLed themes and plugins. To find out what those are, you should read the appropriate version of the license under which a given theme or plugin is licensed.

Here are a few things to consider:

1. If you turn around and release any premium GPLed theme or plugin to the public, you will have to offer support to anyone who uses it or tell them that there is no support offered. Most authors of premium themes and plugins will not provide support for thier work if it was obtained from another site.
2. The community in general frowns upon people who take someone else’s work and profit from it—even though it may be perfectly acceptable under the GPL. So, if you decide to redistribute someone else’s premium work for a fee, then you should be aware that it may cause some backlash. If you are using someone else’s premium work as the basis of a new product, in other words you will be adding additional value to it, that is a different issue. The value added should be appreciable, you must always give credit to the original creator, and the work must remain licensed under the GPL.
3. You will have to provide your own download site. Since you are not the author of the theme or plugin, the WordPress repository will most likely not accept it for inclusion. The exception to this would be if you are creating a new version of the original theme or plugin, if you are adding additional, substantive value to it as detailed above. One scenario would be updating and rereleasing a GPLed theme or plugin that the original author no longer supports.
4. Many people within the greater WP community frown upon such maneuvers in general. Both premium theme designers and premium plugin developers donate a considerable amount of time to designing their themes and coding their plugins. They are simply trying to earn an honest living from their generous contributions.
5. There is nothing in the GPL that disallows theme designers or plugin developers from charging a distribution fee or a support fee for their work. The GPL is about usage freedoms, not about free-as-in-cost software. There is nothing in the GPL that differentiates between a designer’s work being fundamentally different than a developer’s work. So designers and developers are operating within the rights of the GPL when they offer their work for a premium—as long as they are only charging a distribution and/or support fee. When it comes to offering premium themes or plugins, any talk about the differences in rights between designers and developers is outside of the GPL, is a matter of opinion more than legal fact.
6. Currently it seems that in the WordPress community, premium theme designers are accepted in general whereas many premium plugin developers are not. I believe this disparity, this inequity, cannot last for long. The community needs both designers and developers. If developers are not afforded the same opportunities, then some will move on.
7. See my post in the following thread for my additional thoughts and opinions on this topic.

UPDATE: January 19, 2010 A year after this post and here are the results. See my current thoughts on this issue in this article, BP Privacy: History and Lessons Learned from Developing a Major BuddyPress Component.

I think it is not only fair and appropriate, but also necessary for plugin developers to have the opportunity to make a living, or at least part of their living, writing great code that extends the base functionality of the BuddyPress platform.

To be clear, I am not an employee of Automattic. Like the vast majority of BuddyPress developers, I do not get paid a single cent for my contributions. In fact, as a salaried employee of Automattic, Andy Peatling, the lead developer of BuddyPress, is the only one who gets paid for his time working on this Open Source project (as far as I know).

Again, I am not looking to fan the embers of previous debates. I do not have any issue with how Automattic runs the WP plugin repository or care if they never list commercial plugins. That is not my point.

All I’m asking is how can plugin developers exist on an equal footing with theme designers when it comes to the issue of earning a living? Currently, the only three options that developers have, it seems, are to advertise a donate button for each plugin, accept consulting gigs, or accept advertising on their website. But donate buttons rarely provide much support and providing consulting services to clients is not for everyone. Furthermore, for me, I do not care to turn my personal website into a billboard.

The argument that plugin developers benefit by offering their work for free is flawed. It assumes that all developers are looking for consulting work, and two that all developers who offer their work for free will receive consulting work. Whereas it is certainly the case that some plugin developers have built a nice consulting business as a result of their donated work in the WordPress community, that does not mean that this route is for everyone.

What if a developer just wishes to code great-quality plugins like a theme designer designs high-quality themes? What if he or she does not want to provide any other service? How should this developer be compensated for their time?

But, since you asked, I do have a donate-like button for my BuddyPress Privacy Component. You can read more about my version of “donate” here.

I would like to hear some ideas on this topic as I have contributed much time to the BuddyPress community but have not earned a single penny. I am not looking to provide programming services or start a consulting company. I have a significant project that I’m working on so I don’t have time for much else.

Since I am not yet making an money on my project, I need a vehicle to earn some semblance of a respectable cash flow. Just as some theme designers earn a decent income from their premium themes, I would like to think that my income vehicle could be BuddyPress component development.

So, ideas and civil discussion, please!