What does this mean for blogging? Is this a bad portent for blogs? Is it wise to use a surrogate platform owned and controlled by a third party for your content creation and sharing platform?

Long-form Versus Short-from Content

Personally, I do not believe that G+ is the proper venue for long-form articles. The thin-columnar design would make it tedious to read posts longer than a few hundred words. It is also not currently possible to place inline graphics within a G+ posts nor “a” tagged referenced HTML links. That makes it impractical to use G+ for the creation and sharing of any long-form content.

As an example, these following major thought pieces of mine would not be practical to post on Google+:

• My five-part Smartup series, Web 3.0: Powering Startups to Become Smartups
• A Flock of Twitters: Decentralized Semantic Microblogging
• Flowing Your Identity Through the Social Web
• The Web is Not (yet) Social
• It’s Time for Blogging to Evolve

The Web of Content Versus Content Islands

Another issue with redirecting a personal URL, a blog for instance, to G+ is that you lose your Google juice. Whereas it might not be a big issue to people like Kevin Rose and Bill Gross who have significant audiences on most (all?) social networks, to a lesser-known entrepreneur such as myself, the loss of PageRank would be a significant blow to my reach.

But there is a more salient issue with redirecting a blog to G+. The draining of your Google juice may not be as bad as the orphaning of all your past content.

With a redirected site, links to your blog posts in old tweets and on other people’s sites would no longer work. This means that people would not have a way to read your past posts and articles. As even some of the largest social-media sites have closed down after awhile, what happens to your content and all your nice, newly minted links if Google decides that G+ is (once again) not the killer app they were hoping for and shuts it down like Google Wave?

But the biggest issue in my opinion is that of giving up control over your content. Although Google+ does have some facility for data portability, as an open source advocate and W3C invited expert on Social Media Federation, I do not relish the idea of giving up control over my content to a 3rd party. The Web-based Internet was created with a grand vision in mind. Concentrating the majority of social activity into a select few social-media nightclubs was not the vision of its founders.

The Web thrives on interconnectedness. If most of the content is created, shared, and discussed on a few social networking islands, then the Web’s potential to become truly social is in jeopardy. In my article Flock of Twitters (linked above), I discuss the difference between the Social Web versus social networks.

Are There Any Upsides?

Those are the downsides to relegating your blog to the back burner. The upside is this. The benefit of social networks over blogs is that an individual can follow many people at once, thus subscribing to numerous content pipes without having to visit numerous, disconnected sites (i.e. blogs). With blogging, each visitor has the option to subscribe to your feed but it is only one feed. That makes it less likely that you’ll have return visitors. RSS is (was?) a fantastic tool, but I have not had any new subscribers to my blog in many, many months.

Perhaps using G+ for shorter-form posts could noticeably increase your reach. It might even motivate people to visit your blog more frequently.

Whereas short-form content may be at home in a venue like G+, I still believe longer-form articles need a better place than G+. But, in the past, I would have posted these thoughts on my blog but instead I have written them in G+ as well. So maybe the times they are a changing.

The Future of Content on the Web

Even if the current trend is toward concentrating content into a few mega silos, the creation and sharing of content will continue to occur in some form and fashion outside of the walled-gardens du jour. Communication paradigms evolve over time, offering new content containers in which to package the same type of content.

For instance, books are still books it’s just that their containers are evolving from ridged one purpose, write once, read many treeware containers, to malleable multi purpose, write many, read many hardware containers. It may be true that what used to be primarily shared via blog posts is now being shared more in the confines of social-media silos, but this will lead to an evolution in the decades-old blogging paradigm.

Whether or not most people are aware of the original intent of the Web’s creators, or for that matter even care, remains to be seen. But as long as there are open source, open Web advocates pushing the boundaries of technology, the prospects for a real Web of Content, a linked Web of Data remain bright.

Note: A short version of these thoughts was original published just on my G+ account. But after thinking about it awhile, I decided to post these thoughts in my blog as well. It is interesting to note that even though I tweeted links to both posts, my G+ post on this topic has received eight comments (not including my replies), whereas this long-form post has so far received zero comments. If engagement is more important than control, then the social media silos will win more converts. It is clear that the current blogging paradigms are quickly becoming outdated. Perhaps this issue will spur innovation in the blogging platforms.

As I began to compose a response to Nova’s query, it soon became clear that I had too much to say for a blog comment and decided that it was more fitting to write an article for my own site and then simply point Nova to it.

The Rights of the Internet and of its Users

If I were to attend the e-G8 Forum, what is the one big question that I think needs to be answered? Simple. Who owns the Internet?

If I were to attend the e-G8 Forum, what big issues would I push? Simple. I would stress two things: Global Internet democracy and Internet user rights.

What do I mean by global Internet democracy?

I’m not talking about a political movement to ensure that all peoples of the world are granted freedoms that those of use who are fortunate to live in real democracies experience—although that is of course vital to our survival as a species. Instead, I’m talking about the Internet being granted its own rights and freedoms—freedoms to grow, to prosper, to evolve unencumbered by corporate or governmental red tape as if it were its own emerging metaphysical entity.

The Internet has become our global data ecosystem. It is an evolutionary force in the speciation of humanities’ communication and computation infrastructure. As a result of the ease with which data of all types flows around the global, and with the increasing connections made to this data on a daily basis, our species is on the verge of seismic and profound changes.

In just a few decades, the Internet has grown like a developing nervous system, transcending national boundaries, shrinking geographic distances, dissolving geopolitical barriers, and binding many of us together into a single, global network. If allowed to continue its course unshackled by shortsighted power players, then it may become humankind’s most powerful, liberating, unifying, and transformational force.

What do I mean by Internet user rights?

With the recent net neutrality setbacks, discussions of the United States creating its own Internet kill switch, and the Commerce Department’s National ID initiative, informed netizens are right to be concerned about the future of their Internet freedoms.

In a free society, we should strive toward letting individuals, not governments or corporations, be in control of their personal data—an issue made painfully clear by the lack of real data portability among the Web-2.0-styled closed social nightclubs. We should advocate for the Internet rights of user-centric identity control, data ownership, and net equality for our data packets. These should be considered sacrosanct rights for all the Earth’s netizens.

There are a few promising projects in the works that address these issues. For example, the Freedom Box Project is working to create small, cheap, open-sourced personal servers that will return “power to the users over their networks and machines, returning the Internet to its intended peer-to-peer architecture”; the Diaspora Project offers users a distributed version of a Facebook-like social network; and the WebID protocol is creating an open distributed identity standard. These projects, and others in this space, need to be nurtured and given the liberty to proceed without regulation.

Collective and Connective Intelligence versus Myopic Dissonance

In my article, The HyperWeb: it’s All About Connections, I make an important point about the dangerous possibility that the Internet’s full potential might be purposely curtailed as a result of the myopic desires of a few power players:

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

The emergence of a truly Social Web will require not only policies that guarantee and protect the Internet’s freedom to grow, but also an informed netizenry that fights for its rights and freedoms. To date, neither of these prerequisites have been met.

The key message to communicate to the G8 leaders is that the world is struggling to become a global community and that a healthy, unfettered Internet may be our best insurance policy toward bringing that vision to fruition.

It is crucial that governments and corporations establish programs and invest in infrastructure that enable and ensure distributed services from identity, to micropayments, to unfettered mesh networks. It is critical that governments propose policies and enact laws that ensure user-centric ownership and control of personally-created and contributed data.

Let the people’s voices and data be freely heard and transmitted across the Internet. Let no one nation or corporation put up barriers to the Internet’s evolution no matter what the consequences may be to outdated notions of sovereignty.

Who should own the Internet? No corporation, no government, no organization, no individual. Instead, like the Earth, it should own itself.

My Related Articles

1. How the Death of Net Neutrality Effects You
2. Goodbye Google Old Friend: It’s time for the Open-Source Internet
3. Thinking Outside the Privacy Box
4. Regaining Control of Privacy and Identity: It’s up to Each Individual

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!

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.

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?

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.

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.

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.

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 of and control over a given identity graph by a given user.

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.

WebIDs could become the cornerstone in the user-centric Social Web.

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 offering superior services.

WebID: Helping to Flow and Control Identity

There is a very promising identification protocol that goes a long way toward creating the foundation of a flowable identity. It’s called WebID—in particular, a FOAF+SSL WebID. If you are interested in identity flowability, I encouraged you to learn more about WebIDs and how they could become the cornerstone in the user-centric Social Web.

My Related Articles

1. The Web is Not (yet) Social
2. Thinking Outside the Privacy Box
3. Web 3.0: Powering Startups to Become Smartups
4. Repackaging the Promise of the Social Semantic Web
5. Regaining Control of Privacy and Identity: It’s up to Each Individual
6. A Flock of Twitters: Decentralized Semantic Microblogging

Also See

An interesting six-minute video presentation graphically discussing the issues with OpenID: OpenID: Identity Service or Identity Platform

For an interesting, possible alternative to today’s closed-siloed Web, visit the Consortium for Local Ownership and Use of Data. Their task is challenging but in tune with my sentiment expressed above.

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.

To celebrate this occasion, I am offering two specials: 40% off of the standard BuddyPress Privacy Component Support Plan (BPCSP) and the other 25% discount on advertising rates. All but two of the first month’s ad spots are sold. So, if you want to get in early and lock in these prerelease rates, act now.

There is new research out that indicates that teenagers are starting to look for alternatives to Facebook for their social-networking needs. Some of the stated reasons (besides fatigue) are that they’re fed up with advertising inundation and insufficient privacy controls. When it comes to Facebook’s privacy controls, many teens find them hard to use, difficult to understand, and believe that Facebook will likely change them again.

The result? As users become overwhelmed and burnt out by the one–size–fits–all social networking monoliths, they are beginning to seek out more intimate, interest-specific communities. This provides an opening to developers who wish to create narrowly-focused, niche networks. BuddyPress is a great tool that can allow you to do just that.

With BuddyPress fast approaching its version 1.3 release (around the new year), now is the perfect time for those who have been thinking about creating a targeted community to learn how BuddyPress can help achieve that goal. A well–executed BuddyPress site could offer potential members a more meaningful, productive experience than simply joining another Facebook group.

As an open source project, BuddyPress thrives as a result of its community. If you are a designer, developer, or site owner, please consider joining the community and helping to evolve BuddyPress into a strong alternative to the traditional social-networking platforms. New ideas, energy, and contributions are always welcome.

Important Message

If you’re currently running a niche social network, or thinking about creating one, you should be aware of a possible threat on the horizon. It is up to the Web’s netizens to fight for equal access and data equality.

Update

December 15, 2010: Also, see my article Leverage BuddyPress to Build Your Niche Community posted on buddydress.com.

September 2, 2010: If you don’t think that BuddyPress or niche social networking is growing in popularity, see this article.

Personal freedoms, control over one’s privacy, and the ability to manage one’s identity on the Web have never been in more jeopardy. With Facebook’s continued war on personal privacy, the day when a user no longer has any rights to control their own data is closer at hand. The question is, How should society respond?

Of course, Facebook–or any other corporation–is free to offer services and manage their user base in anyway that benefits their stakeholders—as long as they do not break the laws under which they are obligated to operate. Individuals have the freedom to decide whether or not they agree with Facebook’s policies, in particular as they pertain to privacy and the use of their personal data. They can choose not to use Facebook, Twitter, or any other Social Web network.

I have no issue with corporations making a profit, I am a businessman myself. My argument is that society should not feel comfortable when a few individuals (or in this case a single person) make broad, sweeping decisions about how an individual’s data is managed.

Society should not be complacent or apathetic when a large corporation like Facebook continues to assail personal privacy on one front while purporting to be the de facto provider of Web-based identity on the other. Free societies should strive toward assisting individuals to gain control over their personal data.

Currently, there are inherent barriers to providing users with an easy-to-use mechanism that grants fine, granular control over personal data on the Internet and Web. Most users have their personal data strewn throughout myriad, disparate data silos, across different closed social networks. This makes it difficult to create tools that offer users an efficient and effective way to manage their data, to manage their on-line identity.

Some of the initiatives that open a user’s data up to other applications and networks–the Open Stack, for instance–begin to address this issue. But, as long as users’ personal data remains effectively siloed in government and corporate databases, this vision will not be obtainable.

As the Web matures and new technologies such as Semantic Web protocols and tools become available, solutions to the proverbial Privacy 2.0 and Identity 2.0 debate are possible. Whether corporate adoption rates of those solutions will be sufficient to make them viable is unclear. This is were the wishes and desires of a free society come into play. If there is a sufficient cry to adopt new identity-management protocols, then perhaps we can effect change.

In my article, “A Flock of Twitters: Decentralized Semantic Microblogging”, I offer one such path to a user-driven, user-centric identity management and privacy solution. It does not rely on corporate adoption but instead puts the power back in the hands of individuals.

But there are other solutions that offer great business opportunities to companies that truly listen to users’ concerns over the usurpation of their personal privacy and identity. In the coming decade, those companies that build new interfaces and provide new services that facilitate user-centric identity and privacy management will find their visions rewarded. There is plenty of room for both open source and proprietary solutions in this space.

Whereas Facebook has shown great acumen at growing their small business into a global behemoth, it has lost sight as to the roots of its success—their users’ trust. If the Web’s citizens take a stand and demand that their personal privacy and identity remain their domain, and not the domain of corporations or governments, then companies like Facebook could very well end up being a relic of a Wild-west Web, a bygone time where anything and everything was acceptable in the name of profit.

It is up to society, to the Web’s citizens, to decide how the issue of privacy and identity will turn out. If only a few voice their opinions, if only a few are cognizant of this crisis and its negative ramifications, then Facebook and other corporations will decide how privacy and identity are managed.

If you think privacy and identity are too important to let the few decide how they are managed, then it’s time for you to act. Write about it on your blog, tweet about it, retweet my article, do whatever it takes to get those who trust you in your various social networks to take note, to listen, to understand, and to ultimately act.

UPDATE: April 20, 2011: With Facebook being credited with facilitating the Middle East uprisings and their desires to move in to China, it appears that they may be bowing to pressure to curb free speech in certain parts of the world.

UPDATE: May 8, 2010: Jeff Jarvis published an interesting article on this topic. See Confusing *a* public with *the* public.

During the chat, Andy Peatling (lead BP developer and Automattic employee), presented an idea about breaking up development work into component teams:

I’d like to start breaking BP down into chunks, and find people that are really interested in specific features…so for example if you really love the activity stream functionality you could focus specifically on that, and stick to patching just this area…so the long term goal is to get teams on components and have that transition into core commit teams.

This has merit. As the complexity of the BuddyPress codebase expands, it will be increasingly difficult for a one- or two-person team to do all the core lifting. BuddyPress is a complex suite of plugins. It is a social-network-creating ecosystem full of hundreds of functions and classes. Breaking the workload into project teams is a sensible approach.

More Hands to Watch

But, this notion of modularizing BuddyPress core development made me realize that a single guy–that would be me–cannot effectively continue to maintain and update the BuddyPress Privacy Component. It is impractical.

