As a consulting company, we tracked each hour of each employee’s day. We knew what they did and for how long they did it. We could calculate an employee’s total number of hours worked per year, average hours worked per day/week/month, what activities they spent most of their time focused doing, and therefore, each employee’s chargeability. That is consulting slang for how much profit we could squeeze out of each lemon employee.

As it turned out, I had some leverage concerning the big disagreement that I had with my partners on this yet-to-be-revealed work-style issue. For each of the years I worked at the firm (except for the first year), I had the highest average working-hours-per-month total out of all the employees in the firm (over a hundred). To make matters worse (from my partners’ perspective), the division with which I had P & L responsibility was not only the most profitable in percentage terms but also in real dollars. Finally, before I came along, this division had never turned a profit and was a significant cash sink from the corporate coffers. I turned my division around in 18 months and it stayed strong from that point on.

So, when I did or suggested something that was not popular, I managed to at least get a slight pause and a few moments of consideration before the arguing would begin. I was a stellar model of an exemplary employee, manager, and director. But to most of my fellow partners, I was not a stellar example of a partner. Why? Because I was seen as the maverick who not only looked at things differently, but also who was constantly trying to stir things up.

Of course, I was trying to evolve the corporate culture so that our employees would enjoy their time at the company, so that they would have less stress, so that they would not only feel more appreciated but would actually be more appreciated. This would lead to greater productivity, faster growth, and more profits. My partners could not see this.

The Big Work Style Issue Revealed

I never liked the inherent, non-spoken, holier-than-thou, outdated and absurd mantra, and sacred covenant that businesses and their employees buy into — that it is not appropriate for employees to bring their home issues to work. Whereas it of course can be distracting to the productivity of the workforce when an employee lets her or his personal issues mix with their work issues, we are human beings after all and it is almost impossible — except maybe for true sociopaths — to avoid periodically letting home life impact work life. Furthermore, companies never have issues with employees bringing their work life and issues home. In fact, for most white-collared workers, it is often expected that you will always be available for contact when you are at home or on vacation. This is a double standard with which I could not tolerate.

To that end, I did two things that most partners at successful consulting firms would never dream of doing — mostly because they would view it as abhorrent and unprofessional behavior. 

First, I allowed my employees to bring their personal lives to work. I sat down with employees who were having a bad day, week, or month as a result of personal issues at home or their own serious health issues. I became someone who did not frown upon those who showed vulnerabilities. Second, I used each and everyone of my vacation days each year and did not allow my firm to contact me when I was on vacation.

It is unfortunate that most employees feel that by not taking all their allotted and earned vacation days, that it shows dedication. Employees also often sub optimize their vacation days taken as they feel that their managers frown on them when they use their vacation days. To me, however, I knew that I earned and deserved each and every one of those vacation days — and even more.

So, I took all my vacation days each year and would leave explicit instruction with my employees and partners not to call me. I made that especially easy as my wife and I usually traveled to an exotic, remote locale where it would be very difficult — if not impossible — to contact me. I also strongly encouraged each of my employees to use all of their vacation days each year (some did, some did not). I even promoted this practice outside of my division, although it was up to my partners to allow that for their employees.

Why did I do this? Because our employees deserved the time off. They earned it. I also believed that if someone could not afford to take all of their earned vacation days in a given year, then that meant that either they were poor time managers or, that we needed to hire more quality employees to distribute the workload.

Most employers give vacation allotments as an incentive but then when it comes time for an employee to use them, they make the employee feel guilty. However, they appreciate employees who underutilize time off. In fact, they use an awful trick to “reward” them for not using vacation days — they pay them for those days. Of course, this is a much better deal for the employers than the employee. An employer expects to earn a profit for each hour an employee works. So, paying them not to take their vacation days results in them making more money than if that employee had taken the vacation day.

Stirring The Pot To Make Gold

I stirred up the pot in other ways as well. I fought to share a larger portion of profits in an equitably manner with each employee (and not in the ridiculously formulaic way in which it was done — and then, not with any regularity or real fairness). I pushed for better wages and salaries. I argued that the company should award more aggressive bonuses. I even lobbied to have our employees treated and viewed as assets instead of resources.

