Jeff Madsen has a post on his site where he shares his opinions about Open Source software and companies giving back to the projects they use and love. His basic idea is that they're "screwing themselves" if they're not contributing for a few different reasons.

This will be a short piece, so I’m not going to go down [the] rabbit hole right now [of project timing], but tell me one thing: When a construction company is handed a one-of-a-kind blueprint of a new house, do they respond, “Well, golly gee! This has never been built before? - ?I have no idea how long it would take”?

[...] If you are good at creating software estimates, you probably already know the Joel Spolsky guide to making (somewhat) accurate ones. Break it down into small bits that you can understand. [...] Now…here’s where we start honing in on my point. I may have lied to you a little bit above?—?that construction team may not know how long it takes to build a stud wall with wiring [...] because they use bloody pre-fab for everything these days!

Relating this back to Open Source, he links these "pre-fab" items back to Composer packages, Node modules, etc and how they can help make things more efficient (more than writing it all yourself). A lot of companies see OSS as a way to get free software they don't have to create or maintain. Unfortunately they don't take into account the work behind them and how nothing ever fits 100% so you end up making modifications. If you contributed those modifications back to the project that could mean never having to do it again in your own work.

He ends with a few recommendations for companies looking to contribute these fixes and suggestions back to projects including providing monetary support or looking at paid versions over free ones.

On the "24 Days in December" advent calendar there's an article posted from Kalle Sommer Nielsen that talks about some ways that you can give back to PHP including documentation updates, contributing to the core code and just helping out the community in general.

PHP has a tremendous community behind it, that community consists of you and me, and millions of others that help promote PHP by continuing to develop awesome applications that power some of the biggest websites in the world, but within this community exists a relatively small community that actively develops PHP, such as making it run on your favorite platform or making your favorite extensions compile and work or even keeps the documentation up-to-date. Today I want to dwell into that community, and perhaps giving you flavor enough to contribute back to PHP with code.

The article suggests several places you can give back including:

• updating and adding changes to the PHP manual documentation
• participating in the various project mailing lists
• reviewing pull requests on the project's GitHub repository
• writing tests for the untested parts of the language

Kalle wraps up the article talking about his own experience with the language over the years and how it ended up that he was the one to remove register_globals from the language one day.

Fabien Potencier has posted another in his series of tutorials looking at the next major release of the Symfony framework - Symfony v4. In this series he's covered some of the changes that will be coming in this release and what you can do to prepare. In this latest post he looks at the idea of "recipes" and how you can contribute them back to the project

Symfony Flex is not Open-Sourced yet, but I can already feel the excitement in the community. [...] You know, that "one more feature" that will make Symfony Flex the next killer application for the Symfony community.

People are worried about the opinionated recipe repository. Keep in mind that one of the main goals of Symfony Flex is to automate your day-to-day workflow for the happy path.

He reassures those reading the post that a package doesn't need a recipe to be installed and the "opinions" that the main repository uses around packages. He also talks about another recipe configuration option not mentioned previously: aliases. These allow for shortened versions of the Composer installation commands that are easier to remember than the full package name. He covers a bit about how it works in Flex and the process it follows behind the scenes when installing the package.

The SitePoint PHP blog has a post from the godfather of the PHP community Cal Evans about paying the price for open source - giving back to Open Source projects that you use every day.

Back in the early days of Open Source – when Dinosaurs roamed the earth and Rasmus was a young man – there were two types of open source projects we talked about: those that didn’t cost any money, and those that gave you the freedom to redistribute and modify the code.

[...] Fast forward a few dozen years and here we are, Open Source is now an ecosystem, not a user group that you and five friends attend, or a magazine to which you subscribe. The problem is that most of us have stopped talking about the different types of open source, we just assume it is both.

He talks about how PHP is technically both kinds of free but also points out that open source will potentially die out (as it is now) without one major piece - users contributing back, giving their time and effort to keep it (and related projects) free. He talks about how you can give back, and not necessarily monetarily. He talks about one of his own experiences with giving back (to WordPress) when his work wasn't accepted, but he also points out that even though it may be rejected it doesn't mean you should stop.

What ever project you are working with, take the time to give back. Don’t let Open Source die in our generation.

Preserve this great concept; this ecosystem that we have helped build and that has allowed us to build so much. If you are a developer, find your favorite project and give back. If you run a company or a team of developers, give them time on your dime to give back to a project. Help keep the Open Source ecosystem thriving for the next generation of developers.

On the SitePoint PHP blog Thomas Punt continues his series about how you can contribute back to the PHP language. In his previous post he talked about contributing to the PHP manual. In this latest part of the series he moves into something with a bit more complexity: contributing to the core of the language itself.

Previously, we covered contributing to PHP’s documentation. Now, we will be covering how to get involved with PHP’s core. To do this, we will be looking at the workflow for fixing a simple bug in the core.

Since submitting new features to PHP has already been explained pretty well, we will not be covering that here. Also, this article does not seek to teach PHP’s internals. For more information on that, please see my previous posts on adding features to PHP.

In this article he assumes you at least already have a working knowledge of the PHP source and how to locate/update code and execute it. He focuses instead on the bugfix process and workflow needed to:

• find a bug to fix
• create a test to reproduce the issue
• use a debugger to find the exact spot where the problem is
• and create a simple fix

In this case it's a pretty simple issue to correct, but there are much more complex things that would require more work than just a simple "if" check. This guide can help you get started on the correct workflow, however, and be sure you're handling things as the project expects.

On the SitePoint PHP blog there's a tutorial posted helping you get started editing and updating the PHP.net documentation, one of the most widely used parts of the PHP ecosystem.

In this two-part article series, we’ll be covering how to contribute to the PHP project. This will hopefully clarify what steps need to be taken for those looking to become more involved with PHP.

This first part will be covering how to contribute to PHP’s documentation, including how to request a php.net Account and what to do once an account has been granted.

He starts with a bit about why you should contribute back to the PHP project and how the documentation is a great place to start. He then gets into the structure of the documentation, the DocBook structure it uses and points to the online editor for the first time contributors. He includes a video showing how to use the system to resolve this bug showing an incorrect MongoDB Client example. For those that would rather do it locally, he shows how to setup and configure the source and required tools. He then shows the flow of updating the documentation, building the result and verifying the update looks correct.

Finally he talks about requesting a php.net account to push the changes back upstream and provides some general tips on things like style guidelines, page ordering and correctly versioning files.

On the Symfony blog they've officially announce their latest virtual Symfony Hack Day coming in March (on the 12th). This event is a concentrated effort from the project and developers to come together and solve issues over several hours.

Symfony has always been a project driven by a huge and active community. [...] Because Symfony has a predictable release schedule, we know that feature freeze for Symfony 3.1 will be at the end of this month (March). That makes the next few weeks of development really important!

That's why we've decided to organize an online hack day, and I would love if you'd join us. If you're an experienced contributor, great! If you're new, even better! This hack day will focus on teaching you how to contribute.

The event will be happening March 12th from 3pm to 8pm CET / 9am to 2pm EST and will focus around the #symfony-dev channel on the Freenode IRC network. They'll be focusing on how to get started contributing to the framework including a mini-workshop showing how to triage issues to creating a pull request.

On the SitePoint PHP blog editor Bruno Skvorc has a post sharing some of his experience contributing to an open source PHP project and the flow he followed to add in a new feature. The project in question is Gatekeeper, an "all in one", framework-agnostic solution for user authentication and authorization.

GateKeeper is a pretty nifty user registration, authentication and authorization library which uses its own database to store and query the user records. This means that it’s completely decoupled from your main app (so you can, essentially, use Postgre or Mongo for your business logic while using a completely different engine like MySQL for basic user records) and easy to tweak and extend.

[...] This post isn’t about Gatekeeper per-se, though. It’s about contributing to open source, and going about the right way to doing it.

He then breaks the rest of the post up into a few different steps in the contribution flow:

• Step 1: Ask the owner
• Step 2: Fork, clone, test
• Step 3: Plan of Action
• Step 4: Just Do It ™
• Step 5: Testing

He includes the code he contributed to the project and where each change needed to be made. He also shows how he tested the new feature and the results of calling his new method to count the number of records for a user, group, permission, etc.

In the latest post to his site Larry Garfield makes a charge to the community - both Drupal and the wider PHP community - to gave back in 2016 and make an effort to contribute in some way back to the projects you use and love.

At the end of 2014, I wrote a follow-up for Acquia's Future of PHP series. In that, I called on people to Build Bridges between communities through not just visiting them, but building with them. Build and launch a real project with some toolkit that's not your usual go-to tool, and then documenting and sharing that knowledge with others.

While recording another episode of the Acquia Podcast with JAM (who seems to like having me on for some reason), he asked me what was next. What was the next 2016 challenge to help build a more robust PHP community?

This one should be easy, right? Give back.

He suggests not only that you get out and give back but that you also do it in somewhat unfamiliar territory. He points out that with most of the software we use we're "standing on the shoulders of giants" and without these people giving their time to help the project, it wouldn't be where it is. He includes a few suggestions of things to think about when looking for a place to contribute:

• look for projects "affiliated" with the ones you usually contribute to
• if you've never contributed before, there's an even wider range of options (frameworks, extensions, libraries, etc)
• report bugs if you don't feel like you can contribute code

He does include a reminder that not all projects and communities will be a good fit for you and how you'd like to contribute, so find a good fit and then dig in.

Three contributions, to three projects, in any way, that is new to you. That's the ask. That's #PHPGivesBack2016. And then talk about it. Giving back is something to be proud of so be proud of it, and encourage others to do so as well.

The Voices of the ElePHPant podcast has posted their latest episode but this time it's another in their special "It's the Booze Talking" series. In this latest show they gathered together people from several PHP projects and other well-known individuals from the community:

• Tessa Mero
• Emily Stamey
• Amanda Folson
• Anthony Ferrara
• Larry Garfield
• Joe Ferguson

In this episode they talk about how they started in open source and contributing to projects. They also talk about some of their own definitions around what "contributing" means for open source and its projects. Cal also asks the group about how contributing to open source has helped (or hurt) their career. There's also some discussion about leadership and management in open source projects. The group also shares some of the "worst" things they felt when making their first pushes to an open source project.

You can listen to this latest show either using the in-page audio player or by downloading the mp3 directly. If you enjoy the episode and want to hear more (and other interviews with members of the PHP community) be sure to subscribe to their feed and follow them on Twitter.