BuddyPress.org

(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?