Resources, after all, are something that is mined, consumed, and then discarded when every last drop of usefulness has been extracted. The phrase Human Capital was just beginning to come into vogue, but I disliked that term just as much as Human Resources. Capital expenditures are depreciable investments. No, instead I pushed, with very little success, to be innovators in the HR field, to treat and view our employees as appreciable assets.

Fight For Your Life

So, if you are a startup founder, a partner, manager, or lower-lever employee, do you live for work or work to live? It is up to each of you to decide how you are treated and to treat others in a way that lets them thrive, grow, and lead a life in which work is not viewed as an all-consuming necessity but instead is welcomed as a wonderful partner in achieving personal and family goals.

Comments?

Please feel free to comment below or join the active conversation on this article on Google Plus.

Image Credits

Royalty-free image thanks to Image: digitalart / FreeDigitalPhotos.net

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:

NOTE: You may need to change the mampstack version number below if you are installing a newer version — in other words, a version that came out after this article was posted or updated. It is currently updated for MAMPStack version 5.3.10-1 and PostgreSQL Module Addon 5.3.10-1.

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.10-1/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.10-1/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.10-1/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.10-1/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.10-1/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.10-1/mongo ). In that file, add the following:

   Important Note: You can copy the entire text below and paste it into your new, empty mongodb.conf file. However, before saving and closing this file, make sure there are no spaces on the blank lines between the code blocks. If you have even a single space on a blank line — or even after a command line — your Mongo server will not start up as it will believe the line with a space is a command line. It will not know how to interpret this phantom command. So, when attempting to start your Mongo server in step 6 below, if you receive this error, error command line: unrecognized line in ‘ ’, that means you have a space somewhere in this file. Find it, delete it, and try again. As much as I tried, I could not get the Syntax Highlighter to create the below text without adding an extra space between lines.

   # Store data in default MongoDB directory structure, /data/db/
   dbpath = /Applications/mampstack-5.3.10-1/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.10-1/mongo/mongodb.log
   
   # Set location of pid file; this should create one if it does not exist
   pidfilepath = /Applications/mampstack-5.3.10-1/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.10-1/mongo/bin/mongod --config=/Applications/mampstack-5.3.10-1/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 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.

I want to address an odd trend–although it’s not yet clear if this actually is a trend. Over the past several months, I’ve heard similar statements from several unrelated Internet startups—the notion that they are not tech startups.

Instead of thinking of themselves as tech startups, they believe they have a higher-calling, claiming to be some flavor of socially-focused company. This may be the result of more and more non-tech-oriented business people forming Internet-based startups, but whatever the cause, in my opinion, it must be nipped in the bud.

Now if I had heard that sentiment from two unrelated parties, I would not think much about it. But hearing that statement from several unrelated parties has made me pause and think.

The Rise of the Data Civilization

In the conclusion of Stephen Wolfram’s excellent article entitled Advance of the Data Civilization: A Timeline, he states that the “systematization of data and knowledge provides core infrastructure for the world.” Technologies have evolved over time, increasing the rate of collection, processing, and dissemination of that data to help turn them into knowledge.

To our globally-connected and insatiably data-hungry community, in my view, the Internet is perhaps the most relevant class of innovation. The Internet is becoming not only the preferred repository of most of our data but also the accelerator of the systematization of data and knowledge that Wolfram discusses. Our civilization is more dependent on data today than ever before—and that dependence will continue to increase.

As humanity races toward the Internet of Things, data–and lots of it (big data)–will be a fundamental supporting sublayer to our everyday lives. The Internet is becoming the platform on which our society, culture, and economy depends. The Internet is an essential partner in much of our current and future innovations. Don’t discount the importance of the Internet and its underlying technologies. Technology is at the core of our society’s future and your smartup’s success.

Technology as Platform, Engine, and Change Agent

All Internet-obligate companies have some type of a vision and mission, usually backed by a set of closely-held ideals that flavor their implementation of that vision. Whatever that vision may be, the fundamental foundation of any smartup is its technological platform. But as you’ll discover in the Layer’s of the Smartup Stack article, the platform does encompass more than just core code technology.

