The Facebook HipHop Open Source blog has posted a case study from Box about their migration to HHVM and some of the challenges and benefits that came along with it.

Reducing latency and increasing the capacity of our infrastructure have always been top priorities at Box. We strive to deliver the best possible user experience in the most efficient manner, and historically our choice of PHP hasn’t aligned well with these goals. I'm very happy to report that we've recently made very significant strides toward these two ideals by successfully deploying HHVM (the HipHop Virtual Machine) as the exclusive engine that serves our PHP codebase. In the rest of this post, I will detail how we use PHP, how HHVM works, the challenges we faced migrating to HHVM, and the remarkable performance wins it provides.

The post talks about how central PHP is to their overall technology stack and how, despite the work being put in, the processing of requests was starting to be a bit too much. In came the HHVM and some discussion about how it might be used there at Box. They started a yearlong effort to migrate their entire stack to HHVM especially since HHVM has almost reached parity with the PHP language itself. They talk some about the differences in design between the two and how the migration changed their deployment process. They also cover some of the other interesting things that come with a major migration including phased rollout and host-based conversion methods. Finally they share some of the statistics around the performance of the end result, including the better response times and reduced CPU graphs.

Code Climate, the popular static code analysis service, has made an announcement that will definitely help make checking your PHP application for quality and security issues easier - the release of the Code Climate Platform. This platform provides, among other things, a command line tool that you can use to run their analysis rules on your own systems.

Today, we’re thrilled to launch the Code Climate Platform − the first open, extensible platform for all types of static analysis. [...] What does this mean exactly? First, we’re open sourcing our analysis tools, including the engines and algorithms we use to evaluate code. We’re also enabling anyone to write static analysis engines that run on our servers by following a simple specification. [...] Finally, using our new Code Climate CLI, you can now run any Code Climate-compatible static analysis on your laptop – for free.

This is a great step forward to helping ensure the overall quality of your codebase and makes it even easier than having to rely on a fully external service for the results. Plus, with the specification you can write rules and customize the checks according to your application or framework of choice. They have a developer program you can register for to find out more information about that.

The HHVM blog has a new post today sharing the results of their first open source lockdown. During this time they worked to improve not only HHVM itself but how well it supports other open source projects using it as a platform.

The HHVM team has concluded its first ever open source performance lockdown, and we’re very excited to share the results with you. During our two week lockdown, we’ve made strides optimizing builtin functions, dynamic properties, string concatenation, and the file cache. In addition to improving HHVM, we also looked for places in the open source frameworks where we could contribute patches that would benefit all engines. Our efforts centered around maximizing requests per second (RPS) with WordPress, Drupal 7, and MediaWiki, using our oss-performance benchmarking tool.

They share some of the benchmark improvements made by the updates during the session including performance boosts for WordPress & MediaWiki. They also talk about the community involvement during the event and updates made to their own tooling too. The post then spends some time talking about their methodology on development and testing during the lockdown and how the results compare pre- and post-lockdown. The remainder of the post looks at some more specific issues and covers a few technical notes about software used and how the results were reported.

The PHP Roundtable podcast has posted their latest episode, part two in a series looking at semantic versioning, open source support expectations and licensing. This new episode features guests Colin O'Dell and Chris Tankersly.

Part 2 of an on-going series on open source. We discuss a number of open source topics including what the expectations are for support of an open source project. We also discuss how to use SemVer to successfully maintain an open source package and what we can do when SemVer is not an option. And finally we take a look at licensing and discuss why we need to be concerned with it.

On the Magenticians site there's a new post that provides an update of sorts, a post-mortem really, about their opinion of the "open source-ness" of the Magento product and project.

Little less than four months ago, we published an opinion-piece regarding Magento 2 and why we thought it wasn’t really holding up to the mindset of being an open source project. In four months, a lot has changed. [...] Magento 2 was (and still is) being marketed as a new platform which not only refreshes the entire code base, but also improves handling of the community its feedback and involvement. [...] Most of the original critique was therefore that, though by definition Magento 2 is an open source project, all the rest which should naturally come with “being open source”, severely lacked. It is one of our best read articles and linked from a dozen of websites; a timely status update is in its place.

