BitNami offers a variety of development and production stacks that make it quick and easy to set up a localhost-based development environment or even provision a production-based server with a full suite of tools. If you are familiar with the better known MAMP, offered by the German company appsolute GmbH, then you should have no issues using BitNami’s version instead.

What are the benefits of using BitNami’s MAMPStack?

First, as of the date of this article, their stack is up to date. It is compiled and built with the most recent, stable versions of PHP, Apache, MySQL, and phpmyadmin. Second, they offer a very easy-to-install PostgreSQL addon module that integrates into the MAMPStack. This provides the opportunity to use an alternative database, even leveraging PHP’s PDO extension to create a truly SQL-agnostic application. It should not be too hard in the future to add support for other open source SQL-based RDBMSs like Percona or even Drizzle. Third, they seem very responsive to their user community.

Why would you want to integrate MongoDB into your MAMPStack?

The days when a RDBMS could be the end all and be all of your backend are over. For more on this point, read part three of my five-part Smartup series, Web 3.0 Smartups: Moving Beyond the Relational Database.

In short, in the Social Web, smartups cannot use a RDBMS as their only backend tool for every job. A RDBMS is not a universal tool. In fact, RDBMSs — MySQL in particular — are overused and often misused.

Let’s Get Started!

Integrating MongoDB into your BitNami MAMPStack is a relatively straightforward process — at least if you are a developer accustomed to building and modifying your dev stacks. Reading this article will take you some time. But, once you fully understand this process, it should take no more than fifteen minutes to install and configure MongoDB to work within your BitNami MAMPStack.

How do I know? Because before posting this article, I deleted my BitNami MAMPStack using the uninstall.app application with which it ships. This deleted all the work I did in integrating MongoDB into the stack. I then reinstalled the stack and repeated the process below. Of course, I had backup copies of the BitNami MAMPStack because there is no need to redownload that. But, I did go through the entire below process. Total time? Thirteen minutes and four point six seconds — and that is with two MAMPStack server restarts. Bam!

Disclaimer: Before you begin, you agree that you have read this disclaimer and the next one and agree with them. You understand that you are entirely on your own with this process. If you are not comfortable with UNIX commands, if you have never worked within Terminal before, if you do not know how the steps listed below will affect your computer, and if you do not know how to fix any issues that may arise out of trying out these steps, then do not proceed. I am not responsible for what happens to your computer as a result of these suggested techniques. You have been warned. Proceed at your own risk.

Disclaimer 2: This process should not be used on production servers. It is only suitable for a development environment running on localhost.

A. Compiling the MongoDB PHP Driver From Source

Grab the very latest version of the MongoDB PHP Driver. Download the tarball version.

(Note: Although you can try installing the driver using PHP’s PECL command, I’ve had spotty luck with that approach in the past when attempting to install MongoDB into a third-party dev stack. The driver did not always get installed in the proper location. Sometimes it got installed in the extension directory of the default version of PHP that ships with OS X. When that happens, you have to uninstall the driver and try reinstalling it into the proper directory. As this has proven unreliable in the past, I find it easiest to compile from source then move the extension into the proper location within the MAMPStack. It just takes a few more minutes but ensures that everything is in its proper place.)

Drag the tarball out of your Downloads folder onto your desktop. Then double click on the mongo-x.x.x.tar tarball to extract the files. This will create the driver folder. Open up Terminal and navigate to that folder. Each line below starting with a “$” indicates a new terminal command. Before beginning, see the notes below the ordered list. Enter these commands one at a time in Terminal:

1. $ cd /Users/{your_user_name}/Desktop

2. $ ls

3. $ cd mongo-x.x.x

4. $ cd mongo-x.x.x

5. $ sudo /Applications/mampstack-5.3.9-0/php/bin/phpize

6. $ ./configure

7. $ sudo make install

Terminal Notes

Step 1: Replace {your_user_name} with the name of your mac account user. It is the name that appears within the /Users folder.

Step 2: The list command will allow you to double check the MongoDB file folder name which you will enter in the next step.

Step 3: Switch to the directory that contains your MongoDB PHP Driver and associated files. Replace the x.x.x with the version number of the driver which should be the same as that listed for the folder name.

Step 4: This seems like a repeat of above, but if you inspect the folder structure of the driver download, you will see what is going on. This switches into the directory within the downloaded folder that contains the actual driver source files. It is within this directory that you run the compile commands.

Step 5: The phpize command prepares the build environment for PHP extensions — in this case, for building the MongoDB PHP Driver extension (mongo.so). You will be prompted to enter your administrator password. This is your mac user account password (assuming that you are the owner of the mac).

When the screen of output is finished, you will have a compiled MongoDB Driver extension located in the modules directory of the driver folder. Look in /mongo-x.x.x/mongo-x.x.x/modules for the extension named mongo.so. Copy that extension into the following folder in your BitNami MAMPStack directory:

mampstack-5.3.9-0/php/lib/php/extensions

Now you need to add the following to your listed extensions within the php.ini file. In the BitNami MAMPStack, the php.ini file can be found here:

mampstack-5.3.9-0/php/etc

Open the php.ini file in your favorite IDE and add this to the “Dynamic Extensions” section of the file, just below the last active extension:

extension=mongo.so

Save and close the php.ini file.

Now, before continuing on to the next step, if your MAMPStack server is running, stop it and then restart it. Visit your phpinfo page to make sure that the MongoDB PHP Driver has been installed and is active. If you don’t know what a phpinfo page is, visit this link. (I made my PHP Info Page and placed it at root level in the apache2/htdocs folder before I began this process.) Run your phpinfo page and look for the “Configuration” section in the output. Now scroll down until you see “mongo”. Check to make sure the version number is what you expect.

If you do not see “mongo” listed, or the version number is incorrect, you’ll have to start the process again — but first you will need to delete the mongo.so file from BitNami MAMPStack’s PHP extension folder. However, if everything looks fine, you’re ready for the next section below — part two.

B. Adding and configuring the MongoDB Database

In this section, we’ll setup the MongoDB backend and make sure that it is functioning properly.

Follow these simple steps:

1. Download the most recent, stable OS X 64-bit binary version of MongoDB. Double click the tarball to extract the files.
2. Create a new folder called “mongo” in BitNami MAMPStack’s root. When you are done, you will have this directory structure: mampstack-5.3.9-0/mongo
3. Create three subfolders in this newly-created mongo folder, setting their permissions to 775:

   bin

   data

   tmp

   Within the newly-created data directory, add the following subfolder with permissions set to 775 as well:

   db

4. Install the MongoDB files you’ve just downloaded and extracted into the mampstack-5.3.9-0/mongo/bin. Make sure you install just the contents of the bin folder within the downloaded MongoDB folder and not the bin folder too.
5. Next, you’ll create a configuration file for mongoDB. This file will tell mongo where to store data, log errors, and which directory to use for temporary stuff. In your favorite IDE, create a new file named mongodb.conf in the root directory of your mongo install ( mampstack-5.3.9-0/mongo ). In that file, add the following:

   # Store data in default MongoDB directory structure, /data/db/
   dbpath = /Applications/mampstack-5.3.9-0/mongo/data/db
   
   # Set location where all MongoDB errors should be logged.
   # This should create a log file if it does not exist
   logpath = /Applications/mampstack-5.3.9-0/mongo/mongodb.log
   
   # Set location of pid file; this should create one if it does not exist
   pidfilepath = /Applications/mampstack-5.3.9-0/mongo/tmp/mongo.pid
   
   # Only accept local connections
   bind_ip = 127.0.0.1

   Save and close your newly-created mongodb.conf file.

6. To launch MongoDB server, open up terminal and type the following command all on one line. However, as we have just made significant additions and changes to the basic, out-of-the-box BitNami MAMPStack, you need to restart your BitNami MAMPStack servers to make sure all the changes are picked up.

   Once the MAMPStack servers have restarted, type this into Terminal — place your cursor in the box and copy the entire string as it does extend beyond the margins of the box:

   sudo /Applications/mampstack-5.3.9-0/mongo/bin/mongod --config=/Applications/mampstack-5.3.9-0/mongo/mongodb.conf

   Please note: From now on, this is how you will start your mongod server.

7. Test your MongoDB install to make sure that the server is running. By default, MongoDB listens to port 27017. You can verify which port MongoDB is listening to by looking up the configuration settings of your MongoDB PHP Driver in the PHP Info page. However, Mongo’s Web-based admin console listens to port 28017. Therefore by visiting “localhost:28017” in your browser, you can see if you have a connection. If you do, you’re all set!

To learn more about starting and stopping the MongoDB server (Mongod), see this resource.

(Note: You could install MongoDB into your /usr/local/ directory and then symlink the binaries out of the /usr/local/mongo/bin folder to the BitNami MAMPStack. However, the idea in this method is to keep all the applications bundled under the same master folder — your BitNami MAMPStack. That way, uninstalling the stack is very simple. You just delete the BitNami MAMPStack folder from your /Applications directory. The method presented here also makes it easy to move this application setup to another machine. Finally, although it is normally not an issue, with this method you do not have to worry about potential problems when upgrading your OS.)

C. Download and install phpMoAdmin

We are almost finished! If you’ve successfully completed parts one and two above, congratulations! You have integrated MongoDB to run inside of your BitNami MAMPStack. This last step will provide you with a tool to manage MongoDB.

Just as you use phpmyadmin to administer and manage your MySQL databases, MongoDB has several database admin tools written in PHP. We’re going to be installing phpMoAdmin. Grab the most recent stable version.

Once you’ve downloaded a copy, unzip it if it did not automatically unzip. Next, create a new folder within Apache’s htdocs folder called phpmoadmin. Copy the moadmin.php file into this new folder.

Done! You now can access this very simple, but useful MongoDB admin tool by visiting “localhost:8080/phpmoadmin/moadmin.php” in your browser.

Alternatively, you can use MongoHub or RockMongo to administer your MongoDB backend. I suggest checking all three out and deciding which one you like best.

Why are we using phpMoAdmin? It offers the most recently-updated version out of the three and it is simple to install as it is a single, small file. For this article, it is sufficient. However, the other tools may provide better GUIs and a stronger set of features. So, you should check them out and decide which one you like best.

Don’t Forget to Give Thanks!

That’s it!

You can further expand your BitNami MAMPStack by setting up VHOSTs in your Apache config file, but that is beyond this article. If you’re interested in that, see the documentation in the /apache2/manual folder.

Finally, please remember to give back to the open source community as it provides you with high-quality, powerful software with many freedoms — and often free as in cost, too. Share this article, write your own, create a version of this article for Linux distros or Windows, volunteer time to an open source project, contribute bug fixes, thank BitNami for their services, or donate to help fund an open source project. Free and Open Source Software (FOSS) needs your support!