The technological platform though is at the center of, the innermost layer of, the smartup stack. Why is this the case? Because technology is the enabler of the wonderful and fantastic vision your smartup has for the world. Your smartup plans to leverage the power, reach, and socially-transmutational forces of the Internet. To do so requires that you envelope your vision with those technologies that can help bring your vision to fruition.

Whereas it is fabulous that you want to change the world, your Internet-obligate company mandates a technological base. Make sure that base is as strong as it can be. Architect it properly and build it correctly from the start.

Don’t let some branding game cloud your judgement about the key components to your smartup’s future. Remember that your company is at the startup stage. It is not at the growth to maturity stage. You are building the foundation of your vision—a vision that should indisputably be much greater than its technological underpinnings and will be if you do it right. But in order to get to that next stage, you need to come to terms with the seeds of your humble beginnings. There will be plenty of time to expand your focus, to embrace your greater ideals.

Conclusion

It is clear that technology is integral to all Social Web platforms. As smartups are Internet-obligate endeavors, they must be firmly grounded in a tech core. But smartups are greater than the sum of their technologies. The fifth installment of my smartup series lays out the greater ecosystem vision that all startups should strive to embrace. Please read, Building the Social Web: the Layers of the Smartup Stack.

Outside Resources

Here’s a great article by Steve Blank, The Startup Team. The composition of your founding startup team is instrumental to your success — or lack thereof. Technology must be represented on that founding team or you may be in for an unpleasant surprise.

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.

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!

Whereas it is clear that a person who can be classified as a reluctant leader is currently a bad fit for the position, the brunt of the responsibility falls on the shoulders of that person’s immediate superior. Should they have been hired or promoted to project manager in the first place? Did they receive proper guidance and training? Were clear expectations and responsibilities proactively communicated?

Project Manager versus Managing a Project

In smaller firms, a person who is called a project manager may actually be a single person working on a single project. In that case, whereas they are managing a project, they are not truly a project manager. Project mangers usually oversee more than one project at a time and have a team of people whom they lead.

When a company’s backlog grows large enough, it is crucial to appoint a few, results-oriented project managers. Each project manager leads their own team of people. Each project team is tasked with handling a number of the firm’s overall projects in the backlog. The project manager will delegate various chunks of a project’s workload to the team, only keeping a small portion of the project work to his or herself.

Signs of a Reluctant Leader

To me, one of the telltale signs of a reluctant leader is that they would rather be doing the “real” project work and not that “other stuff”. How is that desire communicated? In different ways, but often like this.

When sitting in a meeting discussing a project issue, that project manager seems uncomfortable, maybe even frequently looking at their watch. They finally get the guts to say, “I need to get to work on the project,” or “can we end this discussion because I have to get back to work.”

It is not uncommon for reluctant leaders to assume that all the other duties of a project manager are subordinated to the project work itself. What they fail to realize is that successful project managers have many responsibilities that must equally be performed. Their share of an overall project’s work is just one of many duties.

Successful Project Managers

Successful project managers need to be proficient multitaskers. They need to accept as well as give constructive feedback; proactively communicate with clients and employees; build motivated, results-oriented project teams; sell their vision to their team, to clients, and to recruits; have a passion for leadership; and derive a good portion of their energy from coaching team members and helping each member reach their potential.

In addition to these basic requirements, successful project managers need to manage project chargeability (if measured), organize and lead team meetings, and oversee their share of an organization’s strategic plan. They also need to be results oriented, handle difficult employee issues, and oversee project QA/QC.

A project manager needs to respond in a timely fashion to all team-member inquires—even if it is uncomfortable to them based on his or her communication style. It is imperative that project managers provide clear guidance and direction, effectively delegate the work load, and, finally, perform their share of the project work—what reluctant leaders call the “real” project work.

What Makes a Project In Itself Successful?

Well, that depends on the overall goals for a given project. But a general definition is as follows: hitting the profitability goal, completing the project on time and on budget, and achieving more than satisfactory results for all parties.

In the end, it is up to a project manager’s superior to hold them accountable for project successes and failures. By doing so, it increases the success rate of future projects and can help mold a reluctant leader into a successful project manager.