Going Behind the Scenes with the Jetpack Team


Have you ever wondered what it takes to support a WordPress plugin with a million active users? At the beginning of 2015, Matt Mullenweg highlighted Jetpack as one of the most important tools in helping WordPress remain competitive and preventing the decline of its market share.

The team surrounding Jetpack is laser focused on adding compelling features that will help self-hosted sites get everything they need in one convenient pit stop. Whether or not you believe the future of WordPress is hinged on Jetpack’s success, there’s no doubt that the professionally-supported plugin has helped self-hosted sites to thrive, with much less effort required on the part of site administrators.

With 36 modules currently available in the plugin and a never-ending support queue, the distributed team behind Jetpack meets up regularly to build teamwork and keep things running smoothly. At WordCamp London 2015, a good number of the newly expanded team met in person for the first time.

I had the opportunity to sit down with a few Jetpack representatives, including team lead George Stephanis, support specialist Carolyn Sonnek, and pit crew team member Jesse Friedman to discuss what it takes to keep Jetpack going strong.

Managing the Jetpack Support Load

Since their last meetup in August, the Jetpack team has experienced quite a few shakeups. Automattic’s BruteProtect acquisition added five new team members to the pit crew, bringing their numbers to 10. The Jetpack Manage team, which ties into WordPress.com, has 10 members and is led by Beau Lebens. There are also 10 additional team members allocated for supporting Jetpack user happiness.

Stephanis always tries to include someone from support, as they represent those who are on the front lines with users every day. The happiness engineers are also divided into sub-teams to manage a support queue that often adds up to several hundred tickets per day. Requests pour into an email inbox from the plugin itself, as well as the WordPress.org support forums.

Jetpack team members are also active on Twitter and Facebook where they triage requests and help to move users to a more traditional support avenue. The happiness engineers are currently working on a quicker turnaround for support.

“Right now our goal is to get under 12 hours, and then once we hit that goal, we’re going to go to five hours, and then on to 1 hour someday,” Sonnek said. If you take a look at the plugin’s support forums, you’ll find that nearly all of the issues are resolved or in process, which is a rarity for WordPress.org plugins. It takes 10 team members to keep it that way.

Automattic is aware of the number of people currently using Jetpack but will not be disclosing that information publicly. “We use those numbers internally for reference for how we are doing, or to see if there has been some change that has resulted in an uptake of new connections or something along those lines,” Stephanis said.

“In the end it’s a number, and a number without context is very easy to take out of context. [pullquote]Instead of dwelling on the numbers, we’re much more interested in what adoption looks like.[/pullquote]” He said that the total number is comparable to the million installs reported by WordPress.org but is probably somewhat less if you account for test sites and hosting partnerships where the plugin is automatically installed but not yet active.

Jetpack Focus for 2015: Iterating and Polishing of Current Features

For the past few years the Jetpack team has managed a unique balancing act of prioritizing support while fixing bugs and tackling new features at the same time. Many recent releases have introduced new modules, but the team is switching gears in 2015 to focus on keeping the ride smooth.

“Our focus for the next year is largely going to be on iterating and putting the next bit of spit and polish on features that are already in,” Stephanis said. “A lot of the things we’ve launched need a v2; they need a second pass on it.”

This new focus will be a change as compared to the previous breakneck speed with which the team was cranking out new modules.

“There are couple of minor things that other teams are working on that will probably get rolled out to WordPress.com and will probably get synced down to Jetpack as well,” he said. “But there’s no large ticket features that we’re currently focusing to get into Jetpack and get launched.

“This is very much a year focused on building up the team, building up familiarity with our internal processes and cultures, and addressing some long-standing technical debt that we’ve been kind of swamped with paying down.

“But now with the resources we currently have, it’s much easier to focus on the core product offering and how to explain that,” Stephanis said.

Pushing for Goals Over Deadlines

Stephanis has been leading Jetpack releases for awhile, but recently the team has started rotating release leads in preparation for his upcoming paternity leave. I asked him if he still feels the weight of pushing out code to millions of users at release time.

“Every time,” he said. “I’m just thinking – What edge cases have I missed? Have I forgotten to do something? Have I updated the translations? What if we’re not compatible with some other plugin? What if there’s a name space conflict and we white screen some sites?”