Now go out there and create the next, greatest Smartup!

More resources

• Learn more about MongoDB
• MongoDB books
• Blending the Doctrine ORM with the Doctrine MongoDB ODM

The current Web has moved past the point where personal blogging is a big focus into the realm of real-time (RT) social interaction. Most content is now generated and shared via RT social networks than on CMS-based systems. However, unlike a CMS’s focus on content, the RT social networks’ focus is on users and their Streams.

No longer is it sufficient to place content at the center of a system’s model. Instead, the RT Social Web demands that users have primacy, that their content preferences, that their Stream choices and channels, are just a part of their overall presence on the Web.

Instead of blogging-1.0 styled CMSs, the paradigm has shifted to what I call User Stream Manager (USM) systems. A USM places the user at the center of the system, not the user’s content.

One such USM is Bottlenose, a self-described tool ”that helps you engage with your streams more intelligently.” Bottlenose was founded by Nova Spivack (T, G+) , a prolific Venture Producer, and Dominiek ter Heide (T, G+), a very talented developer and CTO.

I’ve been privy to Bottlenose’s development for more than a year, watching it evolve into a more robust, well-envisioned Stream management tool — a USM. Although I have not used it on a daily or weekly basis, I’ve kept an eye trained on its progress, stepping back in every so often to test its waters.

I just did so again last week and all I can say is Bottlenose will become my default real-time Stream management system. I’ve grown tired of TweetDeck, HootSuite, and other social media dashboards. Whereas Bottlenose is still a nascent platform and therefore should not be compared apples to apples with the aforementioned dashboards, it’s future prospects are greater in my opinion.

Bottlenose’s foundation embraces Web 3.0; the company lives in what I call the Smartup space. The technology and the company are leading the way toward the era of the User Stream Manager. As consummate Smartup practitioners, they’re aiming at building an ecosystem around their core technology, including the ability for 3rd-party plugins to enhance the Bottlenose experience. Add to this the possibility of an app store, and you have a smartup that not only will monetize in a smart way, but share some of their financial success with other developers.

There is a lot of low-level, amazing, and cool technology that churns underneath Bottlenose’s surface, helping to sort out the flotsam and jetsam in your Stream from the treasures. Their proprietary tech helps extract the signal in your Stream from the noise in your channels. It learns what you like and dislike. It allows you to teach it how you prefer paddling your reach of the RT social river.

Currently, Bottlenose’s oars, rudders, and keel are just in the Twitter and Facebook Streams. As it continues to evolve, hopefully adding additional Streams into the mix (Google Plus, Quora), its utility will only increase and each user’s journey down their RT social Stream will become more meaningful.

If you have not yet tried Bottlenose, it’s time for you to jump on in. The water is fine and the flow is just right!

My Related Articles

1. Flocking To the Stream
2. Building the Social Web: the Layers of the Smartup Stack
3. How Many Streams Can You Kayak At Once?
4. The HyperWeb: it’s All About Connections
5. The first article in my five-part smartup series, Web 3.0: Powering Startups to Become Smartups

The Apple boys used Jobs’ parents’ free garage. The Google boys used a friend’s garage for free (initially). HP founders used an unattached garage that was part of the home for which they shared the rent (Dave Packard and his wife lived in the house).

Thus the G+ thread was a discussion about what has replaced real garage spaces as a place where startups should startup. In the post’s comments, a number of apparent startup founders were praising the virtues of co-working spaces, claiming that they are the new startup garage.

I found this statement odd. Bootstrapping founders don’t pay for anything until they absolutely need it. Even if a startup has more money than they know what to do with, wise founders don’t pay for something until it is essential. To me, whatever is the cheapest location option for a startup is the new garage.

The key with the startup-bootstrapping approach is to minimize expenses upfront. Use space for which you are already paying but not using efficiently–your bedroom, dining room, garage, shed, basement, one-room apartment, or dorm room. Or borrow (for free) extra space in your parents’ or friend’s home or apartment. Coffee shops or even libraries might work too but co-working spaces definitely do not. Why spend precious resources when you can get space for free. Once you have an initial product to demo, and you’re beginning to gain traction, it may make sense to look for better facilities.

Renting an expensive place will not make you successful. The “it’s key for networking” mantra is a thinly veiled excuse. Nothing prevents you from networking if you work out of your house. If people only networked with people whom they share the same physical office building, then the world would collapse.

Whether you’re a bootstrapped startup or a well-funded startup, the key is execution on building your prototype, creating your MVP. Don’t foolishly waste cash just to be in a cool place. If you don’t have a founder’s team that can successfully execute the startup’s vision, then the team is flawed. Having the coolest place on earth will not change that. Besides, what can be cooler than starting up in a real garage — especially in the winter!

Note: Before any of my readers get a guilty feeling that I’m talking about you and your startup, relax. I’ve held this view for years and decided to share it after reading the interchange on the aforementioned G+ post. After all, my current startup uses the already-paid-for space in my house and my business partners’ houses. Although there is a fabulous co-working space in a high-tech park less than three miles from my house, I have zero interest in paying for more real estate when I already have real estate that I can use.

As a Social Web architect and an open source advocate I frequently write, think, and promote the notion and ideals of the Open and Social Web. My work in the areas of user-centric control (identity, privacy, data portability, and rights), federated Social Web models, future-of-money projects, and W3C standards groups has shaped my views presented here.

Soon after publishing my 4-part smartup series (almost a year ago), I began to think about key parts of what has become this article. I’ve had bits and pieces of this article jotted down in various places. Over the past three months, the ideas have coalesced into a cohesive framework. With a recent and lengthy process of helping a potential smartup try to find its foundation, I’ve been motivated to assemble, clarify, and share my views on what I call the layers of the smartup stack.

If you’ve carefully read my previous installments in my smartup series you will have discovered–in part–the message that is expressed here. This next installment in the series seeks to clearly present the framework of the smartup stack.

Smartups are Socially Transformative

Smartups look to operate beyond the stale disruptive technology mantra; the smartup vision is not simply a paradigm shift. Instead, smartups are best described as innovating at the intersection of technical, social, and cultural evolution. As such, well thought-out and executed smartups are revolutionary entities. They are socially transformative ecosystems.

The power that a corps of ecosystem partners can bring to your smartup’s success cannot be emphasized enough.

The layers of the smartup stack embrace the uniqueness of each smartup while recognizing the interconnectedness of the greater community. In this regard, smartup’s do not build software. Smartup’s create ecosystems. Like an ecological food web, your smartup can be viewed as an organism that is linked to and interdependent upon other organisms and system services. This mindset requires a broader view of your smartup’s role in society. A smartup’s ultimate goal is to create greater value than is captured.

No matter the grand vision of a given smartup, all smartups share the same DNA at their foundation. They are tech-reliant, Internet-obligate companies. If you need some convincing of this fact, please see my article, Putting the Tech Back into Social Web.

The Layers of the Smartup Stack

Whereas technology is at the center of the smartup stack, you will see in this article that smartups are greater than the sum of their technologies. As we explore each additional layer of the smartup stack, the focus shifts more and more to the outside. Greater emphasis is placed on the social, economic, and cultural frameworks. This will help integrate your vision into the real world. It will help bridge your metaspace creations with their meatspace participants.

Layers can connote horizontal levels upon which other material is placed or stacked. But in the view presented here, layers are rings that surround and bind to any lower and higher concentric-ring partners.

It is practically impossible to singularly architect and build each of the smartup layers without regard to their immediately contiguous layers. However, I will present each layer as if it were a well-defined and self-sufficient entity. The reality is that at all stages of building out your smartup stack, the interconnections to and interdependencies on other layers (inner and outer) must be carefully explored and considered. This is one reason (among many) why your smartup must have in-house technological expertise from the start.

As mentioned above, smartup’s do not build software, they create ecosystems. They recognize that there is great benefit to being linked to and interdependent upon others in a larger system. As many of the system services are outside of a smartup’s immediate control, a smartup must architect its ecosystem to work in symbiotic harmony with the greater Web community.

To that end, a smartup leverages and relies upon open source tools and open Web standards. As we will discuss in the section about the outermost smartup stack layer, smartups also give back to the Open Web movement in order to embrace an ecosystem approach.

The Inner most Layer: the Technology Platform

As mentioned above, technology is at the very core of every Internet-obligate smartup. The center of the smartup stack, then, is the technology platform. There are four pieces that comprise the technology platform. As previous smartup articles discuss two of these pieces in depth, I will not present much additional detail about them.

Each piece of the tech platform layer relies on Open Source tools and standards where ever possible. Although a smartup creates its own technology in aggregate, it leverages code libraries, tools, and standards to help make the process of building out their platform quick and efficient.

At this stage you will be proportioning your smartup’s time between product iteration (which means more coding), marketing your MVP, and customer development. Although you must find the proper balance between these three activities, the primary focus of this process is on building out your smartup’s foundational technology platform.

Here are the four pieces of the tech platform:

1. Schemaless Backend
2. Semantic Web / LOD Stack
3. Responsive Codebase
4. Modern Web Standards

Schemaless Backend

I’ve written an entire smartup article on the virtues of NOSQL versus SQL, so I will not repeat anything here except to say that some smartups may need to use an RDBMS as well for part of their overall data warehousing needs. The main point is that smartups are big-data players and as such they need to utilize the best technology for modeling, capturing, and managing that data. NOSQL databases are, by and large, the preferred choice.

Semantic Web / LOD Stack

I’ve also written an entire smartup article on the Web of Data. Suffice it to say that Semantic Web technologies, which some prefer to refer to as Linked Data technologies, enable the linking of data and allows for the serendipitous discovery of new connections with other datasets.

Smartups understand the value of and participate in the Web of Data. Smartups realize that data is the unit of exchange on the Web, not documents. Instead of Hyperlinks being the engine of exchange, it is Hyperdata. Data is the energy, the food, exchanged between participants in the Social Web. Semantic Web technologies facilitate the flow of information between “habitats”, between communities.

Responsive Codebase

This is the most generic-sounding piece in the tech platform layer. I will not delve too much into this piece of the tech platform layer as it deserves its own full-length article (perhaps the sixth installment in my smartup series).

There is not one preferred or recommended framework, language construct, or codebase that all smartups use. Different smartups use different code-creating tools. They pick those that they are most comfortable with and that serve their particular tech needs. However, there are some clear trends and, therefore, advice that can be offered to each smartup.

The broadest bit of advice is that Internet-coding technologies are evolving to catch up with and meet the needs of a more data-intensive world. Although a smartup CTO should use tools with which he or she feels comfortable, that does not mean that they can be complacent, that they should not spend time exploring and learning some of the newer options.

