Skip to:

The BuddyPress next generation API, the journey begins

  • MrMaz


    (Non-programmers feel free to skip to the last paragraph for an assignment that anyone can help with.)

    Improving, refactoring, and extending the BuddyPress API is going to be a long journey for sure. In fact, it will probably never end, but hopefully it will become much easier and more enjoyable to work with.

    From my viewpoint, BuddyPress is at a major crossroads. The current API has reached its maximum capacity to be extended, while at the same time the demand for plugins is eclipsing itself on what seems like a weekly basis. The goal is to get ahead of the curve and open up BuddyPress plugin development to a new generation of developers.

    Before I get into any details, I want to be clear about the parameters of the refactoring.

    1. Maintain low barrier to entry for developers (and probably lower it).

    2. Maintain backwards compatibility (within reason).

    3. All decisions in regards to the next generation API will be open to public discussion.

    The major goals of the refactoring are listed below in no particular order.

    1. Solve long standing major issues that have been identified as API limitations.

    2. Eliminate duplicate functionality that exists in multiple components and plugins.

    3. Add missing core functionality that is deemed to be of a high value to the BuddyPress community and to plugin developers.

    4. Make extending BuddyPress easier.

    5. Improve API documentation.

    Ok, so How do we do it?

    BuddyPress has always been developed using the iterative model. Variations of that model are the most popular and arguably the most successful for open source software development, so I don’t see any reason to change. I happen to be a fan of iterative development, so I am biased, but this is open for discussion. Even though it is a bit late to start from scratch :), I still want to use prototyping at least during the first few iterations of the next generation API so we can hopefully detect major flaws before they become too widespread and embedded in the codebase.

    The stages of the iterative model.

    1. Analysis

    2. Design

    3. Coding

    4. Testing

    5. Maintenance

    These should be repeated for each iteration (or sub-iteration) of development. They should be applied any time there is a problem to solve, and each step should be made public with a reasonable amount of time given for public discussion before moving on to the next step.

    And so we are at step one, Analysis. I don’t think analyzing BuddyPress is a one, two, or even 10 step process. There is a lot of work to get done, and it feels overwhelming, so lets start with one very simple question. Before we can do anything, we have to all generally agree on one thing.

    What is BuddyPress?

Viewing 25 replies - 1 through 25 (of 50 total)
  • A tool based on WP code that enables and facilitates establishing an environment where people with common interests can share information ?

    And extendable to one’s will, may I add…(if you know PHP, CSS, XHTML, coding and hacking of course…)



    a community shell

    Very nice, this is a great conversation starter.

    In one sentence I would describe BuddyPress as: “Social networking in a box. An easy way to start your own niche social network”.

    Lots of other social network tools try to define themselves as a do-it-all platforms that can be manipulated in all manner of ways, but then they don’t work so well out of the box or without some extensive configuration. Even though BP is also highly extensible, I’ve always thought the primary focus should be providing something that the non-techies can work with without much time investment. This is pretty much the same philosophy as WordPress.

    Andrea Rennick


    I’d like to stop making comparisons to Facebook. (yes, mea culpa ;P)

    It can be bigger (or smaller as in tight-knit)

    it can be better

    It can be *different*

    than Facebook.

    I don’t think we’re looking for a facebook clone of any sort. Not long term.

    Boone Gorges


    Thanks for starting the conversation, MrMaz.

    I want to see BP more as a framework for social tools rather than the end-all-be-all for social networking. Like WP itself, the real power of BP is in its extensibility. (Which is what makes the conversation about the API all the more important.)

    It seems to me that throughout the development of BP, there have been two directions of movement: one is to consolidate functionality (as with the recent rolling of some blog related tracking into the activity stream) and the other is to add functionality. The two aren’t inherently at odds, but they do have a tendency to fight against one another. For ease of development, solidity of platform, etc, my tendency would be to err in favor of consolidation. The discussion that was floated a few months ago about moving more kinds of content creation into the activity stream is one example of this. I’m not really 1337 enough to say what this means from the point of view of scalability, but I can say that having fewer points of input/output make third-party plugin development a lot easier.

    So, I were to think of the BP toolkit as a swiss army knife, I would want BP to be the handle and maybe the big blade or two. Corkscrews, nail clippers, can openers and stuff like that are cool, but they should be options.



    I think that in some ways the question ‘what is BuddyPress’ jumps the gun at this stage. The question might rather be phrased ‘what could BuddyPress become once we’ve rewritten the core and API’? My guess is that BuddyPress will grow organically in ways that we cannot possibly foresee at this juncture. That’s the one of the strengths of Open Source projects.

    Is it too late to start this process? Nah mate! Look at some other Open Source projects – Gallery photo album is on it’s second rewrite. Elgg developers not only rewrote the core/API they made the 1.0 totally incompatible with previous beta versions thus leaving a whole bunch of implementors high and dry (which is why I’m moving to BP)! My question is more, who is going to lead this process — you, Mr Maz? — and what role will Automattic have?

    One issue that might be addressed in the core is your philosophy with regard to access controls. One of the built-in features of Elgg 0.9 which I found superficially attractive was the ability to set an access control on any object — blog post, file upload (but not comment) — and to add arbitrary access controls at the user level. However, in practice this often didn’t work out very well. Members of a closed Community blog had to remember to apply ‘community only access’ to each post that they made, they would frequently forget and thus expose content unintentionally. But I do think that looking at this example, and also how Mahara handles it’s file and blog access can help inform the sorts of access features we would like to see exposed by the API.

    What might BuddyPress become? With flexible group and access control features it could become a premier eportfolio solution for example. Just my 2 penneth ………



    But will it melt our heads?



    Social networking really should be about the people, so all BuddyPress should do is deliver the basics that are needed to build a community. That would basically be all the various components that we already have. Because of legal restrictions in a lot of countries I’d only add a privacy component to the core. Any other feature would be better implemented as a plugin. We could even have canonical plugins, just like WP. Keep the core as lean and mean as possible…



    @markpea makes a good point about the wording of the question. Don’t be afraid to comment on where you see BuddyPress going from your perspective.

    As far as who is going to lead the process, I was brought on as a core developer primarily to make contributions to the API. The software is a community project however, so I am not going to do any leading. I am going to make contributions in the hopes that they are widely approved of and accepted by the community.



    A tool to start your own social niche network.

    A niche could be everything and buddypress should be easy to customize and expand so it could adopt to all of this demands. Thats why i like that Andy decided to get MrMaz on board. He knows where the limits of the actual API are because Buddypress Links pushed it to the limits.

    I guess a crucial point could be to identify the “missing core functionality that is deemed to be of a high value to the BuddyPress community and to plugin developers”.

    There could be a public poll, but at the end the developers should identify what is most important … they have more knowledge and a better foresight as a common user like me.

    I guess good privacy and access control will be something to look at with highest priority.



    Wow ! The” what” and the “how” the same day on the same forum: the hazards of life ?



    Buddypress is the tool that I use to bring friends and friends of friends together.

    The emphasis of my community is primarily blogging. It’s for the people who’ve never had a Facebook account…. and for the people who use Facebook, Twitter, Buzz and more. So for us Buddypress is the superglue that pulls WPMU (soon to be WPMS) together.



    buddypress > Facebook

    i’d like to see the whole activity stream become a bit more robust – generic in use but more powerful api options

    – access control (who, what – can update, read am AS record – fine granular framework from users, groups, plugins, component, types) – right now its a bit clunky to remove certain items and no way to block others (ie, i like a plugin’s functionality but i don’t care for the activity record, i want to block certain groups from updates, or block certain activity types to be displayed, etc)

    this one may be outside the criteria but the whole bbpress <-> bp thing. IMHO – ramp up the AS to handle forum content. (already have commenting, threading, etc – i don’t see importance of bbpress hiding under the covers, even if it will become a wp plugin. so much duplicate functionality being used and another layer of dependencies)

    BP => like Firefox and Burger King – I love extensibility and having it my way. :-P



    @21cdb “at the end the developers should identify what is most important … they have more knowledge and a better foresight as a common user like me.”

    Yep. Agreed. And Activity stream control & manipulation — double plus good. But I wonder whether biting off bbpress at the same time would just be too much?

    Eric Marden


    BuddyPress is the sum of its parts, and taking a systematic, and uncoupled approach to the API will aide in seeing this come true. The current options allow you to pick/choose which features you want, but many of these features are tightly coupled with each other. This is reflected in the current code, since BP started life as a ‘social network’ plugin. But until you strip away the dependencies, and allow all of the content to be displayed in anyway the developer can think of, and you’ll have your “different”, until then, we’ve got a hackable facebook in a box.

    Make the data rich, and the getters/setters easy to work with and let us handle the rest.


    Buddypress is the people based framework that you integrate into projects to solve user needs that a regular content management system doesn’t address off the shelf. It’s the layer thats based on people, not posts or pages. This is what I will rely on it for – a standard way to incorporate user accounts, profiles, person to person interactions, commenting, collaboration, and all the things that have to do with people and how they connect with other people, content, tools, and the management of their identity on a site or ideally across any other buddypress enabled site – a unified people plaftorm. I see people/users as the most indivisible core element of buddypress from which everything else builds upon and attaches to.



    I’m with Andy when he says, “Social networking in a box. An easy way to start your own niche social network.”

    I remember him essentially saying this when BuddyPress was first added to WordPress and it’s why I came to use BuddyPress myself. Glad to see the vision has stayed the same.

    What I do think we need to be careful of is how we define social network. Certainly we can use what’s been learned from Facebook and the like, but the open framework and API should allow for creativity beyond the Facebook definition of social network.



    “Social Networking in a Box”

    3. Add missing core functionality that is deemed to be of a high value to the BuddyPress community and to plugin developers.

    I agree with this but would not one to be locked into a specific media capabilities like pics and videos. Creating core functions that devs can plug in to yes but to not say “this is the only media capability you get, deal”.




    I definitely am thinking along the same lines as you when it comes to reducing the amount of coupling between components. Over time I would like to see a shift where components are only interacting with each other’s APIs or through the core API, instead of so much overlap. I think a lot of this will happen naturally as we refactor out the duplicate functionality and move it higher up the chain. I am a huge fan of “coding to an interface.” This is a challenge while having to support PHP4, but I think we can still make large strides towards a decoupled approach.

    Thanks for all of the comments everyone! Keep them coming.



    Great thread, Mr Maz.

    For my part, I am very very leery of the phrase of the moment, ‘social networking’. It’s a buzzphrase, and even when it’s used specifically and accurately, it makes me want to punch throats, a little bit, because it doesn’t mean much when you dig right into it, and to me, it evokes cheesy cheap-suited salesman making currency of faux friendship.

    But I’m kinda old skool that way. ;-)

    For those of us — most, probably — who’ve been working or at least dabbling in the data for decades, we’ve seen dozens of bandwagons boarded and polluted and just as quickly disembarked and abandoned when the next thing came along. The avalanche of ‘social networking gurus’ and all the rest will fade in time, too.

    For me, the real thing at the highest handwavy level is ‘community’ and more specifically, community on the web. Tools and toolsets and platforms and apps and APIs and all the loosely- and tightly-coupled stuff that enables people who share some set of interests, no matter how specific or broad, to get together and interact and form communities, with all the real-world parallels but also all the special because-it’s-on-the-internet factors rolled in.

    This means a couple of things, and again, talking at a much higher level than the technical here — it means that the platform itself disappears for the user after they become accustomed to it. That it’s designed in terms of interface and functionality to not only provide the features users want, even if they don’t know it, but also to be as invisible as possible as they use it.

    It also means that the platform has to have a robust set of tools for the administrator and moderators of the community (because these things are necessary, to some extent, in community on the web) to use a light hand in keeping the community on an even keel.

    I think web community, more perhaps for people who are not so much of the disposable, in-the-moment, ritalin-riddled, post-it-and-forget it generation, needs to have feet solidly planted in not only the ongoing ephemeral stream of conversation, but also in a more long-term, permanent ‘space’ of shared history, shared interactions that are performed in public and can be gone back to, interactions that more than any set of xprofile fields or avatars build a mutual understanding between users based on personality and past discussion. Build, in other words, community.

    This last is why I keep mentioning how important I believe the forum component of Buddypress to be, and why I’ve spent the bulk of my time on my current not-yet-launched BP site for an existing community trying to beef it up (with the help of some of the excellent plugins that people have been releasing).

    ‘Social networking’ doesn’t excite me. Communities of people from all over the place, communities that can only exist because they are on the internet, that’s what excites me. Buddypress, to me, is a toolset for building communities on the web. It may be a distinction without a difference for many, but I think it’s an important one.

    OK, enough handwaving.



    What is BuddyPress?

    An open source script for blog-centric private social networks.

    Potentially a next-generation social network, starting from the best elements of Facebook and Twitter, but more suited to content (blogs) and collaboration (groups).

    Less is more! I don’t expect social networking in a box. There are already several commercial products that serve that need better. I’d like to see a solid, stripped down core with a flexible API that a developer community can build on.



    To me BudyPress is more about being able to build a niche community.

    You can take an existing blog/site where people comment on posts and turn it into a site where people can converse and share.

    Basic functionality that is solid is a huge must. Well documented APIs to extend the basic functionality is a high priority.

    I have to agree with @Peterverkooijen that BuddyPress doesn’t need to be everything. In fact, I sort of wish BuddyPress didn’t advertise itself as “social networking in a box” because it attracts a lot of people looking for the quick and easy way to make their “millions” a la-Facebook.

    @stwc: “social networking” is a buzzword but like all buzzwords, they have a fundamental definition. “Social networking” means community to me.



    “Social networking” means community to me.

    Yeah, like I said, I may be making a distinction without a difference for many people. I reckon there is one, though.



    I think it is going to be hard to distinguish where the definition of the project ends, and the marketing of the project begins. There is a lot of terminology out there. Some is real, some is hype. I think most people are smart enough to look past the slogan and see the product. I don’t have a problem with using the terms “social network,” and “community” interchangeably. There is a subtle difference, but I think its possible to make BuddyPress a good foundation for both types of projects. In the end we all benefit by having a larger user base.

Viewing 25 replies - 1 through 25 (of 50 total)
  • The topic ‘The BuddyPress next generation API, the journey begins’ is closed to new replies.
Skip to toolbar