With a massive user base using a myriad of different themes and plugins, there’s always the chance for some unforeseen conflict. The support team has to be prepared to handle that.

However, Stephanis believes the many problems with releases can be prevented by making sure you’re never in a rush.

“If you’re forcing it through to get it out super quick, you’re not giving your subconscious the time to turn things over in its own time,” he said. “I’m not saying intentionally slow down the development process, but [pullquote]making sure you’re never overly rushed by deadlines is one of my best ways to ensure that we’re not having oops moments[/pullquote] or shipping something and then two hours later go ‘Oh we forgot the…’”

As part of this approach, the team focuses on goals and testing more than meeting an arbitrary release schedule.

“We set goals more than deadlines,” Stephanis said. “Yes, it’s nice to have deadlines and goals but if you’re overly concerned about the deadline, the quality can slip. We make sure we’re not shipping anything unless we’re really comfortable with it, we’re confident, and we’ve tested it.”

The team aims to do at least a one-week translation freeze before releases and generally catches a good deal of bugs during the freeze.

“We have a fantastic Jetpack beta group that we pass releases out to and explain everything new that’s coming,” he said. “Some of the edge cases they turn up just blow my mind.” Having that cushion of time to focus on compatibility and cross testing is essential to mitigating Jetpack’s conflicts with other plugins.

“[pullquote]Very small issues become very big issues when you’re running at scale with millions of users[/pullquote],” Stephanis said. “If something is only hitting one tenth of one percent, guess what, that’s a couple thousand users now.”

With an ever growing user base, the cost of a mistake or conflict gets even more expensive in terms of support. This is where the Jetpack team has learned that not rushing really pays off. The goal, in the end, is not about hitting a release date but rather providing a smooth experience with the release.

Overcoming Negative Perceptions of Jetpack

One of the constant struggles for the Jetpack team is addressing the negative perceptions of the plugin, especially criticism from the development community.

“There are still a lot of folks who don’t understand what we’re actually trying to accomplish,” Stephanis said. “I occasionally get questions like, ‘With as many things as Jetpack is doing, how are individual plugin authors meant to in any way compete against this?’

“The answer to that is we do a lot of general things aimed at raising the tide that lifts all the ships, but we don’t go in any way in depth. For example, I don’t think the contact form module in Jetpack has in any way hindered the sales of Gravity Forms.

“Developers still have the ability to pick one aspect and go incredibly in depth on it – yes, we have related posts, but if someone wants to do a plugin that just does related posts and really knocks it out of the park, we’ll be able to get folks started on the idea of it. Then they’ll get comfortable and will be much more willing to move to a premium version that they find elsewhere.”

Stephanis also emphasized Jetpack’s extensibility. Plugin authors are even at liberty to utilize the WordPress.com infrastructure while extending Jetpack features. Despite having 36 different modules, the goal has never been to add every possible feature.

“One of the things we fight perception-wise is the concept that Jetpack is bloated,” Stephanis said. “Which is an easy thing to think when you see what appears to be 30 some different plugins that you can turn on and off.

“When they all tie together with the common core, one plugin can be just one line of code or one plugin could be humongous. It’s very easy to fall into the idea of: ‘I turn off a plugin and that’s going to make my site go faster, right?’ But the fact of the matter is that everything we do in WordPress and life is always going to be a matter of trade offs.

“If you do something else, it’s going to affect your site in some fashion. Just by the very fact that you’re adding some level of complexity. It’s more of a question of if you want this feature what’s the best trade off you can get for it. Sam ran a couple comparisons and published them on the group blog comparing our commenting form and several of our other features to WP plugins. In comparison, we wind up coming out a little bit ahead.”

The download size of Jetpack, currently at 8.2MB, is often a concern for many users.

“The code base gets a lot of misunderstanding,” Stephanis said. “The translations are about 2/3 of it and the Custom CSS module includes a megabyte in and of itself, because we include some JavaScript and CSS to make it pretty as you’re editing it, SASS and Less precompilers, the CSS sanitization library, all of which for the vast majority of page views isn’t even loaded.”

