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.

The FrOSCon conference has officially announced the call for papers for their upcoming event. FrOSCon is the "Free and Open Source software conference" held near Bonn, Germany with both workshops and normal length sessions.

As its key feature, volunteer speakers will hold a comprehensive range of talks and workshops. Additionally the event offers space and facilities to Free Software developers and projects to organize their own meetings or sub conferences. It is topped off with a fair of booths from FLOSS projects and companies. We are looking for contributions on current trends and development in all areas of Free and Open Source Software, e.g.: Operating systems, Software development, Administration, IT security, Legal aspects, Desktop and Education.

You can submit as many ideas as you'd like over on their call for papers form but be sure to get them in by the deadline - May 23rd, 2014!

In their latest post the HHVM project (of Facebook) has laid out the next six months ahead for the development and progression on the project. In it they talk some about their "themes" and overall Open Source goals planned for the first part of 2014.

The HHVM team has just wrapped up its planning for the first half of 2014. We'd like to share our plans, providing you a bit of context. We've been making steady progress on HHVM's compatibility with PHP in the wild, but we still have a lot of work ahead of us. We're using unit test pass rates as a proxy for success measurement, but you can help by adding HHVM to your Travis configuration, and reporting bugs and issues through GitHub. We are resourced to help support a couple of major HHVM deployments, which we hope has the side effect of exposing us to "non-Facebook" deployment and maintenance challenges.

We are also going to push for a more open development model, with the goal of increasing our community participation. We'll have more to say on what this means later on. Stay tuned!

They also cover some of the work being done to increase the overall efficiency, reducing CPU time and memory consumption. There's also mention of work being done on a guide to "hacking" in the HHVM, reducing some complexity in the compiler and the conversion to a full HNI extension interface.

In this recent post to his site Jeremy Kendall shares some of his thoughts about password hashing and a new library he's written to help make it simpler - event with an existing password hashing method in place.

He shows how to use this password hashing correctly with the "default" hash and how to store that in the database. His Password Validator library aims to help make this even simpler and adds in other features like rehashing and upgrading of legacy passwords. The remainder of the post shows how to use the library for these functions and how to persist them in the tool's storage decorator and interface functionality.