What a forked WordPress structure could look like

WordPress at 10: Time for a fork?

WordPress turns 10 years old this month, around the same time version 3.6 is set to release. Such a milestone deserves worldwide celebration as WordPress is now the most popular publishing application on the web. From an open source blogging platform, WordPress has grown into a mature Content Management System (CMS) with as many different uses as there are users. For many, WordPress has become the gateway to web publishing, and as a result has changed the face of the web. To call it impressive is a gross understatement.

But with great power comes great responsibility. This 10 year anniversary should also be a time for review, revision, and vision for the future. Should WordPress remain a one-size-fits-all CMS grown out of a blogging platform? Or is it time to rethink the structure of the application and modularize it to meet the demands of different user groups? I say it’s time for a fork.

Issues – The Why

The Fracture

Fractured landscape in grey tonesWith this growth, and the break-neck speed at which WordPress is currently evolving, there are bound to be hiccups along the way. Technical problems appear and are dealt with on an ongoing basis, but the problem I fear the most, the one we are quickly converging on, is a philosophical one:

In its quest for broad appeal, WordPress is becoming overgeneralized. I fear this may erode its foothold on the web and in the end break the application as a whole.

The problem is rooted in WordPress’ popularity. When the project began, WordPress had a neatly defined target user: The Blogger. But 10 years and 80 released versions later, the end user is no longer a homogenous group but a fragmented spectrum of users with widely different requirements and usage scenarios. WordPress is currently built to serve all these fragments, trying to do everything for everyone and as more complexity is added, it is slowly becoming a Jack of all trades but master of none. To misquote one of my favourite movies, “Overgeneralize and you breed in weakness.”

The Many Faces of WordPress

Looking at how people use WordPress today, one thing becomes clear: WordPress is different things to different people. You have bloggers who see it as a blogging tool, developers who use it as a CMS, themers who use it as a target application, large scale developers who use it as a core application for networks of sites, web hosts who use it as a hosted SAAS application, schools who use it as a social networking tool, enterprise clients who use it as a web publishing application, the list goes on.

Each of these scenarios have vastly different requirements, demands, applications, users, and target audiences. And yet they are all using the same application.

This is to the credit of the developers of WordPress. To build an application that can serve such a variety of usage scenarios is an impressive achievement. But when we look at how this came about, it is clear the current situation is sub-optimal.

As much as I hate to say it, WordPress is not really a CMS but rather an extremely built-out blogging platform. And because a large number of its users are bloggers, front end features are constantly added to help them. At the same time, new CMS features are added on the back end, allowing advanced developers to plug in and hook up. The end result is an application that grows in complexity with every iteration providing each individual user with an ever longer list of features she does not use nor need.

The tools and functions needed by a blogger are not the same as the tools and functions needed by a CMS developer. Or a network developer. Or an enterprise developer. But since the present goal of WordPress is to meet the demands of all parties, the application ships with everything for everyone, to the detriment of all.

Ant vs. Tank

Sit down with a novice WordPress user and you’ll see what I mean: What was once considered a simple and straight forward blogging tool has become a stunningly complex application with some blogging features. The novice user is often overwhelmed and this is usually followed by either frustration or overconfidence, both of which in turn lead to dangerous behaviour. The number of bloated, unsecure, spam infested, server killing WordPress sites on the web today is staggering, and it’s all because while we say “it’s so simple anyone can do it,” the reality is it’s so complex you need to be an expert to do it right.

I used to joke that using Drupal was a bit like killing an ant with a tank. Well, WordPress is starting to take on some pretty tank-ish qualities of its own.

Prongs – The How

So what do we do to solve this? How do we stake a path forward that meets the demands of a fractured user base while still retaining an agile core that continues to evolve with (or evolve *the*) web?

Here is my suggestion: I see WordPress stripped down to a core application with a series of prongs, each targeted towards a distinct user group or scenario. This can be done either through distinct forks or through plugins much like BuddyPress and e-commerce are being handled right now. The structure could look something like this:

WordPress Core (root)

WordPress CoreWordPress Core is the root branch on which all other entities are built. The Core consists of the most stripped down version of WordPress possible with core functionalities only.

Focus: Functions, security, and stability.

Target audience: Developers who don’t want any cruft but want to use WordPress as the base for applications.

WordPress for Bloggers (terminated branch)