At the moment, three quarters of Jetpack sites are using English, which means that two thirds of the download size is irrelevant to three quarters of Jetpack users. Getting translations on demand is a major goal for the plugin, but the team has to work with WordPress.org to make it happen.

“We are waiting on support from WordPres.org to let us use a GlotPress instance to manage our translation flow and then it’s just a quick switch to start serving it up on their end,” Stephanis said.

Until that is resolved, the cost of supporting a global user base will continue to be an extra 5MB on the initial download. Apart from some vocal opposition from developers, most Jetpack users do not seem to mind the size of the download or the number of modules. The features it provides in one package are too compelling and convenient for most of the plugin’s users to notice the download size.

Jetpack also gives self-hosted sites access to the infrastructure available on WordPress.com for features that might otherwise create a toll on budget hosting providers, such as related posts and the free Photon CDN. However, Stephanis believes that the quality of maintenance and support are the most compelling reasons to use Jetpack.

“One of the biggest gripes most folks have with the WordPress.org plugin repository is that there are so many abandoned plugins,” he said. “These are plugins that either have bugs and never get attention or plugins that, if something breaks, you can never get support.

“By far the biggest advantage and the best reason to use Jetpack is the fact that we have 20 active developers between Beau’s team and the pit crew itself, and an active crew of about 10 support folks that are daily focused on enriching the experience, fixing any issues that come up. That, by far, to me is the biggest selling point, the biggest advantage over using 30 different plugins where the code quality may be more questionable.”