They go on to update some of their original comments and note that things "feel more like open source" with changes including direct pushes to GitHub (not mirrored) and better external communication. They point out a few other smaller things including their developer hub, updated developer documentation and more informative blog posts about the project/project.

Alex Bilbie has an interesting new post to his site looking at the idea of open source guilt. He uses the term to describe the feeling you can get when a project falls by the wayside and you're not putting as much effort into it as you had before. He uses his own real-world project work as an example (an Oauth2 server and client).

I've willingly and happily poured hours of my life into both projects. [...] After leaving the university I moved to London and my life "got flipped-turned upside down" (as Will Smith once put it) which naturally resulted in a reduction in the number of commits that went into the projects. [...] I did my best with the emails piling up in my inbox but I also ignored many. [...] Releasing open source projects is a great feeling however there are a number of considerations one should bear in mind.

He makes the suggestion of four things to keep in mind when working on and releasing an open source project. These are things that can remind you (and keep you away from) some of the issues he's had in his own work:

Actions have consequences

People want to help

Your personal reputation is on the line

Popular open source projects work well when the authors are using the project regularly themselves

He also includes a few personal things he's going to do to try to make life easier and happier including roadmaps for projects, documenting via FAQs and being more honest about his own availability.

In this episode, Ben and Phil join forces with Loosely Coupled to talk about Open Source, burn out and briefly discuss their favorite open source projects. Jeff was out of action for a lot of it due to unexpected wifi troubles (in San Francisco of all places) so he sadly did not get to take part as much as he would have liked.

There were also a few questions taken from the listening audience about dealing with overly reliant people, explaining OSS to non-tech people and the OSS "clauses" some employer put into their contracts. You can listen to this latest episode either through the in-page audio player, by downloading the mp3 or you can watch the live video recording posted on YouTube.

Lorna Mitchell has shares some interesting results of a recent survey asking people how they got involved in working with open source projects. The results were from a poll announced on Twitter.

I did a very unscientific twtpoll recently regarding what brought each of us into open source. Plenty of people took the time to vote or retweet, so I thought I'd loop back around and let you know how it looked overall when the poll closed.

Not surprisingly, the largest group came from the "find a problem, submit a fix" category (40%) with the next in line being the group that open sourced their own code. The third category she mentions, coming in at 18% of the responses, was those seeking new skills either for personal growth or for their current (or next) job.

The SitePoint PHP blog has posted a tutorial showing you how to use the Solarium library to search SOLR. Solarium is a PHP-based, open source tool that helps make interfacing with a SOLR search instance much easier. This post is part one of a larger series covering the combination of SOLR and Solarium.

Apache’s SOLR is an enterprise-level search platform based on Apache Lucene. It provides a powerful full-text search along with advanced features such as faceted search, result highlighting and geospatial search. [...] If you’re using PHP then the Solarium Project makes integration even easier, providing a level of abstraction over the underlying requests which enables you to use SOLR as if it were a native implementation running within your application. In this series, I’m going to introduce both SOLR and Solarium side-by-side.

He starts with some of the basic concepts behind what SOLR is, what kinds of things it's useful for and how to get it installed on your system (using Homebrew). He shows how to set up a sample schema including a detailed look at the different types and required fields it will need. As this is just the first part of the series, it stops there and will get into the actual PHP code for the interface in the next edition.

Francesca Krihely has a new post today taking about one of the realities of using open source software. While the cost of it might be "free", in truth it isn't.

Why is it so hard to move off your old FOSS tools to new FOSS tools? Free and open software is changing the world, and has been for quite some time. While the price of open source software is usually $0 there are a number of hidden costs associated with building on top of new FOSS tools. The hidden cost is what makes community your biggest asset in open source.

She gives a more "real world" kind of situation where a company has a lot of legacy technology in place from years of work. She points out that moving to the latest technology has both benefits and drawbacks (including the "opportunity cost of moving slower" because of the shift). There's an emphasis put on the community around projects too. Without a vibrant community around it, even the best, most well-written code out there is going to stagnate. For a company that's relying on it for their product, that's almost not worth the risk.