WordPress for BloggersInspired by the front end of WordPress.com today WordPress for Bloggers is a simplified version of WordPress focussing on blogging features while disabling or hiding more advanced CMS features. UI is akin to WordPress.com rather than the current WordPress dashboard. New features like in-post editing and modal settings displays make it unneccessary for the average blogger to ever visit the admin interface.

Focus: Writing and publishing blog posts. Post Formats are front and center while features like custom permalink and front page setup are handled at setup with editing under a simplified Settings panel. Themes are handled through the Theme Preview and Customizer function. Advanced features like SEO integration and social buttons are built in. Security updates are automatic and a security checker is built in to alert site owners of possible security issues.

Target audience: Bloggers who want a low-touch plug-and-play solution with plenty of hand holding. There is little to no room for a novice to be dangerous in this environment.

WordPress CMS (branch)

WordPress CMSEssentially current WordPress with Custom Post Types and content management elevated to first rate citizenship. Content and settings is managed in admin. Blog-centric tools like Post Formats are relegated to plugins. WordPress CMS is close to what WordPress is today.

Focus: Extended functionality including modules / meta boxes, Custom Post Types, Custom Post Templates, advanced data handling, and extended user management including added roles and capabilities.

Target audience: WordPress designers and developers building advanced sites. Small and medium scale dev shops. Advanced site managers.

WordPress Enterprise (branch from CMS)

WordPress EnterpriseWordPress CMS with enterprise level security and compartmentalization at the core.

Focus: Security and scaleability.

Target audience: Enterprise developers and large-scale solution owners.

WordPress Network (branch from Enterprise)

WordPress NetworkNetwork installation of WordPress Enterprise allowing for sub-sites of either CMS or Blogger editions.

Focus: Scalability, user management, extsibility for social networks and forums

Target audience: WordPress Network managers, MU community, bbPress, BuddyPress etc.

WordPress Experimental (terminated branch)

WordPress ExperimentalBranch for experimentation and testing of new ideas.

Focus: New iterations and unexplored territory.

Target audience: Developers and those who see WordPress as a blank canvas.

Process

Platform development would work as follows:

  • All branches are dependent on and built on top of WordPress Core.
  • Any update to WordPress Core is mandatory for all branches.
  • New features are developed against the appropriate branch.
  • When new features are pertinent to all branches they are published to Core.
  • New features can migrate backwards towards core or forwards towards branches.

This structure will allow for parallel development of new core and branch features while at the same time avoiding specialized branch features from bloating other branches or core.

Discuss!

This is a suggested draft map and outline meant to be the basis for a larger discussion about the future of WordPress. At the root of this discussion should be the end user – the person installing and running WordPress – and how to meet the demands of this person without bogging down other users in the process. To do this we need to identify who the target users are, how they use WordPress, what features they use, what features get in their way, and what features they need to move forward. It’s a complicated process and it will require a rethink of how WordPress is developed and used, but in the end I believe it will lead to a stronger platform with more opportunities for everyone who wants in.

Now it’s your turn. Discuss!

Further reading + relevant-ish links


About Morten Rand-Hendriksen

Morten Rand-Hendriksen is a staff author at lynda.com specializing in WordPress and web design and development and an instructor at Emily Carr University of Art and Design. He is a popular speaker and educator on all things design, web standards and open source. As the owner and Web Head at Pink & Yellow Media, a boutique style digital media company in Burnaby, BC, Canada, he has created WordPress-based web solutions for multi-national companies, political parties, banks, and small businesses and bloggers alike. He also contributes to the local WordPress community by organizing Meetups and WordCamps.