25 responses to “Going Behind the Scenes with the Jetpack Team”

  1. Interesting article – I had my reservations about using Jetpack but tried it out last week. I now wish I had done it sooner.
    In many cases, clients only want a simple additional feature and the majority of plugins in the repository are either overkill or unsupported. Jetpack fills that void perfectly for a lot of features.

    • “If your not paying for a service, you’re not the customer you’re the product!” Or something equally cynical.

      Never used Jetpack myself, but from looking at jetpack.me and the repository I can’t see any mention of payed upgrades etc. So why are Automattic offering all this loveliness for ‘free’ ? What’s in it for them?

      If you use WordPress.com, I can see the financial incentives. But for self-hosted WordPress users?

      In the case of Facebook and Twitter, it’s all the lovely data you generate that they can sell to third parties. Is this the case for Automattic? Or are they hoping it will encourage self hosted users to start using WordPress.com and it’s paid upgrades?

      • It’s a combination of a few things. By increasing the usage and adoption of the WordPress platform through Jetpack, we benefit — rising tide and all that — more potential subscribers for Akismet, VaultPress, premium themes, etc.

        But more importantly, the parity to a WordPress.com experience we aim to provide for self-hosted sites makes it simpler for users to migrate their sites either to or from WordPress.com, and easier migrations are a gain for the hosted platform. But more than that, it’s a desire to grow and improve the platform.

        Automattic was founded as a way to provide a way to keep folks fed, clothed, housed, etc — while contributing to Core. It wasn’t founded to pull in tons of money, it was something to be sustainable and drive the platform forward as a whole — both by providing an easy onramp to the WordPress ecosystem through WordPress.com, as well as funding people to contribute on the open source side.

        Whether you believe me, or are too cynical to, that I have no control over — but it’s the truth. We just want to make the web a better place. :)

        • We live in a world where Google’s ‘Do no evil’ has become a rhetorical meme. A world where Facebook and In-Q-Tel holding hands is fine and dandy and only something conspiracy theorists question.

          I’ve followed Matt since the B2 days. His commitment to open source has been an inspiration to me. And whilst I’m sure Jetpack does act as a signpost to Automattic’s premium services, amongst other things, I struggle to see how stuff like the Stats addon fits into this. That’s an awful lot of our user’s information sitting on Automattic’s servers. And all for free!

          With large sums of VC cash floating about the company nowadays, I can’t help but feel a little uneasy. Chase Coleman, Iconiq Capital’s Makan, Endurance International Group’s Goldman Sachs / Warburg love-in – they all have stakes in Automattic. These lad’s aren’t philanthropists. Not by any stretch of the imagination.

          I appreciate all the hard work you folks do in order to make our community a better place. And I certainly don’t question your motives for doing so. ITZ them others that worry me ;-)

          Anyhow, I’ll doff my tinfoil fedora and show myself out. Thanks for playing.

  2. so it is not only the code that can use some diet ;)

    really, jetpack is a no go as long as it tries to have more lines of code then wordpress itself. The security and side affect risks are just unbearable to any non trivial site in which stability of the code is a must and plugin upgrade need an approval from 10 different people.and a rigorous QA.

    (going to the gym to work on my own diet ;) )

    • Core has ( https://api.github.com/repos/wordpress/wordpress/languages ):

      8,830,768 bytes of PHP code
      1,836,270 bytes of CSS code
      2,034,993 bytes of JS code

      Jetpack has ( https://api.github.com/repos/automattic/jetpack/languages ):

      3,238,091 bytes of PHP code (36.7% as much)
      550,377 bytes of CSS code (30.0% as much)
      570,773 bytes of JS code (28.0% as much)

      And that includes all our build tools and unit tests, whereas the core repo doesn’t.

      And — really? You’re going to resort to fat jokes?

      • Fat joke? man have you ever heard about how obesity is bad for your health? If you think that your health is a joke then yes, it was a joke.

        as for the LOC all I have to say is LOL. most people just need some infinite scroll something that can be done in 500 LOC so what is your excuse for the other 2M LOC? You could have achieved the same feature parity with wordpress.com by releasing each module as a plugin.
        But then…. It will not be as easy to show to the investors that automatic has X users on wordpress.com and another Y users tied to its services via jetpack.

        And then you don’t have the best features when you compare your features to other plugins that do similar things so people still need to install other plugins as well.

        Now what about the secret (I don’t remember seeing a documentation of it) backdoor you have to avoid the need to authenticate like any other xml-rpc client? Maybe it is safe when the wordpress site is https only, but is it really impossible for an evil 3rd party to eavesdrop to your communication and learn the secret codes when the site is on http?

        And you are practically not allowed to change anything in the plugin by yourself because then you will not be allowed to use services like photon (yet another unadvertised fact).

        And that is all the issues I have found when I just gave a small glance toward your plugin. I assume I could have gone on if I inspected other aspects, but I don’t care enough.

        On a personal note, since I saw your temperament on the yoast automatic upgrade discussion I will give you an advice: this is the internet, there are no facial expressions to see and no body language to read. Most of the time it is your personal decision how to interpret the “voice” of the written words, Maybe you should count to 30 and calm down before you write a reply to someone that you think was trying to offend you.

        • The numbers quoted above are bytes of code — not lines. If you want to count lines, the public 3.4.1 release has 90,889 of PHP, 16,997 lines of js, and 21,690 lines of css. Where you’re pulling 2 million lines from I’ll never understand. Core, by the way, in lines is 255,961 php, 58,222 js, and 80,836 css.

          So for starters, if you’re going to quote numbers, please actually get real numbers?

          Next up, if a user is using Jetpack for just one feature, the majority of that code just goes away. It’s never even included. So apart from having unused text files sitting on your server eating a couple megabytes, it’s really not a big deal.

          Local mode isn’t something we try to hide, it’s just something that isn’t that useful for the experience of most users. There are some plugins that will toggle it on for you, they’ve even been written about right here on the Tavern — https://wptavern.com/unplug-jetpack-use-jetpack-modules-without-connecting-to-wordpress-com

          I’ve also written in depth about why we ship Jetpack as a single plugin, as opposed to thirty or so separate ones — http://stephanis.info/2015/01/31/why-jetpack-isnt-a-collection-of-plugins-part-the-first/

          Secrets aren’t sent in plaintext with requests to/from Jetpacked sites — the request itself is signed with the secret, and then the signature verified. You can see a bit more of how this works in `class.jetpack-signature.php` if you like.

          Photon only works when there is an existing WordPress.com connection because that is what grants WordPress.com the right to host their images for them — their agreeing to the terms of service through the connection.

          And yes, thank you for your most generous counsel, I had not yet realized that being overweight is unhealthy.

          • I just followed your stats, didn’t bother to check what exactly were you counting so me bad here, but whatever you count the end result is similar especially when you remember that part of the core code is themes and libraries that are included as a whole when only part of them are used (I guess you can argue that this is how you should include 3rd party libraries, but in the case of tinymce IIRC it includes two skins that I never ever seen or heard used) and some libraries just for backward compatibility.

            WordPress has a design philosophy of “decisions not options” which means that the end result of core development is to produce a product which has very few execution paths which are not going to be used in the life time of a site.Links went out although the menu feature is not a 1:1 replacement for them and so did publish by email. I am sure there are some more areas of core to trim (pressThis….) but even an exporter is not part of the core now.

            This means that whatever liability in terms of security and bad software design the wordpress core has it is something that I have to agree to live with it or not use wordpress at all. There is no option of forking wordpress to my own needs as there is no obvious “fat” left to cut out of it.

            And still, I am upgrading wordpress when a new version comes out. first I wait for the .1 version and even after the qa is finished I will still run some real traffic over it to test even more execution path then the qa process tested before going full production with it. And this process is absolutely needed because new versions of core are know to break things because of some subtle changes in the way wordpress api works or 3rd party libraries changes.

            Now imagine this process needs to be followed for every plugin upgrade……

            For small plugins the answer is easy, I just fork them when needed and don’t really care to upgrade. But jetpack is just too big for that. Its development process is not transparent, its code is not audited by the same amount of people as core and it is not tested in as many different server environments. In the last year you have released 12 versions and from the change log it doesn’t seem like it was only a must fix security problems which means that you too easily open to feature creep and your QA process is not good enough.

            And about this “code not executed when disabled”, isn’t it basic security recommendation in the wordpress world to delete unused themes and plugins? do you remember timthumb?

            And no, how photon works is not important as it is illegal to use it with a forked jetpack under its TOS. So in addition to the code liability the is also the legal liability of using all those service with a forked jetpack. which makes forking it as I do to other plugins a dangerous thing to do without a continuous legal advice.

            As for the security….. you are bypassing all security practices of core so there is no plugin that can enhance the security of your communication, and since you do not follow any standard security protocol I am going to doubt your security procedure is actually bullet prof. In any case it is enough for someone to get control of wordpress.com by hacking or legal means to control all sites using jetpack without letting their admins to install any safeguards against it. And this is really the most unacceptable part of jetpack, and a part least advertised in the jetpack feature list.
            Everybody is aware that their google and FB accounts might be inspected by authorities but how many are aware that their silkroad clone can be remotely inspected just because they have installed jetpack to use the contact form feature?

        • WordPress has a design philosophy of “decisions not options” which means that the end result of core development is to produce a product which has very few execution paths which are not going to be used in the life time of a site.

          I really don’t know where you keep getting your information from.

          “Decisions not Options” is talking about user experience flow. We as the software developers should make smart decisions, rather than provide a thousand options for a user to slog through and try to make sense of.


          Links went out although the menu feature is not a 1:1 replacement for them and so did publish by email.

          Links is still shipped in core, just not enabled by default. You can enable it with one line of code:

          add_filter( ‘pre_option_link_manager_enabled’, ‘__return_true’ );

          or by installing this plugin:


          Also, Publish by Email is still shipped in core. You can find it on Settings > Writing.

          I am sure there are some more areas of core to trim (pressThis….) but even an exporter is not part of the core now.

          PressThis just got a huge rewrite in WordPress 4.2, and the Exporter is still bundled in core as it always has been. The Importer, however, has shipped as a standalone plugin for over about years now.

          And about this “code not executed when disabled”, isn’t it basic security recommendation in the wordpress world to delete unused themes and plugins? do you remember timthumb?

          I certainly do remember TimThumb. Its problem was that it was written standalone to be executed by calling it directly, not loaded through WordPress core — which is why it could be used when inactive.

          As a sidenote, the author of TimThumb has published articles recommending folks not use TimThumb, but instead use Jetpack’s Photon module instead: http://www.binarymoon.co.uk/2014/07/dont-use-timthumb-instead/

          And no, how photon works is not important as it is illegal to use it with a forked jetpack under its TOS. So in addition to the code liability the is also the legal liability of using all those service with a forked jetpack. which makes forking it as I do to other plugins a dangerous thing to do without a continuous legal advice.

          You’re free to use Photon in a forked version of Jetpack, so long as you’re still agreeing to the Terms of Service by connecting your forked version of Jetpack to WordPress.com. It’s necessary to grant us permission to host your images.

    • @markk5, George will pwn you every time. I recommend not getting into any spats with him.

  3. Jetpack is standard fare for most of the smaller sites I build. As pointed out in the article, it does a lot of general things very well, without going too in-depth. Smaller projects — “build small, build fast” — are a perfect fit for that approach.

  4. Oh my golly gosh,

    Is Derek Smart on Jetpack the same Derek Smart that coded up Battlecruiser?

    If so been MANY moons my friend!

    For those that never heard of it, Battlecruiser was an “indie” games in the days when “Indie” was damned near impossible to succeed at. BC was an IMMENSE game that suffered much criticism and much fanfare. Derek and I had quite a few discussions not that I can remember all the context of them now. But I was “all for it” (which made me unpopular at times) as I back then worked in the commercial games industry and well… “Knew the game” (the game being all that is played out other than the actual software).

    In respect to JetPack, never tried it. Most WP extensions I’ve not tried.

    Build small / build fast sounds good in practice but that paradigm either is believed and embraced or not. Its an oxymoron with PHP to begin with. PHP is a JIT on the fly compiler that is coded in C++ and compiled. By sheer nature that means there is going to be buckets of generated code that are both performance and resource hungry. I’ve not looked at core PHP C++ in. oh my, probably 8+ years. It was pretty C Array heavy which makes sense. Issues such as no multi-threading are sizeable hits for creating performance based applications. Its been promised for
    years but just when considering implementation its pretty complex. Bringing threading to what
    is essentially and interpreter engine that was not designed from the ground up to support such
    mechanisms that is written in a compiled language that does support it. Its a tradeoff deal.

    There is essentially if we are talking “build small build fast” we have to stick to what we can
    do. In C++ its possible to build small and fast. If we compare the C++ object code to that of hand coded assembler its not fast and its not small. If we compare PHP to C++ its not fast and its
    not small.

    PHP based application performance can have ALOT to do with the hosting firm. There you get what you pay for or less. 98% of all hosting firms are “you get what you pay for or less”. There is 2% that give you “better” for your buck and not a one of them that I have ever encountered has shared hosting.

    Blaming for example Jetpack’s loaded size (that doesnt mean lines of code per se, again, never looked at it) as a performance/resource degrading reason is not necessarily justifiable.

    If one is using a shared host, a VPS and even come of the clouds one has no clue as to what partitioning is happening at a data center, per machine, per sub network on and on. Heck, most folks dont even know what server (hardware) is being used to host them more or less anything else and its not like their is some authoritative body that goes from data center to data center making sure every penny the customer spends on services they in fact get.

    Tis’ why I tell people “Dedicated server” be it managed or not. Want performance? Then start where performance begins. Otherwise its like saying, “Gee… Grandtheft Auto 6 is really slow on my Intel Dual Core 8500 but runs great on my Core i7 Alienware game rig.

    Also same of local development. While Xampp, Wamp, Mamp , Flamps & Cramps are very easy to set up and get started do not bother to try gauge performance by them. Perhaps a rough estimate. There is a system running an entire slew of other code behind the scenes munching cycles.

    Its best to have a “REAL SERVER” even if thats generations back. I have a DELL an older DELL
    PowerEdge rack server w/ CentOS 6 on it that is used for mySQL and a Lenovo Core i3 Server
    used for application development. Ahead of it (if I want simulate) I have a Intel Core Duo box
    that can simulate being a connections server. All Cent OS 6.

    Do really need that? (Well yes) Does everyone? No… I use Xampp as well, but if I need get down to the “grits” I can do so.

    I dont for example fault Joomla for being bloated or sorta pokey given certain tasks/plugins. Joomla’s code is good. On a differing platform than PHP it’d fly, literally. Joomla Ported proper to say Java with its user misinterface redesigned for administrators and everyone else can pack it in and go home in as far as “small CMS” sites go and of course hosting providers offering Java just like any other platform.

    Java is harder to cope with for a hosting firm, but thats another discussion.

    Joomla uses alot of object oriented code and PHP swallows resources when it comes to OOP.

    I was shocked when a simple class we ported from a framework took better than 3K bytes (nearer to 4K) for instancing it .vs. C# which is was ported to was at a bit over 800 bytes. Again, flavor can vary. Some languages get heavy when using inheritance all of a sudden.

    On the other side of the coin if we’d used the Entity ORM of .NET .vs. direct Database management, WHACK.

    Point being, BEST performance you are going to get be that an ASP.NET application online, PHP Application online, Java no matter what, Ruby On Rails starts at the hosting platform.

    If you are expecting say WordPress with Jetpack (which again I have never used, looked at, I am going to assume Matt M. is not in tune with hiring coders that bloat code as a manner of purpose)
    to run nice and zippity aye on your $4.99-$14.99 a month shared hosting account then, well, why not use a Pentium 3 to run Windows 7 on? Because its too slow? Oh… But its a whole lot cheaper to buy a Pentium 3 for $10 than a core i7 for $1000? Well… hate to tell ya this but shared hosting, VPS hosting .vs. dedicated (managed or not) is in perfect paradigm with that.

    Heck from what I remember Derek Smart did Battlecruiser in Assembler. I loved (and hated) Assembler.

    A playstation one cant run playstation 3 games. But if it could what happens? Slower than slow. Do we blame the game or the playstation one? I can put Windows 7 and photoshop along with Firefox and MS Office and Autocad on a Pentium 4 with a gigabyte of Ram in it. I will be waiting LOTS for it to finish swapping ram in and out on the swapfile not to mention going away for lunch waiting for Maya or Autocad render some model.

    Is that the fault of Autocad’s latest or Photoshops latest? They are HUGE BLOATED beasts!
    But it might just be that the Pentium 4 really is the lynch pin. Maybe.

    The fact a LAMP stack will happily exist on a Intel Core Duo 7500 or a 4 CPU 16 core’s server is as material as Windows 7, photoshop and autocad on a P4.

    Put WordPress, Jetpack on a decent dedicated platform and go “Wow! It wasnt WP or Jetpack at all. Imagine that! I guess it was the $10 hosting”

      • Ok, sorry.

        Have you ever had anyone else online think you were he?

        This guy for the day (even by todays standards) coded a MASSIVE game called Battlecruiser in Assembler! Back in the old days of Atari 8 BIT, Apple II’s, Commodore 64’s etc. didnt have lots of options. 8K -16K of ROM and 32-48K of Ram (CPU’s 16 bit data bus yielding 64K bytes address space). But even as things opened up into the PC realms he did assembler.

        Very unique personality and took alot of guff’ for it. Alot of folks deem them the “Good ole days of computers”. Dunno. I think I shipped as much of my hair to companies like Electronic Arts as code LOL.

        • Ha yeah it happens from time to time. He started blowing up the “Derek Smart” web scene when I was still in grade school, so when I entered the arena I inadvertently learned a lot about him.

          WPT might as well change the title of this article to “Behind the scenes with Jetpack and the Derek Smarts”

          • LOL!!!!

            Yep he and I used to “Commune” before the WWW even came to be, back on UseNet, via email and that old thing called the analog telephone. He’s QUITE the character and oh my gosh were there some feud’s!

            I had alot of respect for the guy however. Doing it “his way” as the commercial game industry was (and still is) anything but that. When I left the industry in fact at various development houses the “consumer” was often also called “the addict”. Literally.

            Content and experience in the Entertainment created to tap nerve centers in the brain to become a compulsive addictive experience from scene to scene, level to level etc. tapping many of the centers that are EXACTLY the same for substance abuse addictions (hence the usage of the term).

            I personally dont play much. When I do I prefer real world simulations like WW II flight sims and such which pretty much cease to exist now, so instead its driving simulators. Just need close the blinds so knowbody peers in and goes, “Look! I thought I’d saw it all! There is a guy driving his TV Set with a steering wheels, peddles, a clutch, even a gated shifter!!! SUP WITH THAT!” LOL :)

  5. Thanks to a wonderfull Jetpacks’ team, for all the hardwork. Just started to use it on all of my WordPress websites, and it is simply incredible !


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: