Jeff Sayre's Blog, page 4

It's Time for Blogging to Evolve

The concept of blogging needs to evolve. Whereas Twitter and Facebook seem to have stolen some of the wind from blogging, I believe that netizens in general still desire to control their webspace and their webpresence. That is one reason that Diaspora–the upstart distributed social networking project–found initial funding success on Kickstarter. People want to have control over their content and privacy. They want to use their personal website as the anchor, as the foundation for their online communications.

The issue is that the major blogging platforms do not offer the means with which users can connect their sites in a distributed, decentralized, real-time social network. Thus, Twitter and Facebook continue to dominate the social networking space.

The vision of blogging needs to change. Right now it is an old-school vision, where a blog is a little island of content that is for most purposes unintegrated into the real-time social web.

We're Not in Kansas Anymore

What needs to change? For starters, I believe that blogging and microblogging should not occur via distinct, separate platforms. I think these concepts need to be combined. I think that a blog needs to be re-envisioned as a multipurpose communications platform.

It would work like this. People could blab in 140-character (or so) snippets all day long if they wanted. But if they had more to say, they could easily do so without having to fracture the Stream by sending interested parties to their blog, to Facebook, or to another site.

In essence, you would summarize your basic idea on your own blog in 140 characters (maybe make it 200) and let each of your followers decide if they cared to see more. If they did, they could click a little icon to reveal your additional content—that is if you decided to post more content.

What would happen when a user wished to leave a comment? This would not be done via blogging business as usual. User contributions would not be via comments left on your blog, they would not be via the old-school capturing of others' thoughts onto your database.

Instead, a user would "post" a comment on their blog and then their ideas, their rebuttals, their comments would appear in real time on your personal Stream on your blog. The user, however, would still control their content as it was posted via their site and they did not have to physically visit your site to make the comment. They could delete, edit, or augment their content whenever they wanted and any changes would be pushed to your Stream on your blog.

Think of it this way. On your blog, you should be able to broadcast any idea that you would like to engage others in discussing. If your followers wanted to say a few words about your idea, great, if they wanted to provide detailed rebuttals or contributions, they would be able to do that as well. But for each user involved in the conversation, their contribution would be made via their own communications channel, in other words via their own blog.

Why would this be of benefit? The important point is that each user's Stream stays concisely organized in short tweet-like excerpts and that users do not have to leave their own Stream to continue more detailed conversations somewhere else. Users would not need to travel to Twitter to make pithy comments, then go to Facebook to check up on friends and view their photos, then go back to their own blog to check if anyone had posted a comment.

All Stream activity for each user would be managed in a single place, would be owned and controlled by that user, and would be located on that user's personal communications channel.

It is Time for the Next Social Communications Evolution

Why should a user have to have a Twitter, Facebook, Quora, LinkedIN, and other social-networking accounts? Why can't their blog be their personal communications channel to which others can follow in real time? Why can't their blog have a real-time Stream dashboard that shows the updates of all those they are currently following? Why can't their blog be their plug into the Social Web, instead of having to rely on multiple social-networking islands?

A WordPress or Drupal (or pick-your-favorite CMS) platform should offer real networking capabilities. Currently a WordPress network, as an example, is really a site that is controlled by a single entity. It is not a disparate connection of WordPress sites linked up across the InterWebs. It is just another closed data silo, not much different than Facebook.

I think the tools are already available to begin to make this vision come to fruition. With technologies like PubSubHubBub, some creative developers could take the popular blogging platforms and turn them into the next generation social network, into truly user-centric, user-controlled, globally linked, real-time distributed communications channels.

Blogging 1.0 Has Reached its Limits

The irony is that to announce this new article (or post) of mine, I will have to leave my communications channel, the channel that I truly control, and head on over to someone else's channel and tweet about it. This is why blogging is losing some of its steam. This is why many of my colleagues who used to post frequently to their blogs have not done so in a noticeably long time. The attention has been drawn away from our personal communications channels. The eyeballs are focused elsewhere. The closed-siloed, mega-social nightclubs are winning the battle.