For instance, a smartup will choose an object-oriented coding style versus a procedural-coding style. But that does not mean that all smartups have to code in PHP, Python, or Ruby. There are some promising, new, convention-breaking language platforms that are the current rage in the Web dev world. One of these is NodeJS—a highly-scalable, high-concurrency, event-driven framework.

Another major smartup trend that epitomizes the Responsive Codebase mantra is moving as much of the processing away from the server side as possible (Web-1.0 and 2.0s thick-server approach). The focus is on creating what are referred to as fat- or thick-client applications. In other words, the browser or mobile device handles considerable more of the processing, relying a lot less on the server.

Another trend is the use of light-weight code libraries. When properly utilized, they allow a smartup to react more quickly and be nimble in their coding practices. As an example, one light-weight code library that my newest smartup uses is JSON-LD. It brilliantly facilitates cross-piece integration and as such can be categorized as falling into both pieces two and three in the tech platform layer.

A final smartup trend is preferred data formats. According to a recent report, 55 percent of all new APIs have support for JSON and a staggering 20 percent of new APIs support only JSON. This demonstrates the quickly-growing trend of utilizing JSON as a preferred data format (see slides 22 & 23). It also indicates that for data interchange, the reliance on XML is fading fast.

Modern Web Standards

Smartups support, adopt, and utilize Web standards. HTML5 and CSS3 are currently among the two most important Web standards. There are of course other standards, whose utility will vary among smartups, but these two should be utilized by all smartups.

The Second Layer: User-control and Economic Engine

The next layer of the smartup stack contains two sublayers that interconnect via their direct connections with the technology platform. Once again, this illustrates the importance of the technology platform as being a fundamental, foundational layer to all smartups.

These two sublayers are:

1. User-centric Rights & Control
2. Future-looking Economic Engine

User-centric Rights & Control

As I have written much about user-centric control over identity, privacy, usage rights, and data portability in the past, I will gloss over most of the details. If you’re interested in learning more about my viewpoints on these topics, simply search my website.

All smartups believe in and understand the importance of returning as much control over data as possible back to the users. They realize that it not only makes sense from the standpoint of being good social stewards, but also it makes good business sense as well.

With support from the smartup’s tech platform, users have significant power over each piece of data that they contribute, that they generate. Further support for users’ rights and control can be provided through novel, user-friendly legal contracts.

Future-looking Economic Engine

I’ve been interested in future-of-money projects and theories for sometime—particularly in how technology, specifically Internet tech, is leading to a revolution in how value is exchanged. This is why I am a charter member of the newly-announced W3C Web Payments Standards Community Group.

I believe that new micropayment frameworks and economic models are essential to not only the healthy growth and long-term viability of a truly Social Web, but also to our greater global society. The future of money and of economic self reliance rests in the emergent properties of the social-driven superorganism. Centrally-controlled currencies will eventually give rise to decentralized currencies and instead of tightly controlled and regulated markets, self-regulation via distributed command and control processes will become the norm.

Smartups are on the bleeding edge of this economic revolution. Smartups thus play an important part in helping to push new payment frameworks and economic models. They are intimately involved in evolving economic models and understanding the need for a universal payment mechanism for the Web—a mechanism that will facilitate the proliferation of alternative currencies, friction-less payments, crowdfunding, and general value exchange.

One payment framework that my smartup will be leveraging is PaySwarm. It is described as, “an open standard that enables web browsers and web devices to perform micropayments and copyright-aware, peer-to-peer digital media distribution.” I believe that PaySwarm can become one of the central pillars to any smartup’s future-looking economic engine.

The Third Layer: the Smartup Social Engine

This layer integrates with the innermost two layers of the smartup stack. The focus is more on the user interface (UI) and the user experience (UX).

When combined with the first two layers, this layer comprises what can best be described as the Smartup’s Social Engine. It is the internal platform that contains any intellectual property (IP). It is the fully-functioning application that provides the smartup’s unique product and service offering.

Although basic UI/UX considerations were made during the initial MVP testing, proving, and refinement phase, it was a Lean UI and Lean UX process. The Social Engine Layer is where a smartup spends considerable time perfecting its full-blown UI and UX. Issues such as tight integration with the the User-centric Rights & Control and Future-looking Economic Engine sublayers are addressed. Issues with proper social interaction flow are addressed.

At this level in the smartup stack, the focus begins to shift more toward the outside, toward the physical usage of the service, and not its technical underpinnings. Toward that end, pathways with which others can interact, integrate, and extend the smartups services are developed and engineered. These become the domain of the next layer.

The Fourth Layer: Outward-facing Connections

A key vision of the smartup model is to encourage and enable outside parties–3rd-party developers and other smartups–to contribute to and expand upon your smartup’s vision. To bring that goal to fruition, a smartup makes anywhere from one to three of the following sublayers available to outside parties. How many sublayers are offered depends on the type of smartup and its overall needs and vision.

The three possible sublayers of the fourth smartup stack layer are:

1. Smartup API Access
2. Smartup Open Source SDK
3. Smartup Standards Group

Smartup API Access

By and large, the vast majority of smartups publish a set of APIs that allow outside parties select access to their datasets. As discussed in the final layer section below, the use of APIs by outside parties can be a major catalyst in a smartup’s growth and success.

Smartup Open Source SDK

The Software Development Kit (SDK) sublayer is more accurately termed an Application Development Kit (ADK) sublayer. The notion behind this sublayer is that there are core codebase modules that may very well be primed for open sourcing. We will see below in the discussion of the final layer of the smartup stack why open sourcing some (or all) of your smartup’s codebase can significantly accelerate the development and evolution of your platform.

Smartup Standards Group

This sublayer is the least-frequently encountered sublayer in the smartup world. The purpose of this sublayer is to standardize key pieces of a smartup’s platform.

Above, in the second layer section, I briefly mentioned PaySwarm. That is a perfect example of a smartup opening up some of its work, exposing their efforts to the open standards process. The newly-announced W3C Web Payments Standards Community Group will focus its efforts around core working technology—mainly PaySwarm.

If your smartup has key technologies that could benefit the greater Social Web by becoming a part of an open standard, then you are encouraged to offer up as much of your technology as possible to make that happen.

The Final Layer: the Smartup Ecosystem

This last layer is perhaps the most difficult one to describe in a few paragraphs. The goal is to freely offer unrelated, 3rd-party smartups and developers tools that they can leverage to help build out, evolve, and expand upon your smartup’s original vision. At the same time, the access that you provide to your smartup’s datasets and technology allows them to create their own paths to success. This is what I term a smartup’s ecosystem.

The sublayer offerings in the fourth layer enable the creation of a motivated, loosely-organized team of volunteer coders that can and will help expand upon and evolve your technology—at least that part of your technology to which you allow 3rd-party access. The power that a corps of ecosystem partners can bring to your smartup’s success cannot be emphasized enough. This is why the ultimate goal of each smartup should be to create more value than is extracted from the ecosystem.

As an example, think of what happened when Automattic–the original makers and copyright holders of WordPress–open sourced the codebase. This led to the eventual, very-large ecosystem of WordPress theme shops, plugin developers, and consultants. It also allowed for Automattic to gain an exceptionally cheap (as in cost) and talented labor force which it continues to use to this day to help it build out the WordPress codebase. That is one of the powers of crowd-sourced software development via open source practices.

Twitter is another great example of the virtues of creating an ecosystem. In its early days, Twitter not only welcomed, but strongly supported and encouraged 3rd-party developers and startups to help expand their ecosystem. They published a rigorous set of APIs that allowed for developers to gain access to many of the datasets Twitter captured. In return, the 3rd-party developers were able to create new features and services that augmented the Twitter experience. This led to a number of successful companies that seemed to pop up over night, swirling around the core of Twitter.

Without these ecosystem partners, Twitter may very well not have succeeded. Unfortunately, as Twitter continues to struggle with figuring out how it can monetize its success, it has cracked down on their ecosystem partners in recent months, making many of them wonder if they can trust Twitter anymore. Twitter’s brilliant ecosystem strategy may be coming to a close.

Facebook was also an early creator of an ecosystem of developers. They offered limited API access, created their Open Graph ontology, and even open sourced a few of their key technologies. However, for the most part, Facebook required (and still does) that the apps of 3rd-party developers live within the siloed confines of the Facebook universe. Facebook is not a proponent of the Open Web, Open Standards, or user-centric control.

Of course, neither Automattic, Twitter, or Facebook are considered smartups. Although they do support–each to differing degrees–some level of open source involvement with their projects, they fail the smartup test with respect to many of the other smartup stack layers detailed above.

Conclusion

You don’t build a startup, you build a company. Whereas the word startup is an enticing concept, it is nothing more than a brand, it connotes nothing more than the early stages of a company. Each stage has its own specific needs and foci. Smartups are no different in this regard.

As mentioned above, many Internet-based startups do not transcend their technology but smartups have a vision beyond their technology. Even so, smartups recognize that–as Internet-obligate entities–they cannot divorce themselves from their technological foundations.

A smartup first builds a strong, foundational layer of technology upon which it then layers on additional functional components. Each of these components–also called sublayers–help push the smartup closer to its vision. To fully actualize its vision a smartup must create the conditions that enable, encourage, and support a system of ecosystem partners. In unison with its ecosystem partners, a smartup works toward providing services that empower users to pursue some of their passions and fulfill some of their goals.

Past Smartup Series Articles

Part 1: Web 3.0: Powering Startups to Become Smartups

Part 2: Web 3.0 Smartups: the Social Web and the Web of Data

Part 3: Web 3.0 Smartups: Moving Beyond the Relational Database

Part 4: Web 3.0 Smartups: the New Web Business Space

</Smartups Series Part 5 of 5>

How to Get Me Involved in Your Smartup

Interested in getting me involved in your smartup? Please see my 7-by-7 rules.

Below you will find what I call my 7-by-7 rules. Whereas this is my current set of criteria, I believe this list is useable by anyone seeking to attract talent or looking to start a smartup. Please feel free to adopt, modifying, or expand upon this list and use it as you see fit.

I’ve created this post for one purpose. To help alleviate the emails, requests for Skype convos, and PMs that I periodically receive. I’m guessing that I’ve spent 200 hours this year alone rehashing, justifying, even debating to the point of arguing, some of the items below. This post will serve as a one-stop-shop to learn about my requirements. If you read this and still think that we should talk, then contact me.

First an important note. I have my own nascent smartup that requires most of my time. I also have a number of other projects and responsibilities that use up any remaining time. I am active on three W3C standards groups, closely work with a few open source projects, and spend as much spare time as possible with my family.