40 comments:

  1. I like the overall concept, but I’d say it may be a bit *too* modular.

    Some of those feature sets could (or already do) exist in the form of plugins. I do think there is a good use case for Blogger/CMS branches though. A “lite” version, so to speak.

      1. I partially agree, Ghost does seem like a nice platform. The fact remains that the core of WP is still a blogging platform, what people bolt on and create from it is over complicating it.

    1. WordPress Lite. I like that name. As for the number of modules, they came about based on how WordPress is being used today. I think it can be done in a LEGO kind of way so that it’s seamless and relational rather than split up and fragmented.

  2. I really like this idea. I would love the option of starting with WordPress core without any of the extra Blog/CMS stuff layered on.

    Taking the idea one step further I think each of those branches could actually be developed as plugins to the WordPress core. The initial install would be almost like JetPack where you choose what to install and activate from one screen.

    1. I was just discussing this with Curtis McHale over on Google+. What I envision is when you start a new WordPress site you install WordPress Core. Then as you go through the install process you are asked “What type of site are you setting up?” followed by different options: Blog, CMS, Enterprise, Network, Experimental. Based on the choice you make the appropriate branch package is installed. This would also have to be wired in such a way that the administrator can upgrade or downgrade to a different branch at any time.

      The reason I am adverse to the plugin option is that it runs a separate process on the server. Ideally WordPress in whatever format it is should run as one core application. Modules that are hooked on would work better in my opinion, but the plugin direction is a close second.

  3. Interesting idea. That would be some work, but provides the opportunity to overhaul the codebase and clean out the cruft and blog-specific roots. On the other hand, who’s to say that blog and CMS versions need to be separate? What if one wants both? Also, one of WP’s strong points has been backward compatibility – that may be impacted by such a move. For myself, I say ‘good!’, but it might negatively impact many more.

    1. Backwards compatibility is great unless it holds the entire application back. Let me give you an example:

      Have you ever looked at the markup for an image gallery? The gallery items are marked up as a definition list. This was done ages ago because back then there were no good alternatives. It is semantically incorrect, breaks modern web standards, and there is a correct way of doing it now with the figure tags.

      On asking why galleries are still marked up as definition lists the answer from the core developers was that changing it would break a bunch of existing plugins and themes.

      While this is true, it is not a reason to hold on to bad code. The definition list should have been replaced a long time ago, but persists due to fear of pissing a few developers off. The mentality that we can’t get rid of legacy code because it breaks old stuff is not useful is not even consistently followed within WordPress. Functions and elements are deprecated all the time, but it’s done at random.

      By starting over with a slimmed down core we have the opportunity of getting WP up to modern standards and start fresh. And if legacy is an issue we can always do what so many other applications have done by continuing to release point versions of the latest legacy version for a set period of time (2 years, 3 years) and then move on.

      Drupal was there and did the right thing. Joomla! was there and did the wrong thing. We’re here now and we’re currently treading water.

      1. Agreed, holding back on progress for the sake of compatibility is not ideal. There needs to be a line drawn, and will require some short-term pain to make the transition. WP could be torn down and rebuilt all the better, if the will is there.

    2. WP CMS should be the big brother of WP Blogging Edition. So, CMS version would inherit the blogging feature as well and “The User” would have the choice that what they want.

  4. Thank you John for the great analysis. As Mel pointed out, the success of Ghost on Kickstarter is a clear signal of the need of a light core. This is true for bloggers, but imho it’s also true for developers using WordPress like a framework.

  5. That was attempted a bit over 3 years ago, albeit for different reasons. Remember BackPress?

    That didn’t really work out, IMO, because I think they cut BackPress down a bit too much. It would be the equivalent of what you’re calling the “WordPress Core” above, just the basic guts of it.

    Problem is that this “core” doesn’t add enough to be particularly useful from a developer perspective, really. The power of developing on WordPress is all that extra stuff you’re talking about. The ability to define a custom post type to store arbitrary data without having to do a bunch of extra database crap is pretty darned powerful. Yes, it may not be 100% efficient at the job, but it’s very quick and easy to develop, and allows for rapid prototyping and some okay (but not perfect) scalability.

    Multisite got rolled into the WordPress core because it didn’t make a whole lot of sense to maintain two branches like that. It ended up being twice the work, sometimes more. Even if you separated the pieces logically into segments, there’s still enough interconnectedness between all-the-things to make it kind of a pain to deal with.

    In the long run, yes, WordPress needs to separate its sections out more. However, I don’t think this necessarily means that they’ll be better off in separate “packages”, as such. This sort of thing would be purely a code-level separation, to ease maintenance and development, and perhaps improve speed by making it more of a “load-on-demand” type of system. But that’s not at the user-level by any means, that’s purely developer-speak.

    The types of separation the user would see should be more at the interface level alone, which is already on a quest for more simplicity and ease-of-use, and I think the next few versions will have gradual but incremental improvements in that direction.

    1. Thanks for piping in @Otto. Like I said in a response to an earlier comment, one way this could work was by handling each branch as a module: At install of WordPress Core you are asked what type of site you are setting up, and based on that the correct branch point is pulled down and installed with it. I don’t want to see entirely separate and self-contained branches of WordPress like what WPMU used to be but rather a modular approach where each branch point is dependent on the previous.

      1. I don’t think the idea of getting only the pieces you need makes a whole lot of sense, but only *loading* the pieces you need does. In other words, you can gain the speed and development benefits without the need to fragment the codebase into separate “downloadable” modules and the associated build process that comes with that additional complexity.

        As WP becomes more and more class-oriented over time, then the idea of auto-loading pieces as needed makes more and more sense. But making, say, 5-6 zip files instead of just one kinda sorta doesn’t. It would have to be fairly large for that to be useful, and anything under tens of megs makes that kind of overkill.

        1. I think we’re on the same page here @Otto. How exactly this can be implemented depends on a lot of factors, the most important of which is that this has to be futureproof and a solid base for development of new concepts. The way I see it by splitting the end-user scenarios into separate branches or modules parallel development can be implemented and the platform can evolve much quicker because a blog-centric feature won’t hold a core feature back and vice versa. It would also allow a refresh of the core to purge old legacy code that should have been removed a long time ago.

        2. THIS. I don’t see any need to carve out a whole lot of stuff, but workflow presets could go a long way. Maybe a “blog mode”, a “boilerplate(developer/framework) mode” and a “cms(advanced/wholeshebang) mode” for starters.

          Selective loading, for WordPress internals as well as plugins, would be huge.

          Some more drastic divisioning and downsizing is inevitable down the line, but it’s not the best place to start.

  6. I was loosely involved with a fork of Joomla called “Square One CMS.” A friend of mine took Joomla, stripped the core extensions down to the bare minimum necessary to make the system run. He also went a step further and added a panel where you could go back and install everything as it was before. Effectively, you were able to bring Square One back up to a full installation of Joomla with a couple of clicks (with some small differences).

    Unfortunately, as a side project, it was a bit labor intensive for him to maintain. As changes were made in Joomla itself, he had to pull out some obscure Git commands to keep the core changes in sync. He also had to maintain a list of all of the core extensions so people could add them back. While there was definitely interest in having a “Joomla Lite” distribution, there wasn’t enough volunteer effort to maintain it as a separate project.

    However, Square One did prove the concept that you could ship a stripped down, regularly updated copy of a CMS with a bit of effort. I would think that if a “core and branches” future of WordPress development is desired by the community, Automattic would definitely have the resources to help make it a reality.

    1. With core backing and a clearly defined standard for development this approach would be more than manageable – it would actually make development easier. Like you said, it’s all about resources.

  7. I have been using WordPress extensively since mid 2006. The most significant change in that time was in the back end at the end of 2008. I loved that the button for adding a new page became “add new page” and so on. I have worked on hundreds of sites in that time and when I started most were blogs although by early 2009 that changed to be more static, although usually with a blog section as well.

    I’ve worked with many CMS systems and most of them were just awful at the back end being built by techies for techies or borrowing from truly awful desktop publishing workflows where each page consists of multiple “panels”.

    I still work across multiple CMS systems and Wp is still the best at the backend for “regular users”. I can hand off each site to the business or organisation with ease most of the time.

    However the explosion in plugins and themes in the past few years has become counter productive. Many of the larger plugins are performance hogs and something like ecommerce seems like a better idea than it really is on the WP platform. Add to that security has become a much bigger issue in recent times as well.

    http://tryghost.org/ by John O’Nolan has already been mentioned above. I’m not sure that a blog only approach will work since more than 95% of the people I work with don’t really want a blog at all now.

    James Shakespeare has a provocative post over at http://jshakespeare.com/the-dire-state-of-wordpress/ which does outline some of the issues with the current state of WP.

    I have organised a number of wordcamps and been to WordCamp SF ( twice) including the code days and so I have met many of the core team members and contributors. It is a great community but navigating the eco-system has become more complex than it needs to be.

    Choosing a great theme or plugin has become much harder because of the sheer volumes.

    As an example – I am working on a membership project at present and would prefer to use a plugin off the official repository because I have an idea of how much real validation (usage) it has by looking at the number of downloads and support resolution rates. I also know that the background plugin checks for security is likely to be better on the repository that for a premium plugin.

    It is much harder to evaluate a premium plugin without a serious developer on board. And ultimately I suspect that the best membership systems are not on WordPress at all but for all sorts of reasons it is easier to use a plugin for this.

    Last but not least as James Shakespeare noted in his post – (I’m para-phrasing) a WordPress developer is not the same as a “real” developer.

    In my long experience very few developers are system agnostic – most get comfortable on their favourite one. For example Adobe is dropping Fireworks and it does seem like Fireworks users have a valid case for Fireworks to be open sourced or continued in some other way but I don’t know enough about that example.

    But as hard as it sounds being able to excel in multiple platforms / languages is a good idea. As shocking as it sounds Drupal seems to be heading in the right direction with the latest changes. Anything that gets closer to some form of web standards is a good idea.

    The web standards concept may also be part of the issue. Despite various attempts standards are not as universal and as obvious as they could be.

    What I do see is that most of the s/w applications I have used have become bloated over time and WordPress core is still very good but it is always smart to ask the hard questions.

    I remember Borland (90′s) used to make SE versions of its apps which stood for Special Edition as I recall and the idea of a “stripped down” or light edition seems to be a good one. In some respects WordPress core is trying to do that.

    On the other hand Jetpack seems seriously bloated in the way it has been implemented. I know there is a Manual Control for Jetpack plugin by Mark Jaquith which can be used to manage it better but there is a philosophical issue there as well.

    One idea that has become clearer in recent years is that themes do need to be optimised more for their primary purpose. The obvious example there is ecommerce themes as a subset and possibly some of the theme frameworks that are out there.

    1. To “WordPress developers are not real developers” I tend to agree. When you write code for WordPress you are not writing PHP but what I call “WordPress Markup Language”. There is a WordPress function for pretty much every PHP function and that makes people who are brought up on WP terrible PHP developers.

      To Drupal, as far as I’ve heard they are now officially not trying to compete with WordPress any more but rather focusing in on enterprise and larger sites. That says a lot both about Drupal as a simple site engine and WordPress as an Enterprise solution.

      To Jetpack, I say only four words: I never use Jetpack.

        1. Taken out of context everything can sound like it’s something it’s not. My reference, to which you are referring, is to the article the previous commenter mentioned. My statement (which on revision can be a bit confusing) is that I agree with the overall sentiment in the article (http://jshakespeare.com/the-dire-state-of-wordpress/). My point, clearly stated in the comment, is that most WordPress developers who create themes and plugins cannot call themselves PHP developers because they are in fact WordPress Templating Language developers. As you know PHP and WordPress functions are two very different things and while a PHP developer can do a lot with WordPress, most WordPress-only developers can do very little with PHP.

  8. I’ve been suggesting that a totally rebuilt BackPress should used as a simple core for a while now. Although I do think it needs a little more than a simple set of functions as it was before. It’s never going to be a competitive PHP framework, but it could definitely be a competitive simple CMS which can replicate WordPress with a few (large) plugins added.

    It could include the bulk of WordPress except for the admin panel and some other bloat. Then a blogging admin panel could be provided as a plugin and other more enterprise/developer centric admin panels could be developed for the rest perhaps.

  9. IMHO, the author got WordPress wrong and sounds like a novice that has just installed WP and a theme that enables every feature available and adds some and then with some more twists.

    WordPress is beeing simplified for users while empowering developers all the time. An example is the Link Manager that recently got ditched for those not using it. Blog formats, custom headers, thumbnails etc are all features that must be explicitly enabled by the theme.

    WordPress excels when it comes to simplicity for users, only showing them what they need/use but still has vast amount of power under the hood for devs to enable.

    A fork doesn’t make any sense to me. It would rather be much easier and sensible to make a plugin that use WordPress’ internal features (filter and action hooks) to strip down functionality you don’t need, like comments. Oh BTW, many such plugins already exists.

    1. Just like the removal of the Link Manager is an example of the simplification of WordPress, the new Post Formats UI is an example of WordPress becoming more complex. My point, which you seem to have missed, is that the one-size-fits-all approach that is currently at the core of WordPress development is not suited for the varying end users. While it’s true that you can disable most features in WordPress through themes and plugins, when installed WordPress is complex. The first thing a new user sees is an advanced interface with a vast variety of options that are less than obvious. What you are saying is essentially that it is up to the end user to figure out how to disable these features. What I’m saying is the end user gets frustrated at the onset and it is counter productive to demand they figure out how to simplify their experience on their own. We disagree on philosophy.

  10. This is probably the most confusing posts about WordPress I have ever read. First, you say WordPress is too complex and then go on proposing it to be more complex.

    Then you are talking about “fork” in a confusing way. Forking, in open source, is grabbing a copy and start developing a new product. It seems your “fork” is just install options for activating “modules”, and more options in general.

    Making those branches would mean bundling a package of plugins into the distribution. “Core plugins”? Or a new community based on your philosophy? Go fork, but it will not be WordPress.

    And what you describe is not the WordPress I know. Is there other software also called WordPress? You describe a monster without direction. I see a clean and simple platform for the majority of use cases, and that can be extended endlessly or even further simplified, using plugins or themes.

    There are thousands of ways to make WordPress better, for the average user and for developers. What do you want to remove, and what to add for core? Make a stunningly good plugin to demonstrate your points better.

    1. I see you are confused so let me give you an analogy: If a person goes to a computer store saying they want “a computer to use the internet”, what do you sell them? You can give them anything from an iPad to a laptop to an all-in-one computer to a build it yourself computer. To find out what the customer needs you first have to understand their skill level and expectations. My argument is that right now WordPress is a build it yourself computer and it is being shipped to anyone regardless of skill level. What I propose is to diversify and ship different versions for different skill levels and user scenarios: an iPad for the blogger, an all-in-one computer for the CMS user, a server for the Enterprise user, a build it yourself system for the developer. This is in line with how most software is shipped (Adobe, Propellerhead, Apple, Microsoft etc all do this) and it is based on a philosophy of meeting consumer demand rather than developer demand.

      As for the fork confusion, I think you are mixing what I said in the article with one of my comments: What I propose in the article is a forked system with dependencies. Each fork is dependent on the previous, but each fork can stand on its own. What I was referring to in the comment about modularization is one way of accomplishing this. Off the top of my head I can think of at least four different scenarios: Classic fork (each fork is independent), core with plugins, core with modules, core with extensions. There are bound to be others as well. Which method is chosen depends on factors that go far beyond the scope of this article. What I want to do here is start a discussion about how we deal with the varying demands of the users of WordPress without building a complex one-size-fits-all system that ends up not fitting anyone quite right.

      To see what I’m talking about, do what I suggested in the article: Find a complete novice with no previous web publishing experience, sit that person down in front of WordPress, and watch what happens. Without instruction most people are lost, get frustrated, and many end up giving up. It didn’t use to be like this, but that’s the state of affairs right now. It is the reason why projects like Ghost and other “blogging only” platforms are being released, and it’s the reason why WordPress training is having a huge boom.

  11. Fragmentation should be avoided at all cost but in this point I have to aggre that it has to be done. I’m afraid the complexity of custom post types willreduce the quality of themes.

    WordPress CMS – WordPress lite (for bloggers) is a more realistic senario.

  12. I believe that forking is not the way to go – if you’ve ever got into the core development of WordPress, you would see why it would never work. However, I think that there should be a convenient way to disable some of those more ‘bloggy’ features, such as posts and comments, instead of having to hack around them.

  13. I think Morten has a good point about the interface being too cumbersome/difficult who users who just want to blog, but I think there may be a simpler way to solve that problem.

    Instead of breaking the code into different modules, what if we leave the underlying architecture unchanged, and then add an additional interface, similar what to what WordPress.com does.

    Like in Morten’s idea, when a new site is created (or a new user account), the user can choose if they want the simple, stripped-down interface, or the full interface that we currently give them.

    That might solve the problem for users, without having to add too much work for the core developers.

    Does that sound like a good idea to anyone else? Are there any holes in it that I haven’t thought of?

  14. I do agree that it is getting complex even at the level of UI. The current change of post format UI made it more difficult because WP Core team wanted to copy tumblr. But compared to drupal and joomla, I still think wordpress is easy to learn and use for new bloggers.

  15. Hey everyone. I like the idea of forking WordPress. I respect what Matt and the team has done, but the core is just so limiting.

    I started up a little business called Seshn, and we are building a layer on top of WP that trims off all of the fat and makes it super duper simple to write, create and aggregate content from your social applications.

    Currently I am in the very beginning stages of wondering if we should start forking some of the core components. For instance the post editor needs to be completely re-done from scratch. TinyMCE is problematic and right now we are using WP User Frontend heavily modified so users can post from the front-end in an elegant, minimal setting.

    Feedback is great so far but the more I dive into this, I am starting to think fork is necessary. If you’d like a beta account set up to cruise around, I’d love to set you up so you can take a peek and hopefully give some feedback. Also, if you want to help take the project to the next level with us and fork it…. of course open to that as well.

    Connect with me at brandon at seshn .com

    Check it out at http://beta.seshn.com. ALL built in WP. :)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>