The Story of SharePress and the Future of Social Media

To know where we’re going, we have to understand from where we’ve come.

SharePress was a plugin for WordPress that automated posting from WordPress to Facebook and Twitter. It was one of the first plugins to bring this functionality to WordPress, and I am proud of what we were able to accomplish with it.

Sadly, the time has come to sunset this project—in fact, that time has officially been “here” for months, but I’ve had trouble letting go. On January 1 I made a commitment to open sourcing what was to be the third major release of SharePress—you can find the 3.0b branch of that code here, on GitHub.

To our customers: If you are a user of SharePress 2.x, do not try to upgrade to SharePress 3—it isn’t backwards compatible! If you purchased a license key for SharePress, you can still get support by e-mailing I’ll do my best to help people keep SharePress 2.x running until December 31, 2015.

In saying goodbye to SharePress, I want to thank Corey Brown for instigating the whole thing, and for allowing me to take what we built together and build a business around it. I also want to thank Joey Blake for helping me to keep the whole thing running through a tumultuous time in my life.

The question gnawing at me now is: what do I do next? I’ve been trying to figure that out for months. It occurred to me that like a lot of long-term projects, SharePress is a thread tying together a big chunk of my professional career. What follows is my exploration of that history, closing with ideas about where to go from here.

To know where we’re going, we have to understand from where we’ve come.

I felt unsatisfied and lonely.

About a year before I created SharePress, I was working for a consulting company where my job was to write software on contract for the federal government.  It was a good job, but I was unsatisfied—there are many reasons for my feeling that way, but the one that is most relevant to this story is this one:

I had started to feel like the work I was doing was formulaic, repetitive, and boring.

There was also a high degree of tedium in the work: writing from boiler plated code in Java, for example, and maintaining a very old codebase, and eventually, working on two different projects in two different languages.

That was 2010, I think. My daughter had just been born. I had recently bought my first house. I had a lot to be grateful for, but I was definitely frustrated, craving change, and feeling more than a little isolated.

To overcome those feelings I had been doing a bit of R&D on object relational mapping, and blogging and tweeting about it, and by virtue of putting myself out there, someone found me.

Corey Brown was looking for collaborators and community. Over coffee Corey told me about his world: about moving to the Shenandoah Valley and feeling cut-off from his colleagues, about working with Seth Godin on Squidoo, about creating No Treble, and about a discography concept he wanted to build, but couldn’t—Corey would be the first to tell you that he’s an instigator, even a web guru, but not a developer.

So our meeting was an incredible opportunity for both of us—I needed an instigator, and Corey needed a coder. Match made.

Corey also wanted to start a community of creatives right here in my hometown, where community was both something I had never known and something I longed for—technical peers were few and far between where I grew up, and building new relationships had been further frustrated by my tending toward introversion.

Our meeting marked the beginning of some exciting times.

Some breakdowns are luckier than others

As luck would have it, several months later, Squidoo’s lead developer quit unexpectedly, and Corey offered me the job.

Ironically, at the time I had one foot firmly planted in the world I find myself in today—freelancing and consulting, in pursuit of challenging problems to solve. It actually took some convincing by Seth Godin himself to get me to pull back and get onboard—a story worth telling in its own right, but not right now.

It was in working every day with Corey that I came to know the problem to which SharePress was to be the solution: if you’re building a worldwide audience on social media (as Corey was for No Treble), you have to communicate with your tribe around the clock. To solve this problem without losing sleep, you need some degree of automation.

Corey had already tried to solve this problem with another developer, but the solution was unstable. Corey would schedule new posts in WordPress, and at the time those posts became public, this bit of code was supposed to detect that publishing event, and automatically submit a link to the new post on Facebook.

Unfortunately, because of flaws in the design of the code, sometimes it failed silently. Corey would have to set an alarm to wake up to make sure that his posts had gone live, thus invalidating the entire automation.