Thus it will be very difficult to get me to bite on your project. But if you want to maximize your chances of success, here is how.

General Requirements

1. Your startup must be in the Web-based or mobile-based Internet space. In other words, it is a technology-obligate Internet company. Although in the not-too-distant future, my horizons will broaden to include nanotech startups as well.
2. Your startup must be a smartup. I am not interested in stale Web-2.0 startups.
3. Your smartup must be looking to build, or at least contribute to, the Social Web
4. Your smartup and its founders must be proven participants in or at least supporters of open source projects and principles
5. Your smartup must primarily use open source tools and technologies to build its technology platform
6. You understand, believe in, and adhere to the practices and principles of lean startups
7. I will not sign an NDA. In 2009, I signed a few and requested a few others to do the same. In 2010, I requested zero NDAs and only signed one. Now, I will no longer request nor sign NDAs. To learn why, see this good read on the topic.

Specific Requirements

Note: If you are at the earliest stages of your smartup–having yet to incorporate–and are interested in coaxing me to join as a founder, then I will help you address each of the below points assuming that I agree to come on board.

1. The smartup founders must be pre-aligned on exit valuation and have a written exit strategy that all founders have signed. Why? See this great resource.
2. You must understand startup valuation and its impact on future employees and future investors. See this interesting link for one way to assess your smartup’s current value. If you think that your smartup has a current value other than zero, you must be able to justify it. Although your sweat equity and early accomplishments of course add value to your smartup, you are initially being compensated for your contributions by receiving a large chunk of very cheap stock. If you are a pre-profit, pre-revenue, pre-product smartup that has yet to cut a single line of code, please don’t overvalue your contributions at this stage. Outside investors will certainly not make that mistake.
3. With respect to point two above, you have a well-reasoned and modeled capitalization table (cap table). This may not seem crucial right now, but it becomes essential if and when you seek outside investment. Creating, understanding, managing, and periodically updating your cap table early on is key to making better business decisions. Remember, you are starting a business, not a charity.
4. Your smartup must know when to think outside of the box factory and when it must view the box from within. As a founding team, you will meet some very fascinating, talented, and inspiring people as you promote your project. Don’t get too caught up in wanting to hangout with inspiring people all day long. We all want to do that. What matters right now is laying a solid technical foundation for your smartup (see point 1, General Requirements, and point 5, Specific Requirements). Properly allocating scarce resources to accomplish that crucial task at inception is essential to your long-term survivability, investor suitability, and future success.
5. You firmly understand and agree that at the early stages of your smartup, tech is at the core of your company. To that end, your smartup has an internal technical founder. Whereas having a strong business foundation within the core team is fine, even desirable, not having any technical expertise in the core team is detrimental. See this article section for an exhaustive reasoning for this requirement.
6. You have sufficient in-house engineering skills to begin the process of building out your technical platform, of creating and iterating your MVP. You do not plan on using contract coding firms or overseas hacking sweatshops for building your platform. Don’t be penny wise and pound foolish. See this article section for a story behind this requirement.
7. With rare exceptions, I have no interest in becoming a basic employee or a non-founder-level executive. By and large, if you want me to be part of your smartup, I’m interested in a founder’s position with a healthy ownership stake. I must have the opportunity for significant reward with the opportunity costs that I will incur. If a founder’s position is not possible, I may consider an advisory or outside board member position for the right smartup.

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.

The issue in summary is that the big telecos are aiming to rate limit packet traffic across the entire wireless spectrum. That means that no matter what kind of data you send (text or media based), there could very well be a toll. Those that pay the highest access fees will see their data travel at the maximum throughput rates. Those who can’t pay as much, will in effect have their data throttled.

As I state at the beginning of a previous article on this issue:

If you design websites, run a small web-based business, make money from blogging, or are launching a startup, the level playing field of the Internet is about to get very bumpy. If you think that mobile-based services are the future and are catering to the wireless crowd, then be prepared for a game-changing shift.

There is a potentially game-changing new variable being considered that will skew the Internet’s competitive landscape. Currently, content creators pay fees to host their data, maybe even overage fees if bandwidth limits are exceeded in a given month. But once the data leaves the confines of their Web server, it travels across the Internet’s backbone infrastructure at the same rate as all other traffic.

The Google-Verizon proposal would allow an altogether new fee to be charged for wireless throughput—an access fee, a toll placed on data after it leaves your hosting firm’s building, or your company-owned server farm. This means that content providers–bloggers, ecommerce sites, social networks, you name it–will all be assessed wireless transmission fees. The higher the fee paid, the faster their data will be allowed to travel.

Why is this an issue? Because healthy competition requires a level playing field. Without net neutrality across the Internet’s entire infrastructure, users looking to join new niche social networks or who frequent boutique ecommerce sites may very well bypass those sites that appear to run very slowly on their wireless devices. They may instead move toward those sites that have a fast wireless response time.

It is not realistic to think that an unfunded startup, a new BuddyPress-based site, or a small blog-based ecommerce site would be able to afford paying the same fees as big companies. That would mean that their data would not travel as fast across the wireless infrastructure.

How many Web surfers want to waste their time waiting for what appears to be a slow server response? In fact, it may not be the server at all. Instead, it could be the speed limit placed on the data packets after they leave the Web server.

Think of it this way. When a WordPress Multisite install runs on a heavily-trafficked shared server, it can be painfully slow to use. Site owners who have configured their network this way often report that their members are complaining about how slow the site is to use, that new user registration is down as a result of the poor load times. The solution often suggested is to enable caching and upgrade to a VPN or to a dedicated server.

But guess what. That solution will not help if wireless packet traffic is rate limited. You could have the biggest server farm in the world with the fastest processors, maxed out memory, efficiently cached and compressed data, and best switches. But if you are not willing, or able, to pay the fees required to let your data travel unencumbered across the wireless infrastructure, then your users may have the same experience as if your site was on a shared host. Your users will not care why your site runs slowly. They may jump ship and spend their time on those sites that run at the speeds they have become accustomed to before net neutrality went out the window.

It is true that the total, theoretical wireless capacity is not nearly as high as that of the current wired-based infrastructure. But let’s remember that the wireless spectrum is not privately owned. It is leased from the public. There must be realistic limits placed on what private corporations can do with public assets. Allowing telecos to leverage their leases in such a way that condones economic inequality does not seem like a move in the public’s best interest.

Finally, we must remember that the wireless carriers already charge for data access. They just do it on the receiving end via subscriber fees and limits put on total bandwidth usage per month. What they want to do now is charge an additional toll to the content creators. So they’ll get paid by both parties, they’ll charge a toll on both ends of the wireless highway.

If it Costs Users, it Could Cost You

Guess to whom these costs will be passed? Why do you think that Facebook, eBay, and Amazon have all recently communicated their disapproval with Google, Verizon, and AT&T on this issue? Although these three behemoths could all afford to pay the highest access fees that the telecos may charge, they know that these costs would have to be passed back to their customers. They also realize that it sets a dangerous precedent—that of assigning data packet priority based on transmission fees paid.

If you don’t think that this issue might negatively impact your business, think again. Although this is currently a potential threat, it is a serious threat nonetheless. If the very people who create the content, consult for the content creators, and run the small ecommerce sites do not speak up, then the FCC and elected officials may not take as much interest in this issue as they should.

So, if you make your living as a blogger, by catering to the blogging community, or working for a social media design or marketing company, it’s time that you stir the pot and write your own post, contact your elected officials, or band together with some of your colleagues to shine light on this important issue. It does not matter if you are not based in the United States. This issue may affect your bottom line where ever you live.

Related Articles

Google-Verizon Joint Statement Presages End to Net Neutrality

Goodbye Google Old Friend: It’s time for the Open-Source Internet

Updates

December 21, 2010: Today the FCC voted on net neutrality regulation. The results do not bode well. See, Why everyone hates new net neutrality rules—even NN supporters.

November 4, 2010: With the U.S. midterm elections finally over, the possibilities for protecting net neutrality seem even worse. Read this CNNMoney article, Final nail in coffin for Net neutrality?

November 29, 2010: In a related development, Comcast is striking a blow against net neutrality for the wired Internet, requiring Level 3 Communications–a major fiber-based backbone provider–to pay them a recurring fee to transmit high-bandwidth content to Comcast’s customers.

November 30, 2010: Tell the FCC what you think by standing up for net neutrality. Sign the petition to stop Comcast from blocking Netflix IP traffic.

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.

(You can download the latest version of WordPress Hook Sniffer here. Please read the readme.txt file for important usage and installation notes.)

After the bug fixes, the most noticeable improvement is that you no longer need to manually install the modified plugin.php file—the file that gives hook sniffer its abilities. The plugin now automatically installs the modified plugin.php file upon plugin activation and then reinstalls the original, stock WP version of the /wp-includes/plugin.php file upon plugin deactivation. This means that when you deactivate the plugin, you can rest assured that WP Hook Sniffer no longer has any influence over the operation of WordPress.

As there are important differences between the /wp-includes/plugin.php files of WP 2.9.2 and WP 3.0, WP Hook Sniffer now requires WordPress 3.0. Upon activation, an automatic version check is performed to make sure that WP Hook Sniffer is installed on the proper version of WordPress. If the plugin is installed on an older version of WordPress, it will not run. A warning message is displayed in the Plugins directory and in the WP Hook Sniffer Settings screen.

Also, I’ve versioned the modified plugin.php file that comes with WP Hook Sniffer. Now, when you activate the plugin, it runs a check to make sure that the proper version of the modified plugin.php file is installed in /wp-includes.

Finally, I added a CSS file to improve proper code separation–the older version simply had inline CSS definitions–and renamed all CSS selectors to make them unique to the plugin.

If WordPress Hook Sniffer has become an indispensable tool in your WP plugin development toolkit, please donate to help me keep this plugin updated and its sniffer healthy! Thank you!

Sponsorship Levels

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!

I have been having a few issues with BuddyPress development over the past week. I went through all the usual techniques to isolate the issue, finally deactivating all my 3rd-party plugins. But, the issue remained. Finally, I wondered about my WordPress Hook Sniffer plugin. I realized that although it was deactivated, it might be negatively affecting the operation of WordPress if the modified plugin.php file that comes with the plugin had issues. I replaced the modified version of plugin.php with the original one that ships with my version of WordPress, and bingo, the issues went away. All I could think was crap—especially as I say this in the installation instructions:

“The modifications to WordPress’ standard Plugin API file are used exclusively for WordPress Hook Sniffer. They should not affect the functioning of the rest of WordPress.”

