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

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 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: 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 BuddyPress Privacy Component 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 BuddyPress Privacy Component is ready, I will make it available in the same manner. Only donate if you want to provide development support.

Support Level

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

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

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!

Support Level

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

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

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.