It was a challenging problem, and solving it would require me to build a stable integration of Facebook’s code and WordPress’ code. I was so inspired I wrote the first version of SharePress in about 24 hours. Corey was thrilled with the result—so much so that he rewarded me by giving me complete ownership over the codebase, and did so with the encouragement that I should sell it and start a business building WordPress plugins.

And just like that, I became an entrepreneur—or so I thought.

The rise and fall

I decided to monetize my work by crippling it—preventing it from being able to post to Facebook pages, which is something that nearly every potential customer wanted to be able to do—and selling license keys that unlocked those features. I also provided paying customers with e-mail-based tech support.

This worked out great in the short-term—in the first year I think I made about $20,000, but there was a big problem: the business didn’t scale.

For one thing, I was doing little more than just selling my time—I hadn’t created a business so much as I had created a side-job for myself, supporting and maintaining one WordPress plugin. It made money, sure, and most of that money was profit, but there was no way I could have quit my full-time gig to focus on SharePress.

It’s also relevant that I wasn’t driven to quit my full-time gig: I was working at freaking Squidoo for Seth Godin with people I cared about and thought highly of.

The other way in which SharePress didn’t really scale was in the size of its user base.

To be a SharePress user (and customer), you couldn’t just be a good writer who wanted to reach more people more frequently; you had to have enough technical know-how to setup your own installation of WordPress, to install a WordPress plugin, to setup a Facebook application, and be able to do the necessary configuration for all three—all of these tasks are jargon-laden processes that years later are still too hard for many bloggers.

So I got a lot of support requests. I created some documentation, and while that helped some, most people still got stuck in the same places and wound up needing hands-on support. The need to support most customers siphoned away a lot of time and energy that would have been more productive if it had been put toward building more and better products.

In retrospect, a better strategy might have been to hold onto every dollar earned until there was enough capital to hire someone to be a support technician, allowing me to focus on building the next product. The truth is I didn’t know what I was doing and I didn’t have a plan—I was and continue to be primarily a very good technician, not a great businessman, though I have learned a lot. And the capital did go toward a great cause at the time, but I digress.

The world was changing rapidly

While I was making small money with SharePress, big money was raining down on the other side of the fence.

Instead of creating SharePress-like software—SharePress connected a single installation of WordPress directly to the social networks without an intermediary—companies like HootSuite and (later) Buffer were building centralized intermediaries: systems that sit in between the CMS and the social network, operating independently of both, but basically performing many of the same tasks as SharePress.

On the inside of these two kinds of systems the workflow is pretty much the same: authenticate with the third-party social platform (e.g., Facebook), store that authentication for later use, facilitate scheduling of things the user wants to post later, and consistently automate the posting. But while I was lucky to make a thousand dollars a month selling licenses to a few highly-motivated and (sometimes) savvy WordPress users, these other services were making millions of dollars per year.

By virtue of their mass, my competitors also had sway with and special support from Facebook’s engineering team. Their architectural scale—many servers vs. the standalone, shared, commodity hosting servers on which SharePress was often installed—allowed them to build insightful analysis features. And publishers need insight to compete effectively and to maximize the value of their content.

By the way, Buffer has a fascinating company culture that includes a public dashboard of their internal statistics, including revenue: $504K/mo. as of this writing, up 6% over the last 30 days.

There are some downsides to being one of those big players, I suppose. The changes and growth Facebook went through leading up to their IPO and afterward were probably a lot scarier for them than it was for me.

Instead of nervously watching my bottom line, my emotions hung on struggles like Corey’s: small- to medium-sized publishers who were fighting to maintain audience reach despite Facebook’s rapid transition from an organic system of distribution to one that was mostly influenced by a publisher’s willingness to pay. Those were stressful times.

Regurgitation vs. Curation

But I don’t think Facebook was wrong to move in that direction—away from organic and toward a system of paid distribution. For one thing, charging for access to an audience can make you a lot of money, and while it may be uniquely suited to the social media user experience, charging for accessing someone else’s audience is hardly a new business model.

But charging for reach is also a natural and practical defense against spam.