It is time to change that; it is time to once again leverage the power of the Web, regaining control and rebuilding the power of our personal communications channels. It is time for blogging to evolve once more, for the next stage of the blogging revolution to begin.

My Related Articles

The Web is Not (yet) Social
A Flock of Twitters: Decentralized Semantic Microblogging

BP Privacy v1.0-RC1 is now available!

After more than 1500 hours of work, 7300 code and comment lines, and creation of a 38-page manual, BP Privacy release candidate one is now available for download and testing. It requires at least PHP 5.2.x and is developed and tested to work with WordPress 3.0.5 and BuddyPress 1.2.7. It also requires a modern Web browser and you and your users must have javascript enabled.

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.

BP Privacy: History and Lessons Learned from Developing a Major BuddyPress Component

Coding great-quality, open source software, while often rewarding, can also be a thankless, difficult task. As many have been asking for an update on BP Privacy–also known as the BuddyPress Privacy Component–I thought I would take the time to write up an exhaustive history of the project and share some lessons learned.

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 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.

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 and Boone 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!

BP Privacy: An Update

This is an update on BP Privacy. I felt that it was important to communicate its current status. I also think that it is necessary to address a few who are claiming that BP Privacy is very late, for instance this statement that it is "at least 14 months late now".

First off, whereas it is true that two-and-a-half months have passed since the initially-announced release date of the first public version of BP Privacy (version 1.0), I never promised that a public version of BP Privacy would be released before then. I had mentioned several times in the past, and in several places, that I was hoping to release a beta2, but I never set a firm date on a production-ready, public version until my above referenced post. So comments that BP Privacy is very late (as in over a year) are not valid.

Secondly, BP Privacy will be finished when it is finished. I am hoping that is soon, but the reality is that it will be released when it's released. You get what you pay for. I am not under contract to produce BP Privacy, I am not getting paid by anyone to provide free software to the community. This is an all volunteer effort. Attempts to goad any developer into accelerating the pace at which they are offering you free software are usually unproductive.

However, having said that, I will mention that I share a couple of the concerns expressed in the BuddyPress Theme Converts post. I may elaborate on this in an upcoming article on the history of BP Privacy and the lessons learned—to be published once BP Privacy has been released.

Note: I have received a very, very modest amount of funds via people who purchased a BuddyPress Privacy Component Support Plan at the pre-launch pricing and a marginal amount of ad revenue. I have not yet used any of those funds. They remain in my PayPal account and I may very well refund them. But these funds are not donations to the development work. They are pre-paid fees that purchase a bit of my time in supporting the plugin once released or a leasing fee for real estate on the BP Privacy site.

The HyperWeb: it's All About Connections

I recently came across this interesting graphic entitled Hierarchy of Visual Information. The author clearly states that it is a work in progress, just the genesis of an idea, a not-fully-formed thought. In fact, he rightly points out that this–in general–is not a new concept at all and provides a link to a Google image search result showing many incarnations of the data-information-knowledge-wisdom concept.

As I looked at his graphic, a different idea came to mind, a different interpretation of the concept in the context of the Web's evolution. The hierarchical nature of the illustration made me think of the increasing complexity that comes with increasing connectivity. It made me think of how hyperlinks (more precisely hypertext) preceded hyperdata.

I realized that the hyper meme can be extended to the various evolutionary stages of the Web. So, I'm presenting what I call the HyperWeb.

The HyperWeb

The HyperWeb is about increasing connectivity and the increasing complexity of those connections overtime. The chart below outlines a few of the salient features that I believe best describe each stage, or epoch, of the HyperWeb. This is my twist to the traditional data-information-knowledge-wisdom concept.

Complexity is an emergent property of the increasing connectivity, not a direct result of the Web's technical foundation and framework. But there's a twist. There is a positive feedback loop that can cause more connections to be made as the system becomes more complex. Connectivity and complexity thus feed on one another, accelerating the rate of change and pushing the Web faster toward its asymptotic future.

The graph below shows the HyperWeb's epochs plotted against connectivity and complexity. The straight line shows the approximate points where most people assume the various Web epochs will emerge—a nice linear, one-to-one relationship. In reality though, the HyperWeb's phase transitions live on an asymptotic curve, they are not linear. The asymptotic curve demonstrates that the initial stages of the Web's evolution are slow but greatly accelerate with increasing connectivity.

I've placed the Social Web in the Web 2.5 to Web 4.5 range. If it occurs, that is the zone in which I expect it to materialize, thrive, and then die. What's that last point? Read on.

Whereas the Web seems far away from Web 5.0, you may be wondering what will the World look like if the Web ever evolves to Web 5.0? You might also wonder what the heck is Web 6.0?

For one possible set of answers to those questions, you'll have to wait for my upcoming article, to be released in the coming weeks, entitled Cybernetics, the Social Web, and the Coming Singularity.

The HyperWeb May Not Reach its Full Potential

It's important to point out that, just like natural speciation, the continued evolution of the HyperWeb is not guaranteed. As with all evolutionary processes, advancements (innovations) may stop at a certain point.

The Web is a democratizing force that can help redistribute power. That is antithetical to most large companies interests—and a number of countries as well. Apple, Twitter, Facebook–and of course the phone and cable companies–want as much control as possible. They are fighting for control of the Web, not for the health of the Web.

It's possible that for political, societal, or economic reasons–or some combination thereof–that the HyperWeb's evolution may be curtailed. For instance, due to myopic business leaders, scared political leaders, or an uneducated, apathetic citizenry, humanity's journey on the HyperWeb may not progress past Web 2.0 or Web 3.0.

Each new Web epoch will bring opportunities and uncertainties. The changes will be transformational, reshaping global society. If the Web continues to evolve to higher and higher levels, individuals will increasingly be the main benefactors, not business or politics. As such, the vision and drive to bring each new paradigm shift to fruition will come more and more from the Web's users and not the Web's businesses—although revolutionary advances in technology will be required all along the way.

If society wants a truly Social Web, then people need to fight for the Web, to help push it past its 2.0 version, past its current limitations and restrictive user control. The HyperWeb will continue to evolve only if the Web's netizens make it so.

My Related Articles

The Web is Not (yet) Social
My four-part series, Web 3.0: Powering Startups to Become Smartups

The Web is Not (yet) Social

There is a common misunderstanding about the meaning of the phrase Social Web. I believe that most of the Web's netizens think that the Web is social. But in fact the Web is not currently social.

Whereas Facebook, Twitter, FourSquare, and other ventures are social platforms, they are not the Web. These entities are only part of the Web—although it's looking more and more "like" Facebook wants you to think that the Web equals Facebook.

The Web is currently not social. The social-media-driven Web is the metaspace analogy of meatspace nightclubs.

Each of these internally-focused social networks might have a globally-distributed data center, but all the activity occurs within the walls of their private social clubs. The activity in one social club is predominately isolated from the others. The activity does not freely spread throughout the Web. The conversations do not flow throughout the Web. They flow within each proprietary network with a very limited trickle of "conversation" allowed to the outside Web. Of course, this trickle is allowed out to encourage more people to come in to their closed clubs.

There is a monumental difference between social networking occurring on the Web and the Web being Social. Social creatures frequenting social networks does not make the Web inherently social. Why is this the case?

In my article, A Flock of Twitters: Decentralized Semantic Microblogging, I state:

With their closely-guarded data silos, social networks are not full participants in the Web, they are not participants in the interconnected data ecosystem. So, unlike an ecological web (think of a food web), the Web-based Internet is not as much of an intact web as it is a land of social network islands that punctuate an ocean of truly connected websites.

The Social Web, on the other hand, is a fully functioning and healthy ecosystem were all data are globally connected.

There is no disputing the fact that social is a big part of the current Web. Web 2.0 is the realm of social media, but it is also the web of exclusive, social clubs. Web 2.0 is about companies "doing" social media via cloistered social islands (called "networks") more than it is about making the Web itself a social space.

The Web is currently not social. It's the metaspace analogy of meatspace nightclubs. It's filled with private social silos, which are antithetical to the Web's vision. Each private social island is an internal network consisting of tightly-controlled infrastructure that offers its own vision of how humans should connect and interact.

Web-2.0-style closed social nightclubs are not the epitome of the Social Web. Their existence is a indication of how much further the Web has to go before it will become a Social space.

Metaville: a Non-social City of Social Stadiums

To better understand some of the points presented above, let's look at the fictitious city of Metaville. In this analogy, the city of Metaville represents the current state of the not-social Web.

Metaville is a city with millions of residents. From the outside, it might look like a regular, American city. People regularly gather in a number of the city's stadiums. In those stadiums, they socialize, sharing stories, pictures, minutiae of their daily lives.

The owners of each stadium are furiously growing the size of their stadium to make room for more people to join the conversations occurring inside of their stadium. Membership is often free but the two requirements are that the vast majority of your conversation must remain inside the walled colosseum and that you have little control over what the stadium owners do with your conversations.

There are a few upstart, niche arenas struggling to grab people's attention, but even these smaller gathering spaces mimic the rules of the big stadiums.

Is the city of Metaville social? Well, there are pockets of social activity spread throughout the city but all of that activity occurs in stadiums with each stadium primarily isolated from the others.

Learn more about the differences between the Social Web Versus Social Networks

It is true that social activity occurs within Metaville. But when people leave one stadium and go to work, to home, or even to a different stadium (some of the residents of Metaville are members of more than one stadium), they leave their friends and conversations behind. Yes, sometimes they will check back in with their friends in a given stadium and sometimes they'll get a ping from a friend within a stadium, but they don't take their friends and conversations out of the stadiums. When they join a new stadium, they have to assemble a new set of friends, start a new conversation history.

Conversations do not happen in the streets of Metaville, or at cozy little cafes and diners. Conversations do not happen between a resident currently in his house with another resident currently in her condo. Practically all of the conversations occur within the exclusive domain of the stadiums. Sure, a resident at home can chat with one currently located in a private stadium, but the totality of that conversation is made possible by the propriety infrastructure that each stadium offers its members—and even then the conversation still takes place within the stadium's system.

So the city of Metaville is actually not social. It is a place that has many stadiums within whose walls friends gather and conversations occur. But when a person leaves the stadium, their friends do not and cannot follow them. When a member leaves a stadium, a security guard inspects their belongings to make sure that very little is removed from the stadium.

In the realworld, in our meatspace, this is not the way life works. Our friends can come with us and even join us outside of the stadiums. Our friends can come over to our house, or we can chat with them in cafes, or on the streets, or in parks. We are not prevented from being social where ever we go.

Metaville is the model of the current Web. It has some very large pockets of social activity but the conversations and friendships do not readily travel outside of the stadiums.

This metaphor could be expanded further. Instead of Metaville being populated with a bunch of closed stadiums, it could be Metastate populated with closed cities whose citizens rarely leave to visit other cities, or Metacountry whose closed states have tight boarder-crossing restrictions, or Metaworld with closed countries tightly controlling and limiting the flow of information from its citizens into neighboring countries.

When you look at life in Metaville, you will see that the current Web is no more social than one stadium full of people, that the cafes and diners of the Web are ghost towns, that the stadiums of Metaville are more like dictatorial countries.

The Not-so Fine Line

You might think there's a fine line between calling the Web a space filled with private social clubs and a Social space itself. You might think that it is not a big deal to call the current Web social. But for Social Web Architects, such as myself, the differences and distinctions are large, not small.

Social Web Architects are fighting for the rights of individuals to own and control their data, to have powerful yet easy to use identity and privacy tools, to freely and easily carry on conversations throughout the Web—not just within the walled sanctums of a few snooty nightclubs. We are building technologies that will link data and allow for the serendipitous discovery of new connections with other datasets and with fellow human beings—no matter where on the Web those connections and people may lay.

The Social Web is the metaspace actualization of a user-centric controlled, globally-connected conversation space across the Web. In essence, the mission of Social Web Architects is to bring the Web's vision to fruition.

Fortunately, the Web is constantly evolving. What it is experiencing now are the natural growing pains of an adolescent platform. Many of the current social-media nightclubs will eventually give way to a more open, user-centric ecosystem. I believe that they will have little choice as humanity inexorably races toward a truly Social Web.

Outside Resources

For two additional (one differing) perspectives on this issue, see Dave Winer's, What I mean by "the open web" and and Stowe Boyd's, Messiness At Scale.

My Related Articles About the Social Web

Flowing Your Identity Through the Social Web
My four-part series, Web 3.0: Powering Startups to Become Smartups
Apple's Ping Versus the Social Web
How the Death of Net Neutrality Effects You
Goodbye Google Old Friend: It's time for the Open-Source Internet
Thinking Outside the Privacy Box
Regaining Control of Privacy and Identity: It's up to Each Individual

I've Got a Clot in My Klout: Influence Across a Distributed Social Web.

I've been a fan of Klout since its inception. I was a relatively early adopter of its services and believer in its ideal to become the standard for influence measurement. I still use Klout and believe in their vision. Why else would I place a Klout widget on my About Me page?

But there are two issues that I wish to address. First, only one of the six listed most influential topics on my Klout profile make sense. Second, without connecting my Facebook account, I'm significantly penalized.

These two issues have big ramifications for those of use trying to build the Social Web.

Luke, Use the Foci

About three or four months ago, I tweeted the same observation concerning the most influential topics list on my Klout profile. Someone from Klout promptly @replied to my tweet stating that with continued use, the algorithms would more accurately determine my most influential topics. But this list has remained unchanged.

I have not bothered to check this assertion, but I believe that sixty percent of my time tweeting and ninety percent of my time writing is spent on the topic of a user-centric, distributed Social Web. This is divided between generic categories of Internet freedoms (GPL, open source in general, net neutrality, data portability, privacy, identity, BuddyPress) and Web 3.0 (Semantic Web/Linked Data, smartups, WebID, FOAF, RDFa).

Yet my Klout profile does not reflect any of that. In fact, "Indiana" is one of my listed most influential topics when I would guess that fewer than 1% of my tweets have used that word.

Of course, I could be wrong. Klout can scour my backtweets a lot more efficiently and effectively than I can. It may be that fewer of my tweets are about those topics than I realize, that few people retweet any of my tweets that are about my primary foci. Perhaps I engage in conversational chatter on Twitter more often than I think—although I do know for which issues most people retweet and @mention me.

Whatever the actual truth held within my Twitter data, I'd be very surprised if "Indiana, SEO, Design, Influence, Google" are my most popular topics. I rarely use any of those words in my Tweets or hashtags.

I do not spend my time within the dungeons of Mordor, I mean Facebook.

But it could quite possibly be that Klout is accurate, that those are my most influential topics. If so, that means that the vast majority of my time has been wasted, that I shouldn't bother tweeting about #privacy, #identity, #opensource, #Web30, #BuddyPress, #SemanticWeb, #WebID…etcetera.

I'm of course being somewhat facetious. But when the vast majority of my tweeting and blogging foci aren't reflected in the self-proclaimed "Standard for Influence", I have to wonder whether Klout's algorithms need some tweaking, or whether I've got a clot in my Klout.

Interestingly, and on a side note, influence is one of my most influential topics! In my mind that invokes a self-referential, infinite-looping, circular-referencing maelstrom.

An Audience with Sauron

Without connecting my Facebook profile to my Klout profile, I'm penalized forty percent—whatever that means, I don't like the sound of it.

Although I do have a Facebook account, I do not use Facebook. I think I have four or so people whose friendship I've accepted and who are obviously waiting with baited breath to see what I'm going to say. To date, I have not made a single wall post. So, they will be waiting for a lot longer as I plan to never post any content in Facebook.

In fact, I think in 2010, I may have bothered to login to Facebook three times and that was only to checkout one or two aspects of its interface.

Why don't I use Facebook? If you've been following my tweets and reading my articles posted to my site, you will already understand why. Facebook is antithetical to most of what I believe the Social Web is about. I'm professionally working on helping to bring the concept and infrastructure of the Social Web to fruition. Thus, I do not spend my time within the dungeons of Mordor, I mean Facebook.

Since I don't use Facebook, some of you may ask why I use Twitter then, as it too is just another private data island. Simple. Although Twitter is a participant in the closed-silo wars, my posted content is accessible to anyone who wants to see it. In other words, they do not have to be logged in to access my Stream. With Facebook, you must not only have an account but also be logged in and be a friend of that person to see their Stream.

As I'm trying to promote the concepts of an open, distributed, user-centric Social Web, Twitter lets me get the message out to everyone—whether they follow me or not, whether they're logged in or not, whether they have a Twitter account or not.

An Island of Misfit Toys

If Klout is to become the true measure, source, authority, standard for influence across the online world, then it needs to stop living exclusively within the social networking private clubs. Why? Because influence occurs across the Web-based and mobile-based Internet. It isn't restricted to closed social-media silos.

What about all of my online activity that occurs within my various blogs? Many people comment on my articles. What about the activity that occurs on forums, like the BuddyPress support forum where I'm a moderator (albeit a very inactive one lately)? What about on identica, or Diaspora, or the various niche BuddyPress sites that are beginning to pop up?

Conversations and influence flow beyond closed private data islands. Much activity occurs across the decentralized Web. In fact, for those of us fighting for the Social Web, we envision a day when most of the social activity will occur across a user-centric, decentralized, distributed architecture. The exclusive walled gardens of the Web will become a relic of the bygone, archaic Web-2.0 days.

Shouldn't this all be factored into my influence, into the influence of those who spend their time outside the Islands of Misfit Toys? Of course.

Does this really matter? Yes. As companies are beginning to use Klout scores to assess a potential candidate's job application, to determine if a particular person has sufficient expertise to be awarded a consulting contract, and other inevitably unknown purposes, the accuracy and integrity of that score becomes paramount to all the Web's citizens.

Flowing Your Identity Through the Social Web

Some social networking platforms are beginning to buy into data portability. Whereas any step toward opening up the closed data-silo islands is a positive step, the real question is what does data portability actually mean?

Data portability is defined as the ability to "bring your identity, friends, conversations, files and histories with you, without having to manually add them to each new service."

Does this really solve the most important issue that users face when spelunking the depths of the social networking space?

While it's great that a user has the flexibility, the freedom, even the right to take their data with them, in effect they are not taking anything with them. Users are not actually porting anything from one site to another. Porting implies the moving of an entity from one location to another, the transferring of data from one machine to another.

In reality, data portability is about giving users the freedom and ability to grab a copy of their current dataset and paste it into yet another data silo. They are not actually moving their data as much as copying it from one silo to another. So, their data is now duplicated across multiple locations.

The data silo (the social network) from which the data was copied ("moved"), does not delete the content—often even after a user requests the deletion of their account. Why? Because a member's data, the content, is one of the most important business assets the social network owns. It is their key competitive advantage.

This is the fundamental defect with the notion of data portability on the closed Web. The duplication of a user's data across multiple networks makes it even harder for a given user to control their identity, privacy, and Web presence.

I don't want my personal data exported, copied, replicated throughout the Web. I am for data redundancy where it's efficient and necessary, but exporting a copy of my dataset (or subset) from one social graph to another does not make sense. You are duplicating your effort. You are splitting up–or more accurately duplicating part of–your identity graph into little pieces and then strewing them into different locations, placing them in multiple, closed data silos.

Don't get me wrong. I am for true data portability. I'm just not in favor of the way it is currently implemented by the few participating social networks.

What I am proposing is a step beyond data portability that is even more user centric, that could make the Internet a truly open space, that would help usher in the Social Web.

What is Identity on the Web?

Before introducing my concept, it's important to understand a key difference between my views of Web identity and the mainstream definition.

The commonly-accepted definition of a Web identity is a digital representation of a user. It is one of many possible personae that an individual may have on the same social network or among all the networks in which a given person participates. But I believe this definition discounts the individual in the equation.

In my article, Thinking Outside the Privacy Box, I discuss my philosophical views about identity on the Web. In short, what most people call a Web identity is simply an identifier. The true representation of an individual on the Web is what I describe as the set of all their identity graphs.

Enter Identity Flowability

In our service-centric Web-2.0 world of social networks where each new service is in effect a closed data silo, data portability is an important issue. What I'm suggesting is that the next focus of the Social Web should be to obviate the need for data portability.

Instead of data portability, the Social Web needs to champion the concept of Identity Flowability. Identity Flowablility is the easy movement and control by a user over their identity graph.

Identity Flowablility enables a user to store any part of their identity graph in the places that they choose and then allow other sites to reference that data from those places—not copy the data from those places. Data would be semantically marked up to facilitate their auto discoverability for sharing between other sites. Access rights could easily be assigned.

Thus the concept of Identity Flowablility is to provide each user with an easier, more efficient, and effective mechanism with which to control their entire IdentitySpace. It creates a user-centric container through which data content and privacy rights could be better managed and controlled.

How would this concept change the Social Web? Instead of the quantity of users a site has being its most valuable, monetizable asset, the true value proposition of each Web 3.0-enabled company would be the quality and uniqueness of their service. No longer would a large membership base necessarily equal a big asset as smaller, more nimble niche-market players could compete by offer superior services.

Related Articles

Web 3.0: Powering Startups to Become Smartups
Repackaging the Promise of the Social Semantic Web
Regaining Control of Privacy and Identity: It's up to Each Individual
A Flock of Twitters: Decentralized Semantic Microblogging

Release of BuddyPress Privacy Component Pushed Back One Week

Yes, I know. What??? How could you!!! Is this a warped event caused by a rip in the space-time continuum or possibly even triggered by Daylight Savings Time? Is this some sort of a joke?

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 pending the release of BP 1.2.7. Assuming that will happen as detailed in the link above, 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. There are great discounts to be had!

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.

BuddyPress Privacy Offers You the Power of the Force

Okay, that title may not be accurate. But for those advanced BuddyPress administrators and site owners who are performance focused, the BuddyPress Privacy Component will offer the option of creating the ACL (access control list) tables with the InnoDB storage engine instead of the MyISAM storage engine which WordPress and BuddyPress use as the default. This offers a number of advantages such as referential integrity with cascading deletes and updates and row-level locking instead of table-wide locking—which increases performance by facilitating multi-user concurrency, a crucial point on under-powered servers or highly-trafficked sites.

The conventional wisdom that the MyISAM storage engine is always the preferred type is outdated. I will not go into the whys in this article as it is discussed in many places. Here is an article that discusses the benefits of the InnoDB storage engine type in great detail.

Refer to the MySQL documentation for more details on the InnoDB storage engine.

Suffice it to say, that two years ago, the Drupal project decided to make the InnoDB storage engine the default type for Drupal 7 and have not looked back since. You can read more about that decision here.

Use the Force, Luke

To use the InnoDB storage engine type for the BP_Privacy tables, you must manually configure before installing. Details will be provided in the readme.txt file.

InnoDB offers many advantages including one of my favorites as a developer—cascading deletes and updates. To take advantage of this, I've coded dual delete methods within each class model. The method that is fired depends upon which storage engine a given install has chosen. If the InnoDB storage engine is in use, then record deletion is a very simple process as deletes are automatically cascaded down through the child tables. If the default MyISAM storage engine is in use, then multi-table deletes require a more complex looping routine to ensure that associated records are deleted.

Although MySQL allows for the mixing of storage engine types across tables, there are solid reasons for standardizing on one storage engine type across your entire database. It is up to you to decide if you want to mix and match storage engine types and to determine which tables may benefit from one storage engine type versus another.

If you decide to install BP_Privacy using the InnoDB option, then you should consider whether it makes sense to convert all of your existing WordPress and BuddyPress tables to use the InnoDB storage engine. If you are doing a clean install of WordPress and/or BuddyPress, you can set the default storage engine type to the storage engine of your choice for each table before running the install script. Future core upgrades, unfortunately, will then require extra vigilance. So, proceed with extreme caution.

Here are some additional resources to help you better understand the risks, benefits, and issues involved (read the comments in the below articles as well):

How to scale WordPress to half a million blogs and 8,000,000 page views a month

Convert your MySQL database from MyISAM to InnoDB

5 Essential Steps For Hosting A Scalable WordPress Blog Or Website

These Aren't the Droids You're Looking For

To do my part in reducing data bloat, and helping those users that have lower-powered servers, or are on shared hosting, I've structured BP_Privacy's tables to be as compact as possible. How? Well for starters, by using the INT, instead of BIGINT, numeric field type for the tables' primary key fields and by using partial indexing where practical.

The benefit of using the INT numeric field type is that it's a 50% reduction in storage space compared to BIGINT (not a fifty percent reduction in the maximum number of unique possible records within a table, but in the number of bits required to store the data in the ID field of each record in the table). Using the INT numeric field type for the table ID still allows for 4.29 billion unique records within each table. This should be more than adequate for 99.5% (likely even more) of all BuddyPress installs.

Given the fact that these improvements are for a few, small privacy tables, it may not seem like that little of a space savings makes a difference in the grander picture. But imagine if WordPress and BuddyPress core made similar changes and all plugin developers took the time to optimize their plugin's data schema (if they have one). Every bit saved on better field type and index sizes can add up to big performance gains, especially as a WordPress-powered site begins to get noticed and needs to scale.

After all, does WordPress and BuddyPress each really need to use the BIGINT numeric field type for UserID? Is it even realistic to make allowances for the possibility of 18.446 quintillion unique user records? Or, would larger benefits accrue to WordPress and BuddyPress users if the data size for that field was reduced by 50% (by using INT) or even better 62.5% (by using MEDIUMINT). Imagine where else data schema optimization could occur!

A Jedi Uses the Force for Knowledge and Defense, Never for Attack

As this famous quote from Yoda implies, with great power comes great responsibility (how about that for mixing SciFi and comic book metaphors). So, here it goes.

Warning: If attempting anything mentioned in this article or in the linked-to articles, the typical caveats apply: backup your existing WordPress and BuddyPress database(s) before you do anything, know how to restore your database(s) from your backups, know what you are doing and what you're getting yourself into, don't cry if you break something, it is entirely your responsibility to fix anything that breaks, and there is no one you can blame except yourself if something goes wrong.

I will not answer any questions about how to do anything discussed above or in the linked-to articles, nor provide any assistance in helping you do this, nor provide any help if you do this and your site breaks. It is up to you to know what you are doing. Proceed at your own risk. You have been warned.