As you already may know from my very successful fundraising drive for my BuddyPress Privacy Component, keeping the BP Privacy plugin up to snuff with each new release of BP is quite challenging. In effect, I have to be an expert on all the BuddyPress components.

If there will be project teams managing the future development of the BuddyPress suite of components, that means two things: 1) there will be too much information created by too many hands on which I need to stay caught up; 2.) there’s an opportunity to streamline privacy filtering.

Enter the BuddyPress Privacy API

Privacy should be a core feature of any social network. BuddyPress is no exception to this rule. So, I’m now thinking that the best approach to privacy in BuddyPress is via a Privacy Layer that provides a basic Privacy API which any and all components can access.

I’m now investigating how practical and possible it will be to create a Privacy Layer using my current privacy codebase. If it is something that can successfully be created without a significant amount of additional work, I will switch my efforts toward creating the BP Privacy Layer.

This means, that going forward, it will be up to each BuddyPress component development team to utilize the Privacy Layer (if they choose to), to tie their component into the Privacy API, and provide privacy filtering. That way, providing privacy will become a team effort and not just one guy playing catch up, running behind Andy, jjj, and all the component-team members who are furiously evolving the BuddyPress codebase.

Do you think a BuddyPress Privacy Layer is the best way to ensure that privacy becomes a core element of each component? Do you think a BuddyPress Privacy API is a desirable feature?

Here’s why I ask. Over the past several years, whenever Facebook has made a change to its privacy policies, it has caused great uproar—not only with civil liberties advocates (as you would expect), but also with Facebook’s user base.

The recent brute-force change to the privacy settings of all 350 million of its users is just the latest in a series of moves that exposes more of Facebook’s users’ information.

According to the above linked article, here’s what Zuckerberg said about the recent change:

Doing a privacy change for 350 million users is not the kind of thing that a lot of companies would do. But we viewed that as a really important thing, to always keep a beginner’s mind and what would we do if we were starting the company now and we decided that these would be the social norms now and we just went for it.

That last statement, “we decided that these would be the social norms,” is the telling truth. It is not that lack of privacy has become a social norm. It is that Facebook believes that it should be.

It is as if Facebook issued a decree to its global citizens. Privacy is no longer something you should request. Privacy is not in the best interests of our society (as in Facebook’s “society” or corporate mission).

Exposing more of its users’ data to the world is, of course, attractive to Facebook’s business alliances. It offers a number of new opportunities for profit. To a company rumored to be heading toward an IPO in 2010, new revenue streams and growing profits are a good thing.

But open data and opening up of personal data are two different issues. What pieces of your data should be open? Where do we draw the line? In general, as long as they are not breaking any laws, I believe it should be up to individuals to decide which pieces of their personal data are made public.

In a free society, we should strive toward letting individuals, not governments or corporations, be in control of their personal data. Collectively society should “own” the data with individuals given control over a subset of their personal data.

There are compelling reasons why opening up personal data to the world is desirable. But it should not be up to governments or corporations to make that choice on behalf of their citizens and users. In a free society, it should be the citizens who drive the push toward more open data, not a few elite power players who force the issue.

What do you think? Is Facebook engineering the expectation of lack of privacy? Are they forcing the issue and making it become a social norm by brute force? Is this truly what their users want? What rights should individuals have to control their personal data?

UPDATE February 24, 2010: See my article A Flock of Twitters: Decentralized Semantic Microblogging to see how users can take control of their own on-line communication streams.

UPDATE March 19, 2010: As this year’s keynote speaker at South by SouthWest Interactive (SXSWi), Danah Boyd presented a very thought-provoking keynote presentation on privacy in social media: Making Sense of Privacy and Publicity.

UPDATE May 2, 2010: The Electronic Frontier Foundation recently published a very illuminating article on this topic, Facebook’s Eroding Privacy Policy: A Timeline.

UPDATE May 8, 2010: An interesting graphic depicting what I call the devolution of Facebook privacy.

In a recent post, I asked for ideas on how WordPress ecosytem developers can earn a living doing what they love to do—coding great-quality plugins for WordPress, BuddyPress, and bbPress. This post is my attempt to try the time–honored (but more than likely ineffective) request–for–donation approach for my BuddyPress Privacy Component.

Please Note: The new BuddyPress Privacy Component which will work with BP 1.2.7 is not yet available. The below PayPal button is for donation to support development. It is not a paywall that provides access to a download link for the Privacy Component. All of my WordPress and BuddyPress plugins to date are GPLed and are freely available on the WordPress Plugin Repository. Once the updated-version of the BuddyPress Privacy Component is ready, I will make it available in the same manner. Only donate if you want to provide development support.

But, I’m going to go about this in a slightly different way. This approach is a serious attempt at doing things differently. I hope it does not provoke the ire of my readers.

How is my approach going to be different? Well, I’m going to be upfront and honest about the time commitment on my part to code, update, and support my BuddyPress Privacy Component. Then, I’m going to appeal to your sensibilities. If that doesn’t work, I’m then going to leverage your needs!

Please click the first link above and read that, if you have not already. Then, come back to this post and continue reading.

First a Caveat

Please be advised that the approach I’m about to detail will be controversial. This is my attempt at one possible solution to the question posed in the first link above. It is an experiment at best.

Do I think that this approach will be warmly received? No. Do I think that it will be successful? No.

But perhaps it will stir up healthy conversation and some tangible solutions.

The Ever-Changing BuddyPress Landscape

BuddyPress version 1.2 is fast approaching its public release. However, the underlying codebase has undergone major code refactoring and even significant changes in functionality. So much has changed that it will require a significant amount of time to refactor my Privacy Component codebase to function properly in the newly-overhauled BP platform.

I’m not complaining about the changes. I’m just stating a fact. I believe that BP version 1.2 will be superior to previous versions.

I’ve had discussions with a few other BuddyPress plugin developers who wonder if we’ll see similar codebase changes in future versions of the BuddyPress platform. At this stage, we have to assume that this is a real possibility. Therefore, it is only wise to plan accordingly, to assume that with each major new release, that parts of our plugins may require significant TLC. But again, when the dust settles, version 1.3 of BuddyPress will be superior to previous versions.

It’s Just Time, Right?

I currently estimate that it will take at least 30 to 40 hours of code refactoring and functional code changes to bring the current version of my BuddyPress Privacy Component up to working order for BP v1.2. Of course, not all of this time is for coding. A noticeable amount of this time is studying the changes to the BP codebase and figuring out how key object arrays, actions, and filters have changed. When version 1.3 comes out later this year, it may require a similar amount of effort. This estimate does not even take into account the incremental versions (1.2.x, 1.3.x) that could require fixes here and there. But, leaving the incremental version changes out of the equation, I estimate that this phase of the project will require between 60 and 80 hours of work in 2010.

Along with updating the plugin, support is another time sponge. I estimate that once my plugin hits the mainstream, that I could be looking at at least 5-10 hours a week for support requests during the first two weeks of a version release and then 10 hours a month until the next version is released. With two major BP privacy plugin versions assumed to be released in 2010, that equates to an estimated total of 100-140 support hours in 2010.

Finally, there is at least one big, missing piece of the privacy puzzle—group privacy filtering. Until development of BP v1.2 is frozen, I will not be able to provide an accurate estimate of how many hours it will take to code a full-featured suite of group privacy filters. But, I do know that there is talk of possible, significant changes to the groups component in version 1.3. So, once again, this is my best guesstimate. I’m assuming roughly 80 hours of coding to bring to fruition group privacy filtering.

What does this all add up to? The total estimated time required in 2010 to upgrade, maintain, augment, and support my BuddyPress Privacy Component is 240-300 hours. At my standard, weekly work schedule, that is roughly 4 weeks of my time!

This is more than likely an underestimate of the amount of time that will be required, but I’m using that figure to help me determine a realistic financial support request. Also, it does not include the hundreds of hours already invested in the current version.

An Appeal to Your Sensibilities

Now, of course I cannot possibly donate four weeks of my time on this plugin or any of my other not–yet–released BuddyPress plugins. Can you donate four weeks of your time for anything? Would you give up your vacation time (and then some) to provide free software programming and consulting services?

My goal is to recoup some of the time I’ve already put into developing this plugin, to fund the current and future upgrades and enhancements to this plugin over the course of this year, and to cover some of the support time I will inevitably be requested to provide.

Supporting Development, Developing Support

How is my donate button different than others? Well, it is not a donate button. It is a support this project button. It’s a request for action, an opportunity for you to show your support by buying into the project. If there is not sufficient support, then the project will be discontinued.

Without sufficient financial support, I cannot continue to develop this, or any other plugin. I need to have a reasonable cash flow. I have to contribute to the support of my family.

Based on my above estimates of the number of hours that I will be required to put into my BuddyPress Privacy Component in 2010, I’ve set a goal of $9,000. That adds up to an hourly rate of between $30 and $37.50. This, in itself, is a greatly reduced hourly rate from my previous consulting days. That is okay. I’ll consider the difference as my continued donation to the cause.

What Happens in 2011?

This request for financial support is only for 2010. So, you rightfully may ask, what will happen when 2011 rolls around?

By then, privacy in some form or other should be a core BuddyPress component. It will thus be maintained by the core development team—and I’d be willing to help them maintain it as well.

Of course, it’s possible (but I think unlikely), that privacy will become a core feature of BuddyPress this year. If it does, I very much doubt that it will be the fined grained, fully-featured privacy suite that I offer in my plugin. But Andy and JJJ are very clever guys. So, you never know!

What Happens if You Don’t Raise the Entire Amount?

Since PayPal allows for refunds to be sent within 60 days of receiving a payment, I plan to hold all proceeds in my PayPal account. In 58 days from the date on this post, I will assess the results. If the goal has not been met, I will decide if I’m willing (and able) to provide the entire year’s worth of work discussed above for the amount raised. If I decide to proceed, I’ll withdraw the funds from my PayPal account. If I decide not to proceed, I’ll issue a refund through PayPal.

So, on Monday, March 1, 2010, the final decision will be made.

BuddyPress Privacy and BP Version 1.2

Just to allay any fears, I have already committed to bringing my privacy component up to code to work under BuddyPress version 1.2. That will happen no matter how this little experiment turns out. The real issue is what happens from that point.

Wait, Open Source is Supposed to be Free

Most people expect software to be free these days, especially with Open Source projects. But the spirit of Open Source is not providing free (as in no cost) software. It is in providing freedoms in how you use the software. These two pages on Gnu’s website–the maintainers of the GNU GPL license which WordPress is licensed under–explain it very well:

• Selling Free Software
• The Free Software Definition

So, although it is customary in the WordPress ecosystem for plugin developers to offer their work for no cost, it is not what is intended by the GPL, it is not what Open Source is truly about.

Has the misguided assumption about free (as in cost) software become too ingrained in our community? Whereas designers who offer GPLed–premium themes seem to be accepted into the community without issue, developers who offer GPLed–premium plugins are often treated differently. There should not be a double standard. Both designers and developers should have the right to earn a living from providing great-quality free software.

My Plugins will Always Be Free

I believe in the free software movement, in the spirit of open source. I will always freely provide my plugins to the greater community. I’m truly not looking to sell my code. I am just looking for an acceptable vehicle (besides the consulting route) that provides some financial support so that I can continue offering high-quality (I hope!) plugins.

An Appeal to Your Needs

Now, I’m in no way intending to hold the BuddyPress community hostage. I’m trying to see if this idea will work.

Is privacy something that you think is important in BuddyPress? Is privacy filtering for your members’ data something that you need for your BuddyPress-based community?

If you have read this far, and have not unfriended me over at BP.org or unfollowed me on Twitter, then I am amazed! Actually, it does not surprise me. I assume that you agree that Privacy is of paramount import in BuddyPress, in any social network.

If privacy is something you value in BuddyPress, then I ask that you please help support my efforts. Tweet about this post (you can use the Tweet This! button on top), blog about my post, draw attention to my efforts in other ways, and finally, put a few dollars into the project’s coffers. I’ll then do all the heavy lifting!

Thank you!

The bar chart below and at top will update as support rolls in. The question is, will it roll in at all? If not, what are my options?

After learning the rudimentary workings of OAuth, it quickly became clear that it did not offer a mechanism for internal access control, nor was it even intended to be used as an authorization protocol. I’ll discuss this last statement in more detail later.

So, to educate my fellow social media gurus, I decided it would be helpful to jot down what I learned and determined about OAuth, its intended use in any social media application like BuddyPress, and how privacy control needs to be implemented within BuddyPress.

What is OAuth?

From the OAuth Core 1.0 Specifications:

The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from a web service (Service Provider) via an API, without requiring Users to disclose their Service Provider credentials to the Consumers. More generally, OAuth creates a freely-implementable and generic methodology for API authentication.

Therefore, OAuth is a set of rules and procedures that facilitate the exchange of data between websites without the requesting website requiring the user to provide his or her sensitive authentication credentials. This enables a greater level of security for all users.

Imagine if you had to provide your Twitter credentials (username and password) when installing the Twitter Facebook Application in your Facebook profile. Fortunately, Twitter now uses the OAuth protocol so your password does not need to be provided to and stored by Facebook. Instead, a token with defined rights is created and used by the Twitter Facebook Application to gain access to your Twitter data.

How Privacy Needs to be Implemented in BuddyPress

Whereas OAuth can provide access control to a user’s private data, or any URL with a need for access restrictions, it does so only between sites. OAuth is not a protocol used for internal access control; it is not an internal authorization protocol.

(Visit this post to learn more about Authentication Versus Authorization)

Again, from the OAuth Core 1.0 specification:

It is important to understand that security and privacy are not guaranteed by the protocol. In fact, OAuth by itself provides no privacy at all and depends on other protocols to accomplish that.

Therefore, BuddyPress requires its own internal privacy protocol. Enter, BPAz, my BuddyPress Privacy Component

BPAz is a necessary protocol for providing privacy to all BuddyPress users’ personal data. Once a given user’s data is sufficiently controlled by their BPAz access control list (ACL), they can feel more confident in exposing any data they wish to share across the Web.

BPAz is internal to a given BuddyPress install. It provides the mechanism whereby a give authenticated user can establish access rights—via an ACL—to their internal objects. The focus is on allowing users to have fine-grained control over their personal data. OAuth, on the other hand, is a protocol that facilitates the cross-site sharing of user content.

With BPAz, users can compartmentalize their data, to decide which pieces can be shared and with whom. OAuth can then generate tokens based on a given user’s ACL that allow clearly defined access rights to users in outside networks. Without the privacy filtering of BPAz, OAuth tokens would be very broad in scope, potentially allowing access to all of a user’s data with a single token.

Now, it is not as simple as installing my Privacy Component and suddenly your BuddyPress site is ready to safely communicate your users’ data to the outside world via OAuth. WPMU and BuddyPress first need to properly communicate with OAuth. This is on the roadmap for a future version. Once that happens, I will take a look at the code and figure out what, if any, I need to alter in my Privacy Component to properly communicate with OAuth.

So, the take home message is this. Authentication within BuddyPress is currently handled by a few internal core WPMU scripts. Authorization, however, is not yet a core feature of BuddyPress. My Privacy Component is an important first step in molding BuddyPress into a platform that can safely and effectively interact with other social media sites.