Unlike No Treble and (when we used it there) Squidoo, the vast majority of SharePress’ users are using it to automate the reposting of OPC—other publishers’ content. There’s software out there that is designed to subscribe to RSS feeds and automatically generate and publish posts in your own blog. While some “publishers” use software like this to fill gaps in their schedules, others try (and often fail) to build readership solely by regurgitating OPC.

If you combine SharePress with one of these plugins, you can easily post hundreds of unique links to Facebook and Twitter per day. If you do this sort of auto-posting, you might make a bit of money in the short-term, but in the long-term, if you’re regurgitating instead of curating, you’re not fostering an engaged audience, and so you’re not creating any value.

I’ve always known that SharePress was being misused this way, and it is, for me, a reason to consider discontinuing the product.

Deliberate and careful curation does create value, especially when the curator is something of an expert in his field. If I spent a portion of my time each day reading about WordPress development, and posting the best reads each day in a place where other WordPress developers could subscribe to and have access to my opinions, I would be creating a useful and valuable service.

If my aim were to build a tribe this way, I could do it with Buffer and an account on Facebook or Twitter—no blog and no SharePress needed.

Riding off into the sunset

In the last year that we all worked for Squidoo, my business partner Joey and I worked sort of irregularly to build SharePress 3, but mostly Joey did a lot of support engineering. I was spending most of my time focused on my personal life—something that I couldn’t have done without Joey’s partnership.

Sadly, while SharePress made us a bit of money, mostly it just created frustration for Joey. Our experiences were very much the same—dedicated support for a SharePress-like plugin seemed unavoidable even at our small scale, which left very little time for Joey to focus on new development, just as it had done for me.

At the time I conceived of it, the aim of SharePress 3 was to replace SharePress 2 with a more maintainable codebase and a product that would be easier to use overall. The original codebase had been built and maintained in a haphazard way, shifting to accommodate new ideas and keep the integration stable, so the technical debt was pretty high.

And as 2014 came to a close, so too did Squidoo—the landscape of optimizing affiliate content for search had moved away from us, and it was time to let go. As it was clear that SharePress didn’t represent a viable source of employment for either of us, Joey and I decided not to ship SharePress 3 and dissolved our partnership.

In dissolving our partnership we also agreed to open-source the SharePress 3 codebase. In fact, because it is GPL-licensed code (all WordPress code is required to be GPL-licensed) SharePress has always been open source, but now you can download the 3.0 codebase here—it is completely free for the taking, and is completely unsupported software.

The Future

SharePress is dead. Long live SharePress.

I think it’s time to build something new, but what to build is something I haven’t decided. As it was before, my time and attention are not focused on this problem—I’m currently freelancing, building a job-listings service, and I’m working for equity stake in two other projects.

It is still technically possible and even desirable to connect a self-hosted WordPress site directly to the social web.

There is a larger project called WordPress Social Login that facilitates exactly that. Built on top of an open source social authentication framework called HybridAuth, WSL is not commercial, and in many ways architectural, it is an incarnation of one vision I had for SharePress’ future: a standardized framework for building social-media-aware applications on top of WordPress.

But just facilitating social authentication and auto-posting is not in and of itself a grand enough product—it’s simply not viable for me personally (creatively), professionally or economically.

Looking to the world of centralized services does offer some inspiration. Buffer and new-kid-on-the-block Edgar offer compelling user-experiences and feature sets that could be cloned to run on top of self-hosted installations of WordPress. In fact, when I began designing SharePress 3, my intention was to build it to compete directly with Buffer.

But would anyone really want a Buffer-like feature for WordPress that wasn’t capable of providing them with rich performance insights? What is the ability to auto-post and repost without the ability to measure the success of your choices? Auto-posting the way Buffer does it is a lucrative business, but I have grown to believe that building these experiences inside of WordPress is not practical—commodity web hosting just isn’t performant enough to serve traffic and perform analysis services.

Another concept Joey and I were discussing we called Posse. Taking its name from the acronym POSSE which means Publish On (Your) Site, Syndicate Elsewhere, our Posse would have been a WordPress theme that provided users with a proxy for posting to social media. By posting through Posse, users would ensure that their content would remain in their control, and that platforms like Facebook and Twitter would be relegated to the role of syndication. I still think this is a good idea.   

Then there’s another idea that I attribute to conversations with Corey and Kenneth Reitz—a sort of POSSE in reverse that would automate the archival and organization of the things you create and publish on third-party sites like Facebook. Instead of publishing through your WordPress blog and pushing out to the third-party, the content you create at the third-party would be imported, archived, and indexed into your self-hosted installation of WordPress for safe-keeping and “findability.”

But these days I spend most of my time thinking about one idea in particular.

Taking on social media because it sucks

I want to change the social contract inherent in social media.

If you are a consumer of social media as at least 90% of users are, you’re there to connect with people you care about, to be entertained, to shop, or, in numbers that grow larger every day, you are there to be informed.

You belong to a generation that has grown to believe that content, even great content, should be free to consume and free to distribute—you want it good, you want it fast, and you want it cheap, and you’re not going to have it any other way.

But if you are such a consumer of social media, you are paying a cost, because you are the value proposition. You are being sold to advertisers for billions of dollars per year—your personality and your preferences are all for sale to the highest bidder.

This form of media that was born to connect you in an intimate way to the people and ideas you care about has become a world in which your permission to be marketed to is assumed, not asked for.

While our attention is being stolen and sold to advertisers, we are simultaneously drowning in information and mistaking it for accumulated knowledge—we now consume content not because our trust was earned by its creator, but because one or more of our “friends” have given the content their blessing in a mostly passive and transient way: by “liking” it.

But the technology platform on which social media rests was not created for the sake of mass marketing!

The Web was created to distribute information in an efficient and standard way for the sake of connecting people over great distances so that they could share ideas and make the world a better place.

In effect, we have sold our digital souls, trading the promise of a more connected world for one in which we don’t have to pay to play.

It’s time for a new contract

I haven’t written a proposal for this yet, but I will. When I do, I’ll write a new blog post to distribute it.

Very, very loosely, I think it looks something like this:

1. Unified codebase and user interface. That’s a complex way of saying that I think that social media and our interactions with it can be standardized. Posting, browsing, liking, saving, messaging, and sharing are all in common—the only thing that changes from service to service is the format of the content. So let’s have one system and one nomenclature to serve them all, with all forms of content welcome.

2. Decentralized application architecture. The architecture can be deployed in a way that allows each user to have a dedicated or virtually-dedicated hardware node, replacing the need for a giant and costly centralized system. The future of social media reflects the current systems’ network underpinning: interoperable nodes, distributed across the Internet, big and small social networks and even single-user nodes that can all pass messages and subscribe to one another.

3. Distributed cost paid for by the end-user, not by advertisers. There simply must be a better way to finance the operation of this system than selling privacy and preference to the highest bidding marketers. The goal should be to align the price with the cost of the system, because the platform as a form of human communication is invaluable. Open source for the win!

4. Mobile focused. There is a trend in Web design called “mobile-first.” While I don’t think that the smaller screens will ever be the only screens to access the Web, they are the dominant device in social media. Constraining user interface design to 767 pixels and smaller feels like the right way to go, and constraints boost creativity.

5. Publishers and retailers are first-class citizens. You won’t be able to pay for reach—you’ll have to earn the trust of your subscribers and users, but this leaves the playing field completely open and completely level. Will you be able to monetize your content? Yes, but you’ll do it in a respectful way: no interrupters or auto-playing ads allowed, and you’ll be encouraged instead to monetize through a pay-for-access subscription system that will be built-into the architecture.

6. Your feed is an inbox, not an algorithm. If you subscribe to too many voices, you will not be able to read them all. And the number of voices to which you can subscribe is limited by the size of the node you are on, which in turn is limited by what you are willing to pay for the service—referring again to the price of the system being driven by its cost not the profit margin. But there won’t be an algorithm deciding what to show you and when—guaranteed delivery of all the things, all the time.

If you have ideas about the future of social media, or if you would like to collaborate with me on this project, please write to me.