In fact, this statement is still technically correct. The culprit is that when I updated the modified plugin.php file for last week’s version 0.13 update to the WP Hook Sniffer, I failed to use the proper base plugin.php file. I used the one that ships with WP 2.9.2 and not WP 3.0. Even though I thought I had done a sufficient parity check between these two files, I had failed to notice a few important changes.

WordPress Core Developers please note: if you change a function you should indicate as much in the inline documentation. Please use the @version PHPDocumenter tag to indicate that the function has changed. The @since tag version indicator is not helpful if the function has changed.

What issues did I have that caused me to discover this problem? The WordPress “wp” action hook was not firing. Yep. That is a big problem, especially if you are doing development work. Interestingly enough, most of BuddyPress continued to function as expected, except for a few features that used to work but suddenly stopped working—right at the time I installed the updated version of WP Hook Sniffer. Of course, I failed to notice this for several days.

I have gone through the stock plugin.php file–with a very fine-toothed comb–and ferreted out all the changes. I am in the process of updating the modified plugin.php file that WP Hook Sniffer is required to use. I want to make sure that it is adequatley tested before releasing an updated version. Look for the updated version with a fixed plugin.php file to be available either Sunday or Monday.

With this pending update, WordPress Hook Sniffer will require WordPress 3.0. Therefore, if you want to use it in an older version of WordPress, you will have to install Version 0.12 of WP Hook Sniffer. Please note, I will only support the most recent version of WordPress Hook Sniffer.

I apologize if this has caused you to lose valuable development time. I know that I have lost several days of productive coding due to this issue. There were obviously some important changes between WP 2.9.x and WP 3.0. Even though I thought I had properly assessed potential changes within the plugin.php file, I had not. I guess I need more sleep, more caffeine, fewer late-night alien visits, or some combination of those three.

These are not the normal, run-of-the-mill plugins that extend BuddyPress by adding additional functionality for a site’s members, or allow a site administrator to selectively alter the core functionality of BuddyPress. Instead, the plugins that I’m excited about are specifically targeted to providing site administrators and developers with unique services. I call these tools to differentiate them from the general-purpose plugins.

Although there are currently only a handful of such tools available, I hope that these releases indicate a trend. The WordPress ecosystem needs more specialty tools for site administrators and plugin developers.

So, in no particular order of importance, here is a listing of the more interesting plugins that provide useful tools for the site administrator’s or developer’s toolbox.

Developer Tools

WordPress Hook Sniffer: This is a tool I recently released that helps plugin developers determine the sequence in which action and filter functions are fired. It provides a window into the inner workings of the WordPress Plugin API and can help a developer figure out why a custom action or filter hook or function is not working as intended.

WordPress MU Demo Data Creator: Provides a utility for populating your WPMU development sandbox database with dummy data. Why waste time creating your own dummy data to test your plugins when it can be auto generated for you.

BuddyPress Skeleton Component: This is not a new developer tool. In fact, as an example BuddyPress plugin component, it is the grand progenitor of many BuddyPress plugins.

BuddyPress Template Pack: This is not a developer’s tool per say. But I think it deserves listing nonetheless. It is actually a theme designer’s tool that helps make a custom WordPress theme compatible for use as a BuddyPress theme.

Site Administrator Tools

BP System Report: This tool gathers useful network intelligence on a site’s member and group activity. It provides a site administrator with usage trends and statistics, offering important insights into the health of their community.

Import from Ning: I thought I should throw this one in as well as it is a tool that helps social network operators. It provides some utility in helping to migrate a Ning network to BuddyPress. As Ning does not offer too much help in migrating existing networks to competing platforms, this tool is not a panacea to your Ning-networking woes—but it is a great start!

Plugin Developers Need Your Support

Creating a high-quality plugin takes more time than most people realize. In fact, it can take as much time if not more than creating a top-quality theme. But plugin developers rarely receive the same financial rewards that premium theme designers do.

My limited, empirical data shows that with the number of downloads of my current three WordPress / BuddyPress plugins, that less than 0.1% (yes, that is less than one-tenth of one percent) bother to donate. If my plugins received poor reviews, that would be understandable. But, as my lowest-rated plugin received a 4.5-star review out of 5, the lack of donations obviously has nothing to do with perceived quality. Note: Although I am a listed contributor to the BuddyPress Skeleton Component, I do not include that as one of my three plugins.

Whereas the greater WordPress community appears to have no issue with spending money on what are called premium themes, there seems to be a disconnect when it comes to supporting the developers of the plugins that help make their communities successful. Yes, great themes definitely provide an important face to a community, but it’s important to remember that plugins– along with the core functionality of WordPress and BuddyPress–provide the foundation to our networks.

So please generously donate to plugin developers and help keep them coding their wonderful plugins be they general purpose or specialty in nature.

As a developer, one of the downsides to Open Source projects like WordPress and BuddyPress is that a significant amount of foundational code is already in place. There are hundreds of functions, classes, methods, and general code that you never actually get to know. Sure, you might call them from within your code, you might know how and when to use them, but you more than likely do not understand how and why they work and what they actually do to accomplish their task.

Why? Because you were (more than likely) not part of the team that wrote the code, that figured out what each function was required to accomplish and in what ways that code would interact with other parts of the foundation.

This is exactly the situation I found myself in several weeks ago as I was trying to figure out why one of my custom do_action events in my BuddyPress Privacy Component was not working as I had expected. My investigation into this issue not only opened my eyes into the inner workings of WordPress’ Plugin API, but also helped me figure out why a few BuddyPress action events were not behaving as intended.

Understanding Hook Firing Sequence

How can you know the firing sequence of action functions or filter functions that you attach to existing WordPress and BuddyPress hooks? Why is this even important?

To answer the second question, read my article, WordPress Hooks, Barbs, and Snags. The answer to the first question is more difficult.

Since many internal WordPress and BuddyPress functions may be tying into the same action or filter hooks, there is no easy way to know the firing sequence of action functions or filter functions. Add to that the fact that 3rd-party external plugins can also tie into these same action or filter hooks and the issue becomes even more murky.

As I had a serious issue with a custom do_action event in my BuddyPress Privacy Component not working as expected, I set out to solve the first question. Although my problem appeared to be with my custom do_action event, I soon discovered that it was caused by another hook to which I had tied in to.

The result of my investigation: a new tool for WordPress and BuddyPress developers called the WordPress Hook Sniffer. What does this plugin do? It helps plugin developers determine the sequence in which action and filter functions are fired, providing a window into the inner workings of the WordPress Plugin API.

As with all of my other WordPress and BuddyPress plugins, this plugin is licensed under the GNU General Public License 3.0 (GPL).

Download WordPress Hook Sniffer and Donate!

You can download the WordPress Hook Sniffer via the WP Plugin Repository. Even more excitingly, you can help me support this plugin, encourage me to create new ones, and enable me to keep living by selecting a sponsorship level below and clicking the “Pay Now” button. Thank you!

Sponsorship Levels

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!

Using the Plugin

WARNING: This plugin is to be used only in a development sandbox and not in a production environment. It is intended solely for use by plugin developers to help determine the sequence in which action and filter functions are fired. Use at your own risk. As this plugin should not be installed on an active WordPress-based site (a production site), no support for broken sites will be given. You have been warned!

As with all plugins, please read the installation instructions in the readme.txt file. You may find the FAQ in the readme.txt file useful. Also, if you have been using an older version of this plugin, the installation process is now much simpler—see this post for details.

1. Once installed and activated, you will find a new menu option in the Settings menu
   
2. Clicking on that will bring up the WordPress Hook Sniffer Settings screen. The first thing to do is look in the upper left-hand corner of the screen. See that gratuitous “Please Support My Work” section? Go ahead and select a nice, juicy amount and then click the “Pay Now” button. Your donation (in any amount) is greatly appreciated! Okay, enough begging.
   
3. Next, read the “Usage Notes” section at the end of this article for a few additional bits of important information
4. Finally, select “Enabled” in the Main Sniffer Settings section, choose what data you wish to view in the Output Options section, and then select where you would like the output to go in the Output Location section
5. It’s that easy!

Output Settings Options

Whereas getting the WordPress Hook Sniffer to work is relatively straight forward, interpreting the output is a different story. What does all of that crap stuff mean?

Here is a brief overview of each of the output options and what information it can provide. However, to truly understand how to interpret the output and how best to use it in your development work, you will need to read my article, WordPress Hooks, Barbs, and Snags article.

A. Added Functions

Selecting this option outputs the special WP Hook Sniffer array that holds, in the order in which they were encountered during code execution, all add_action calls and add_filter calls. The file and line number from which a given function was triggered is also provided.

B. Removed Functions

Selecting this option outputs the special WP Hook Sniffer array that holds, in the order in which they were encountered during code execution, all remove_action calls and remove_filter calls. The file and line number from which a given function was triggered is also provided.

C. Action and Filter Function Array

This is the grandaddy, grandmommy, grandchild, Grand Ole Opry of output data. It contains the output of the $wp_filter array, the array that holds all of the added action and filter functions and is used by the do_action and apply_filters functions call to determine function firing order—although there is a twist here. You must read my article WordPress Hooks, Barbs, and Snags article to learn what it is.

D. Action Event Firing Order

This option contains the output of the $wp_actions array. A simple, one dimensional array that holds the sequential listing of all the do_action events that need to be processed. The events within this array used in conjunction with with corresponding data in the $wp_filter array determines the firing sequence of all action functions

E. Action Event Firing Sequence

Selecting this option outputs the special WP Hook Sniffer array that holds the sequential listing of do_action events with their corresponding fired action function(s). This listing shows you exactly the sequence in which each triggered action event fires its hooked action functions.

F. Filter Event Firing Sequence

Selecting this option outputs the special WP Hook Sniffer array that holds the sequential listing of apply_filters events with their corresponding fired filter function(s). This listing shows you exactly the sequence in which each triggered filter event fires its hooked filter functions.

1. Reporting Bugs: If you find bugs or are having issues using this plugin, you can either post a comment in this article or visit the support forum for this plugin. Assistance in providing patches to this plugin is appreciated.
2. Increasing Precision: If you want to see a more precise accounting of the execution time of a given function, you have to edit your php.ini file to increase the precision displayed for floating point numbers. Search your php.ini file for the entry:

   precision = 12

   and change that to:

   ; precision = 12
precision = 16

   As you can see, I like to comment out any changes to my default php.ini settings just in case I decide to revert the changes later. This allows you to do so easily without having to remember or look up what the default setting is supposed to be.

   Save your modified php.ini file and then restart your development server and you should now see the time-executed stamp displaying 6 significant figures instead of 2. This provides a sufficient level of detail.

3. Text Output Issues: If you’re using SSL or are behind a proxy server, you may have issues when selecting to send the output to a text file. There are a few work arounds for this, but suffice it to say that since this plugin is to be used exclusively in a development sandbox environment, I will not be coding these into the plugin. If you must use this plugin with SSL or behind a proxy server, then simply select the screen output option. You can learn more about this in the PHP manual for the fopen function.
4. Screen Output: When printing to screen, it may take a several seconds for output to finish. The output will start just below your theme’s footer.

This article is my exhaustive study of what I thought was a simple little function—the do_action function. It details how WordPress action hooks really work. It is a long, detailed article. If you want to understanding the inner works of the do_action function, then it will be worth your time. Although this article only briefly mentions the apply_filters function, the lessons learned about the do_action function apply equal as well as the coding of these two functions is nearly identical.

This is not a beginners guide to WordPress action and filter hooks. To benefit from this article, you need to understand what hooks are, why you use them, and how to use them.

Hooks, Barbs, and Snags

Before we start, I need to define two terms. You may be wondering about the title of this article, “WordPress Hooks, Barbs, and Snags.” You should already know the definition of a WordPress hook. But what are barbs and snags?

These are two terms I created to classify the following:

Barbs: salient insights about the functioning of WordPress hooks that stick out and grab your attention. Understanding these barbs help you avoid snags. In this sense, a barb is a good thing.

Snags: WordPress hooks that do not execute as expected, not because the do_action or apply_filters functions are misbehaving, but rather because you do not understand how these functions actually work.

The Hook Loop or Where the Issue Gets Complex

When it comes to code, loops can be tricky constructs to properly implement. What seems like a simple, innocuous operation may actually be more complex than meets the eye. This is the case with the do loops in the do_action and apply_filters functions.

There are two key arrays that WordPress uses to determine the firing sequence of actions and filters— the $wp_actions and $wp_filter arrays. These arrays get built throughout the execution of each page load and are not fully populated until page load is complete and PHP stops execution, waiting for its next command.

The $wp_filter Array

The $wp_filter array is where all added action functions and filter functions are stored for future reference and processing by both the apply_filters function and the do_action function. This array is a very-large, multidimensional array nested to four levels. See the snapshot of the partial contents of this massive array.

Here is a snapshot of what is generated in the $wp_filter array just by navigating to the homepage in my particular setup. Your results will vary depending on which plugins you have activated, which theme you’re using, whether you’re running WordPress in single-site or multi-site mode, whether you’re running BuddyPress, whether a user is logged into your site, and of course which versions of WP / BP you currently have installed.

As you can see, there are a lot of action functions and filter functions listed, each of which result in the grabbing and storing of added actions and filters. Not all of these are necessarily triggered. It is up to the apply_filters and do_action functions to determine which of the referenced functions will be fired.

The $wp_action Array

The $wp_actions array holds all of the current actions invoked by do_action events in the files that are processed when a given page is loaded. Like the $wp_filter array, the contents of this array obviously depend on the page to which a user navigates.

Here is a snapshot of what is generated in the $wp_actions array just by navigating to the homepage in my particular setup.

But read on as knowing about these two arrays is only one aspect to fully understanding the underlying processes, in figuring out the entire puzzle.

Populating the Arrays, Firing the Hooks

Here’s another piece to this complex puzzle. We know that the array $wp_filter holds an array listing all of the currently active action functions and filter functions. But how is this array built?

It’s simple. All action and filter functions that are not enclosed within a function, a loop, or any type of conditional clause currently not triggered, are added sequentially to this array as a given file is executed after it’s loaded (via either an include, include_only, require, or require_only function call). Therefore, as soon as a file is loaded, execution passes to that file and all directly executable add_action, add_filter, remove_action, and remove_filter function calls are processed.

This means that PHP is furiously processing function calls from these four functions, resulting in data being added or removed from the $wp_filter array. When an add_action call is triggered, the parameters are sent to the add_action function in the WP plugin API. When an add_filter call is triggered, the parameters are sent to the add_filter function—and so on.

However, one additional function is called when an add_action call is processed. As soon as the add_action function gets called, it immediately passes on the responsibility to the add_filter function. This means that WordPress looks at action functions and filter functions as the same. This is another key insight and is why both action functions and filter functions are referenced within the same array— the $wp_filter array.

Once the add_filter function gets control, it adds the calling function to the growing list of actions and filters that can be triggered by a given do_action or apply_filters event. This process quickly results in the $wp_filter array growing into a massive, multidimensional array. Of course, action and filter functions can get removed from the array via calls from the remove_action and remove_filter functions.

The reality of code execution is of course more complex. The $wp_filter array is still being populated with action and filter functions when the first do_action events are triggered. This means that it is possible to have a situation where an action or filter that is hooked to a given do_action or apply_filters event will not get triggered if the file in which the hooked function is located has not been loaded before the hook is triggered.

This last point is exactly what was happening in BuddyPress when the bp_init action hook fired. This is the issue that was puzzling me and resulted in this exhaustive study and creation of my new WordPress Hook Sniffer plugin. You can read this BuddyPress Trac ticket to learn more.

A Detailed Analysis to Shed Some Light

Here is a breakdown and partial analysis of the $wp_actions array, the array that holds all of the current actions invoked by do_action events in the files that are processed when the homepage is loaded. We will use this array along with the $wp_filter array to figure out what is really going on.

The contents of this array obviously depends on the page to which a user navigates. This is just what happens when a non-logged-in user visits the homepage of the default BuddyPress theme in my WPMU setup. The only other plugin that is activated is my BuddyPress Privacy Component. For these tests, I am running WPMU 2.9.2 and BuddyPress 1.2.3.

NOTE: To fully understand what is going on, you need to make sure that you are looking at the completed arrays and not the partial arrays grabbed partway through page-load.

Let’s look at the order in which do_action events will be triggered. We will analyze what is happening in the first four elements of the $wp_actions array (index value of “0” through “3”). How is each action triggered and what are the results? This will start off as a detailed look into each hook’s actions, but will provide fewer details with each additional event as the basic processes become evident.

The First Four Triggered Action Events

[0] => muplugins_loaded

[3] => bp_setup_root_components


[0] => muplugins_loaded

When a user navigates to the homepage of a default BuddyPress install running on top of WPMU, the first action hook that is invoked is muplugins_loaded. This is directly triggered on line 547 in wp-settings.php. Any added actions that are tied to this event will next be triggered.

Looking at the $wp_filter array, you will see that there are no actions tied to this hook. This means that there is no subarray element with a key name of muplugins_loaded. In other words, you will not find any reference to that action event within the $wp_filter array. So, this action event does not result in any action functions getting fired.

NOTE: A triggered hook may or may not have actions tied to it. If no actions are tied to the hook, the do_action routine passes by that hook, checking the next invoked hook for added action functions to fire.

Before the next action event is triggered, something important happens.

Execution of the wp-settings.php file continues. On line 703 of wp-settings.php, all the active plugins are loaded—both blog specific plugins and site-wide plugins.

If you look at that line, $current_plugins can be modified by any added filters. That is what happens. On line 2348 of wpmu-functions.php, an add_filter call triggers function mu_filter_plugins_list. This filter modifies the contents of $current_plugins, adding any MU plugins that have been activated site wide. Processing is returned wp-settings.php, resulting in the main file of each activated plugin getting loaded.

There is an interesting item to notice within function mu_filter_plugins_list. On line 2345 of that function, the two arrays $active_plugins and $active_sitewide_plugins are merged and the resultant new array is sorted.

What does this mean? It means that when it comes to the issue of action and filter sequence firing, it does not matter which plugins you activate first. The order in which plugins are added to each of the serialized objects active_plugins and active_sitewide_plugins is immaterial. The sort function will alphabetically reorder the contents of the merged array.

NOTE: Each WPMU blog has it’s own listing of active plugins that are stored in a serialized object in the blog’s wp_x_options table. Look for the entry “active_plugins” within the option_name field of that table. The corresponding active plugins are in the option_value field of that record. All plugins that are to be activated site wide within WPMU are stored in a serialized object in the wp_sitemeta table. Look for the entry “active_sitewide_plugins” within the meta_key field of that table and the corresponding plugins that are to be activated site wide in the meta_value field of that record.

So, in our particular case with two site-wide plugins installed and activated (buddypress and bp-authz), the order in which they were activated is immaterial in determining which file is included (loaded) first by the conditional loop code starting on line 704 of wp-settings.php.

If you look in the wp_sitemeta table for the meta_key “active_sitewide_plugins”, you will see this:

a:2:{s:24:"buddypress/bp-loader.php";i:1270239897;s:28:"bp-authz/bp-authz-loader.php";i:1270396554;}

BuddyPress appears first because I activated it first—as is necessary. But, when the references to these two main plugin files are processed through the mu_filter_plugins_list function, they get sorted. This results in bp-authz-loader.php getting loaded before bp-loader.php.

This could be a big issue as all BP-dependent plugins rely on BuddyPress to be installed, activated, and loaded. Any BP-dependent plugin that comes alphabetically before “buddypress” will have their main file loaded before BuddyPress’ main file.

Barb 1: As a BuddyPress plugin developer, this is the first major insight, the first important barb that can prevent your code from hitting a snag with regards to action and filter execution.

Fortunately, there is an easy way to prevent this barb from snagging you and those that use your plugin. Make sure that BuddyPress is active before your plugin loads its core files.

Since that is exactly what I’ve done with my BuddyPress Privacy Component, there are no issues and execution quickly passes back to the loop and the next file in the $current_plugins array is loaded. This is the main BuddyPress file, bp-loader.php.

[1] => bp_core_loaded

Execution of bp-loader.php begins. On line 22 of bp-loader.php, the first custom BuddyPress action event is invoked:

do_action( 'bp_core_loaded' );

It is directly invoked, directly triggered. It is not enclosed within a function, a loop, or any type of conditional clause. This invoked event is what appears in the second element of the $wp_actions array.

Since there are currently no tied-in actions to this particular action event (as can be easily determined by looking at the $wp_filter array), the invocation of this action does not result in further actions being triggered.

The execution of bp-loader.php continues. Right after line 22, a series of conditional clauses include (load) all enabled BuddyPress modules—activity, blogs, forums, friends, groups, messages, xprofile.

As each of these files are included (loaded), any directly invoked (directly triggered) action events within each of them will also be invoked. Since there are no additional, directly invokable do_action calls within any of these files, execution is passed back to wp-settings.php.

[2] =>plugins_loaded

On line 735 in wp-settings.php, the do_action event for plugins_loaded is directly triggered.

do_action('plugins_loaded');

This is when things really start to accelerate. Up until this time, only a few lines of php code within BuddyPress have actually been run.

With the invocation of the plugins_loaded event, we now have our first action hook that has actions tied to it. Understanding what happens next leads us to the second major insight, the second important barb.

To understand what happens next, we need to inspect the elements within the plugins_loaded array of the $wp_filter array. I have extracted just that subarray element below:

plugins_loaded:
Array
(
[0] => Array
(

)


This array element is itself a multidimensional nested array. In fact, the first element (with an index value of “0”) has two action functions referenced.

An important point: each subarray of the $wp_filter array is a numeric array. Read that again. This means that the second level of the nested $wp_filter array contains numeric arrays.

You might be wondering how the index values for these numeric arrays are set. This is simple.

The key, the index value, of each 2nd-level array element is determined by the priority assigned to the event in the add_action and add_filter call. Thus, the priority set for a given action or filter function becomes the key of each element in a given hook’s multidimensional array. If a priority is not set for a given add_action or add_filter call, it is automatically defaulted to “10”. This means that any and all added actions or filters that do not specify a priority are automatically assigned to the proper action array element with an index value of “10”.

As an example, if the priority for a given added action is set to “16”, then that particular action function will be located in the array element for that action with an index value of “16”. Multiple action functions can be added under the same index value, creating an array of action functions associated with the same numeric key element. The order in which they appear is determined by the order in which they were executed.

Barb 2: This is the second major insight, the second important barb that can prevent your code from hitting a snag with regards to action and filter execution.

Now, the next piece of the puzzle is this. The order in which action functions are added to a given action array element is determined by the order in which they are encountered, the order in which their corresponding add_action or add_filter calls were fired. As we will see below, this is what makes determining the firing order of added actions and filters difficult.

Barb 3: This is the third major insight, the third important barb that can prevent your code from hitting a snag with regards to action and filter execution.

Barb 4: The higher the index key, the later the action or filter functions within that index-key grouping will get fired. Therefore, using the example above, if we set a priority of “16” for a given action function, it would get fired only after all the other action functions with a lower priority have been fired.

We have now reached the final piece of the puzzle!

Near the beginning of this article, the complexity of the do loops within the do_action and apply_filters functions was briefly mentioned. And it is within those loops that this story really finally gets resolved.

If you look at lines 166 (within the apply_filters function) and line 339 (within the do_action function) of the wp-includes/plugin.php file, you will find the code lines where the actual hooked functions are fired. Do you see the call_user_func_array() function call? That is a core PHP function. It is what will actually fire the next action or filter function in line, as determined by the data in the $wp_filter array.

The action of the call_user_func_array() function nested within the do loop is not as simple as it may seem. Why is this? Well, currently we are discussing the plugins_loaded action event and all of the tied into functions that get fired.

Look at the next action event to get triggered within the $wp_actions array. It is the action event bp_setup_root_components. But wait. Why is there another action event being triggered? We have not yet finished iterating through all of the added action functions to the plugins_loaded action event.

Once again, the reason is simple. Triggered action functions can themselves have action events. Inspecting the plugins_loaded subarray in the $wp_filter array, we see that the bp_setup_root_components action function is invoked by the plugins_loaded event via an added action call on line 2021 in bp-core.php. Within that action function there is an action event called bp_setup_root_components.

So, the sequential processing of all the added action functions with the plugins_loaded subarray of the $wp_filter function has come across a new action event to trigger. It now gets priority and further processing of the plugins_loaded subarray is put on hold until the bp_setup_root_components action event is finished processing its added action functions.

Barb 5: This can quickly result in a nested grouping of action events with the firing of their corresponding action functions. This is the final piece to the puzzle and the last and final barb that can prevent your code from hitting a snag with regards to action and filter execution.

As you are reading this, the juxtaposed actions of the do loop with the call_user_func_array() function more than likely seem obvious. It may seem this is not unexpected behavior or difficult to understand.

Whereas that is the case when all of the data is clearly laid out before you, the complex actions of these intertwined functions are not apparent when you are coding a plugin. There is no practical way to peek inside this action-event, action-function feedback loop.

This is were the true value of the WordPress Hook Sniffer plugin is revealed.

[3] => bp_setup_root_components

Here’s where we understand the last piece to this confusing puzzle.

Inspecting the $wp_filter array for this action event you will see that there are four action functions that are hooked to this action event: bp_activity_setup_root_component, bp_blogs_setup_root_component, bp_forums_setup_root_component, groups_setup_root_component.

These action functions are fired in that sequence. Since they do not have any action events which they trigger, control is passed back to the plugins_loaded event and the next action function in the plugins_loaded subarray is fired.

Applying the Lessons

When interpreting the results of the WoodPress Hook Sniffer plugin, you need to look at the output of the $wp_actions array and then search out the hooked actions to each of those items (if any) in the $wp_filter array. This will give you a general idea of what gets fired when. You can then experiment and see how changes to action priorities affect the firing sequence of a given added action.

You need to carefully think about the execution timing of each action or filter you add, looking at the corresponding triggering event for the hook or hooks to which it’s tied. Remember, you can hook a function to more than one hook which means that it is possible, if you are not careful, that some of them may fire whereas others may not. It’s all a matter of whether or not the reference to the action or filter function was successfully added to the $wp_filter array before the associated hook is triggered.

Looking at the Action Event Firing Sequence and the Filter Event Firing Sequence will help you precisely tune your added hooks and filters. Remember that execution my temporarily pass to another action or filter event. The output of these two WordPress Hook Sniffer arrays will show you when that happens.

Finally, there is no requirement that you place your add_action and add_filter calls right below the functions in which they are associated. Whereas doing so does facilitate code understanding, you could instead place them all at the top of the file (or the bottom) in which the associated functions are located. Remember, each add_action and add_filter function call that is directly executable is processed as soon as a file is loaded. So it does not matter where within the file those calls are located—with the possible exception of fine tuning the execution order of a particular function.

Final Notes on the $wp_filter and $wp_actions Arrays

The arrays $wp_filter and $wp_actions are repopulated from scratch each time a page is loaded. They do not contain a running accounting of all action and filter functions and all action and filter hooks. The contents of both of these arrays may vary depending on which page you navigate. The contents will depend on the files that are loaded (via include, include_only, require, require_only) when a given page you are on is displayed.

The reality is that, when visiting a given page, there will always be more hooks, action, and filter functions buried deep inside non-loaded files or within function blocks that are not directly hooked. The first is a result of the add_action, remove_action, add_filter, or remove_filter calls not getting fired until that file is loaded. At file load, any directly-executable do_action or apply_filters will be triggered as well. The second is the result of functions that have hooks that only get triggered if the file is loaded and the function is fired.

Although the WP Hook Sniffer will locate all action and filter hooks, and action and filter functions no mater the source–core files, custom themes, or 3rd-party plugins–what is captured depends on one simple rule—that the hooks and function calls are actually fired during page load.

As an example, WP Hook Sniffer cannot locate add_action calls that get fired on a different page than the currently loaded page. It can also not locate add_action calls that are buried inside a function that does not get triggered unless a special criteria is met. To sniff out those added actions, you have to navigate to that page so that those calls get fired or cause the special criteria to be met so that the function containing the buried action call is triggered.

Remember, the way that the WordPress Plugin API processes added and removed actions and filters is by storing (or deleting) a reference to them in the $wp_filter array. But that only happens for hooked functions that are actually encountered during page load. The $wp_filter array is wiped clean with each page load and rebuilt from scratch. The same holds true for the $wp_actions array and the action hooks it tracks.

Therefore, if you have action or filter functions that are supposed to be fired on a given page but you are not seeing that they’ve been fired, then that indicates that they are hooked to an action or filter event that finishes firing before the file in which the target action or filter functions are located even gets loaded. This is exactly what happened to me and caused me to write WP Hook Sniffer.

Summary of Barbs: the Key Insights

1. When it comes to the issue of action function and filter function sequence firing, it does not matter which plugins you activate first.

2. The key, the index value, of each 2nd-level array element within the $wp_filter array is determined by the priority assigned to the event in the add_action and add_filter call.

3. The order in which action functions and filter functions are added to a given action or filter subarray element in the $wp_filter array is determined by the order in which they are encountered during code execution.

4. The higher the index key, the later the action or filter functions within that index-key grouping will get fired.

5. Action hooks (events) –> trigger action functions –> which can have additional action hooks –> which can trigger additional action functions –> until control is passed back to the the originally-triggering action hook.

This is the action-event, action-function feedback loop caused by the juxtaposed actions of the do loop with the call_user_func_array() function.

It is interesting how some people quickly jumped to conclusions and made sweeping assumptions based on a single blog article, or worse yet, blog title. Although the majority of people who have taken the time to comment or tweet about this post have been positive about my efforts, a small minority (across the age spectrum), have been negative, even seemingly offended.

I’ve concluded that this latter group must not have read the post in its entirety. In fact, it is very possible that they got emotionally thrown-off guard by the title and didn’t bother reading the post at all. The other likely scenario is that they only read the first half of the post and found it disagreeable so they did not finish reading the rest.

Either way, it is a shame when people make accusations–are prejudiced–based on a few words. It is an unfortunate fact that some people will judged you on little more than a few words or sentences. They will not take the time to learn more about who you are before rendering an opinion.

Now I have thick skin. When you’ve been through a life-threatening illness, not sure whether you would live another year, you learn what is truly important and are able to filter out most impacts of personal attacks, illogical drivel, and emotionally-charged, incorrect assertions.

Marketing Message

Although the title of my post was somewhat sensational, it did speak directly to the issue of ageism in the VC-funding of web startups. This is a real issue.

But, my article only used that issue to build a bridge to the larger point—that what matters in startup founders in not age, but their experience, skills, and maturity. In fact, near the end of my piece I state this:

Now, I am not an ageist by any stretch of the imagination. So, if you’re an exceptional under-35 year old who is interested in this opportunity, send an email convincing me that you’re the one I should pick. You will still be required to meet all the requirements except age.

So, when it comes to my search for exceptionally-talented startup partners, this post is really not about age. I’ll gladly consider anyone, regardless of their age—although when choosing a founder, the experience-bar must be set higher.

Rash Decisions Are Not Good Decisions

The fact that someone tweeted today calling me “utterly pompous” for my statements in that article, does not surprise me nor upset me. Whenever someone sends a negative tweet about something I’ve said or written, I always engage them in respectful debate. Some will reply, a few simply ignore my tweets. My purpose is to better communicate my original message and learn what in particular set them off.

When I received that tweet this morning, I sent off three, quick tweets encouraging him to read the whole article and explaining that the major point of that piece was that I’m looking for two experienced people with the skills to be founders. I told him that it was really not about age at all.

He eventually sent another tweet back but has not yet recanted his remark. That’s fine. He’s entitled to his opinion. I have big enough shoulders. If I’m ever in need of the services his firm offers, I’ll fully assess the firm’s strengths and weakness. I will not jump to conclusions based on the little interaction that I’ve had with one of its partners.

This experience made me realize another essential quality of a great leader—to be slow to judgement. If you are too quick to judge, then you are likely a person that misses key information that could make a difference to your business’ success. You may be prone to letting emotions influence your judgement too much. Instead of making a rash assumption about a person, project, or opportunity, do your homework. Properly assess the situation so you know as much of the truth as possible before making your decision.

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?

Since I am not hiring employees, I am not breaking anti-discrimination laws. I am not making job offers. I am searching for business partners with whom to start a business. So, I can use whatever criteria I want in selecting my startup partners.

In the days that followed that post, Dave brought up more issues of ageism—in particular venture funding in the realm of tech startups. On Wednesday, January 13, 2009, Dave tweeted this quote, taken from an article about Douglas Leone, a partner at Sequoia Capital:

“Sequoia focuses on younger entrepreneurs because people over 30 aren’t innovative.” http://r2.ly/red7

Wow! I guess Pablo Picasso, Richard Feynman, Steve Jobs, James Cameron, and hundreds of thousand of other post-30 innovators, never realized that their creativity and innovative spirits had dried up once they hit 30. Shame on them. They all should have been sent to the Soylent Corporation’s processing plant once they hit 30-years old.

If you read the article linked to in the tweet, you’ll get the full picture of what was being said. But the point is, that when it comes to web startups, especially those in the social media space, ageism is an issue.

( N.B. If you have made it this far in the article and your blood is beginning to boil, read this newer post for a sneak peek at the message behind the headline.)

Fifty is the New Forty; Thirty is the New Twenty

So, why am I looking for founding partners 35-plus years of age?

In my two previous jobs, I managed teams of people; I managed managers who managed teams of people. It was a rare exception when I found someone under the age of 30 who was sufficiently focused, task-oriented, dependable, experienced, and knew what they wanted. When I did find someone like that, I knew that I had a potential project manager and someone who might be able to be mentored to become a possible future executive.

Now that does not imply that most people over the age of 30 have what it takes to manage projects, to lead a team of people, to start a company. Most of them do not. It is simply that my empirical evidence convinced me, when it came to a professional life, most people under the age of 30 still had some growing up to do—and some of those had a long ways to go.

All under-30, professional-level employees have fewer than 10 years of work experience. Most are still very green and have much to learn about work ethos, teamwork, project management, and leadership. The other big issue is that many under-30 employees have yet to perfect an effective, proactive communication style. Finally, experience comes with discipline, hard work, learning from mistakes, and age. And experience is more valuable than raw, young talent in my book.

Don’t get me wrong. Young employees are important to a healthy, vibrant business. But a company full of only young employees is a company that is most likely inefficient and prone at making mistakes that a business with a diverse, well-seasoned workforce would never make. This applies to old firms as well as new startups.

The Company, The Opportunity

My startup is in the Publishing 2.0 space. That is all I will say for now.

I have an detailed concept paper describing the underlying vision and functionality. It is not a business plan. At this stage in a startup’s life, business plans are not necessary. If you don’t understand that statement, or understand why, then this opportunity is not for you.

You must know the differences between working at a startup and working for a small business. Whereas all startups are (usually) considered small businesses, very few small businesses are startups. If you do not clearly understand the differences, then this opportunity is not for you.

Each founder is required to provide their own hardware and software. As we will be using a number of Open Source tools for designing, coding, implementing, managing, and running the platform, the need for proprietary software should be limited.

The earliest stages of this startup will be self-funded. It should not require much initial infusion of capital beyond what is needed for hosting and membership in a few select collaborative services. I plan to run a very lean startup. The mid-term goal is to bootstrap the startup, thereby not requiring any angel or venture funding. However, I am not opposed to either if it makes sense down the road.

As this is a startup with zero outside investment and will initially have zero cash flow, founders will not receive any salary or benefits at first. You must be able to meet adequately your personal financial responsibilities and have a sufficient savings cushion to live in this way for at least 6 to 12 months. If that is not possible, if that concerns you, then this opportunity is not for you.

Founders will be owners of the company. Percent ownership will be negotiated with me on an individual basis. Stock options will also be made available.

Our company will strive to determine as quickly as possible the right fit of functionality and service for our intended target demographic. We will do this through analyzing metrics and customer development data obtained over a series of incremental launches (iterations of our platform). The initial goal will be to get a minimally viable service built as quickly as possible so that we can begin this process. We’ll then scale up our platform and service, leveraging our learned intelligence.

What I’m Seeking

In particular, I’m looking to create an energetic team that will function as generalist. We will build the initial, working technology platform, and create the business foundation.

Whereas each member of our team will have a specific, unique skill set that complements the overall startup process, there will be necessary overlap in the area of coding knowledge. This means that each team member must have sufficient Web coding experience, although only one of us truly needs to be an expert-level developer.

In the earliest stages of a Web-based startup, generalists often perform better than specialists. But, as we begin to successfully acquire members and bootstrap the business, we will hire (additional) specialists.

Here are the basic requirements (not listed in any particular order of importance):

Required of all Founders

• Must be 35-plus years of age
• High energy, positive personality
• A killer work ethic (days will be long)
• Ability to work independently
• Adept at creative problem solving
• Proven creative, innovative, independent thinking
• Ability to work initially for zero salary or benefits (this could last 6 or more months)
• Sufficient comfort level with back-end PHP coding and front-end design
• Project management experience
• Must live in the contiguous United States—for travel purposes
• Must be a citizen of the United States—for legal purposes
• Must have a computer with a video camera and high-speed Internet access
• Thrive in taking measured risks
• A healthy savings from which you can survive off of for at least 12 months
• Respectful, proactive communication style
• Easy to communicate with and a good, active listener
• Understanding that there are no guarantees of success
• Must be willing to travel to meet in person a few times in the first 6 months
• You cannot be in arrears with local, state, or federal tax institutions
• You cannot be a defendant in any pending or active lawsuit
• Founders will share corporate risk and liability
• Founders will sign shareholders’ agreement
• Must be results-oriented, focused, tenacious, and driven

More Specific Requirements—Coder, lead-developer

• At least one coder with significant experience in OOP MVC Python-based frameworks (PHP considered as well)
• Experience and knowledge of DB design theory and practice—ERDs, normalization, sharding, etc.
• Experience with PostgreSQL
• Experience with Web security
• Experience with agile development

More Specific Requirements—Designer

• CSS and HTML guru
• Ability to resolve browser-specific rendering issues
• Keen eye for clean, uncluttered, Web-2.0 style design
• A stickler for designs that validate
• User-friendly UI/UX maven

Not Required but a Plus (one or more)

• Previous startup experience as a founder
• Previous early-stage startup experience as an employee
• Extensive, high-level contacts in the New York book publishing Industry
• Understanding of Semantic Web and experience with semantic technologies
• Past P&L responsibility
• Previous position as CTO
• Law or MBA degree
• You are a Mac person

Not An Issue

• Married/unmarried with kids
• Desire not to relocate
• Desire to get some sleep each night
• It’s okay if you’re a PC person

I spent years in the PC world designing custom database solutions for big companies, I now prefer Macs. In fact, I have three Macs that I use for development. I no longer own a PC—which I have found to be a nice relief.

Now, I am not an ageist by any stretch of the imagination. So, if you’re an exceptional under-35 year old who is interested in this opportunity, send an email convincing me that you’re the one I should pick. You will still be required to meet all the requirements except age.

If Interested, Here’s What you Need to Know and Do

If you are not a highly-motivated, creative, driven, risk-tolerant, tenacious, tireless worker, then this opportunity is not for you.

This is not a job posting. It is a potential opportunity to become a startup founder.

If you are interested in being considered for a slot as one of three founders, ping me here no later than February 6, 2009.

In the body of your (brief) email tell me why this opportunity intrigues you and what experience and skills you bring to the table. Please include a link to your “About Me” page on your website (I prefer that over a digital resume). Include your Twitter and LinkedIn usernames. Finally, include your Skype or iChat contact details so that, if I think it desirable, we can have a video conference.

I will seriously review each potential candidate and make a short list of those with whom I wish to have a video conference. I retain the right to make the final decision on selection of partners. I do not guarantee that I will select any of the candidates who apply. I will not add another founder until I’ve found the right fit.

UPDATE: January 19, 2010 A year after this post and here are the results. See my current thoughts on this issue in this article, BP Privacy: History and Lessons Learned from Developing a Major BuddyPress Component.

I think it is not only fair and appropriate, but also necessary for plugin developers to have the opportunity to make a living, or at least part of their living, writing great code that extends the base functionality of the BuddyPress platform.

To be clear, I am not an employee of Automattic. Like the vast majority of BuddyPress developers, I do not get paid a single cent for my contributions. In fact, as a salaried employee of Automattic, Andy Peatling, the lead developer of BuddyPress, is the only one who gets paid for his time working on this Open Source project (as far as I know).

Again, I am not looking to fan the embers of previous debates. I do not have any issue with how Automattic runs the WP plugin repository or care if they never list commercial plugins. That is not my point.

All I’m asking is how can plugin developers exist on an equal footing with theme designers when it comes to the issue of earning a living? Currently, the only three options that developers have, it seems, are to advertise a donate button for each plugin, accept consulting gigs, or accept advertising on their website. But donate buttons rarely provide much support and providing consulting services to clients is not for everyone. Furthermore, for me, I do not care to turn my personal website into a billboard.

The argument that plugin developers benefit by offering their work for free is flawed. It assumes that all developers are looking for consulting work, and two that all developers who offer their work for free will receive consulting work. Whereas it is certainly the case that some plugin developers have built a nice consulting business as a result of their donated work in the WordPress community, that does not mean that this route is for everyone.

What if a developer just wishes to code great-quality plugins like a theme designer designs high-quality themes? What if he or she does not want to provide any other service? How should this developer be compensated for their time?

But, since you asked, I do have a donate-like button for my BuddyPress Privacy Component. You can read more about my version of “donate” here.

I would like to hear some ideas on this topic as I have contributed much time to the BuddyPress community but have not earned a single penny. I am not looking to provide programming services or start a consulting company. I have a significant project that I’m working on so I don’t have time for much else.

Since I am not yet making an money on my project, I need a vehicle to earn some semblance of a respectable cash flow. Just as some theme designers earn a decent income from their premium themes, I would like to think that my income vehicle could be BuddyPress component development.

So, ideas and civil discussion, please!