There are many ways you can contribute to Open Source: reporting issues, answering support questions, contributing docs, tests or code, and maintaining packages. I’ve been experiencing the last one for a few years, thanks to Thomas Rabaix, of Sonata Project fame.

I got involved in Sonata soon after picking it as the go-to tool for administration interface in my former company. I had been experiencing some bugs, and the code was simple enough for me to change it, and make a PR to contribute the changes back. At some point though, I remember getting a bit frustrated because my PRs were piling up. I looked at the list of PRs and I thought that mine were never going to be reviewed given the list of open PRs. So I proceeded to give reviews to as many PRs as I could, so that they were easier to understand, merge or decline. Then Sullivan Senechal joined the project and gave it, among other things, a much needed vision on versioning
Some time after that, when the project’s health was starting to get better, I got merge permissions too. Since then, I have been a maintainer and I have learnt some things about that job that I think are worth sharing.

The bus factor

This one is of tremendous importance: just like your production systems should avoid Single Points Of Failure, you should avoid them in an open-source organization. Many people should be able to merge pull requests, release new versions, or tweak repository settings. Of course, you should not trust just anyone, but if you notice you get regular contributions from the same person, you should definitely ask them if they would be interested in joining your team. Some might first say they are not worthy, and later on turn out to be great additions to your team. All will feel honored with your trust, and will often contribute even more than they already did. Always be looking for new team members even if you are already many, it puts less pressure on everyone, and allows better decisions to be taken. Some
members will sometimes need to step away from the project for some time, and that should not be an issue for anyone.

Managing releases

Composer is in my opinion the single best thing that happened to the PHP community the last few years, and, because of it, I think the approach people have towards version numbers shifted from marketing to something way more technical: backwards-compatibility. One of the most crucial responsabilities you can have as a maintainer is to make sure patch/minor releases do not contain any BC-breaks. Instead, you will often have to ask contributors to deprecate part of the API of your lib, while recommending newways of using your package.
The issue with the BC layers that are introduced is that they are often ugly, and can make your code harder to understand, and to contribute to. To avoid this, you should release new major versions of your packages as often as necessary, and remove deprecated APIs when doing so.
The corollary of this is that major versions should be boring, ideally just about removing old, ugly things, while minor versions should be the ones to continuously introduce new features.

This “release often” mantra goes for minor and patch versions too:
– The longer you wait for releasing major versions, the more crust you accumulate;
– the longer you wait for releasing minor versions, the bigger wave of bug
reports following them;
– and finally, the longer you wait for releasing patch versions, the longer your users suffer from bugs.

Our policy for Sonata releases is to do the patch and minor releases on demand: people can ask anyone of us for a release and it will be notified in a dedicated Slack channel that release managers monitor.
For major releases, we do not release as much as I would like, and I hope we can improve on that.

Making contributions easy

As a maintainer, you should make sure that the build is as stable as possible. Contributing a typo fix and getting a red build is terrible experience for contributors. To avoid that, you should never ever merge unless the build is green, and most tools will allow you to prevent that with some settings. You should also try to reduce uncertainties by using appropriate version constraints, and pinning versions for software you do not install through Composer. Do not commit your composer.lock though, that would mean your users would discover bugs before you get a chance to. Do add build jobs to test your software with future versions of your dependencies, and a job to test them with the lowest possible versions. Also when everything else fails, remove the tests that fail, even if they only fail sometimes for no apparent reason.
There is nothing worse than flaky tests.
If the tests fail in the CI, your contributors should be able to run them locally easily. Ideally, they should be able to just run make test and look
at the result.
If that fails, your contributors should be able to figure things out by reading the CONTRIBUTING.md and/or README.md files.

Reviewing code

Getting fast feedback on pull requests is always nice, and one of the most important feedback you can provide is that you do not understand the pull request. Require good commit messages, documentation for new features, and unit tests demonstrating how to use new APIs, or confirming that an issue is indeed fixed.
To avoid pestering contributors with style issues, automate away the style review, there are lots of SaaSes for this. Sullivan even wrote one and let us use it on Sonata.
If you can, integrate static analyzers like phpstan or psalm in your CI pipeline, it should detect some non-obvious bugs, or inaccurate phpdoc. With this out of the way, you should be able to focus on the big picture, and tell your contributor as soon as possible if their patch can be merged or not. Doing so as early as possible can avoid a lot of frustration.

I hope these tips will help you if you plan to become a maintainer, which you absolutely should if you want to grow as a developer: it will give you experience in areas that are crucial for deploying projects flawlessly but where you might not be able to train often.

When Andreas asked me to write something about the PHP community I immediately said ‘yes’. This community has become very dear to me over the past couple of years so I would love to share some of my thoughts.

This story begins many years before I even knew what PHP was.
When I was young I didn’t have a great relationship with the word “community”. To me, it meant conformism, in-crowd, bullying, gossip. I wasn’t a cool kid. I had great difficulty belonging. And by the time I was a teenager I kind of decided that I would be as independent as possible. Community was unsafe.

But as I grew older and gained more confidence, I did find communities where I felt at home. I was so fortunate to often have very nice co-workers. In my mid-thirties I joined a Zen meditation group. And by doing so, I became part of a larger spiritual community where I felt very much at home. It felt warm and safe being on the inside of a community and it became part of my identity. But everything changes, and the rebel in me started screaming and needing some space. Who would have thought that? My identity of being part of the Zen community in the tradition of Thich Nhat Hanh started to crumble. Some of the rituals started to annoy me, as well as the devotion that some people displayed towards Thich Nhat Hanh. And my spirituality expanded to include more than just Zen Buddhism. It felt like a pendulum. All the way to one side, then all the way to the other side. And right now it kind of stopped in the middle. The community of Thich Nhat Hanh is still my ‘family’ even though I don’t identify with it fully anymore. I still feel at home in it.

And then, at the age of 47, I became part of the PHP community. I was kind of nervous. In the spiritual community, I found myself among many people of the ‘feeling’ type. Many therapists and artists. More women than men. I was a bit scared to enter a community where the men were in the majority and where I expected to find people with a much more rational, thinking approach to life. Would this be a good match?

Up until then, my career had been lacking direction. Working was for paying the bills. Not very inspiring. Until the data scientist at the company I worked for, asked me to help him with some programming stuff. Then I discovered that programming actually gives me a lot of energy. That I really enjoy doing that! But if I was going to make this my profession, I would have to overcome my shyness and go meet the right people. And I did. I started going to meetups. Everywhere I went, I met nice people. No one tried to discourage me because of my age or my gender. I received a lot of help and mentoring to make my dream of becoming a developer come true. I received diversity tickets to go to conferences. AmsterdamPHP once organized a TestFest. I asked Rafael Dohms if I could attend and perhaps just watch what other people were doing because I could barely program in PHP. Rafael was very welcoming and during the event, he spent all of his time teaching me how to write unit tests. Mike van Riel played a big role in my becoming a developer as well. He was also at that TestFest where we practiced writing unit tests for phpDocumentor. After the event, I asked Mike if I could keep on practicing on phpDocumentor. Mike welcomed me to the phpDocumentor team and started mentoring me. He helped me improve my unit testing skills and programming skills in general and he answered many, many questions. It was Mike who had enough faith in me to introduce me to LTP where I landed my first job as a developer.

And then came WeCamp. Oh imposter syndrome! What if my skills were way too limited to participate? But I quickly found out that I had nothing to worry about. Such a great atmosphere! Any skill level was absolutely welcome. I felt included and at home. From then on I knew that the PHP community was also ‘family’.

I feel really rich and fortunate to be part of these communities. At the same time, I also see a danger. Remember that I shared that as a teenager I wanted to become as independent as possible? At the same time, I actually longed for a community. And when I found those communities I basked in the feeling of belonging. And I noticed in myself a feeling of “us”. I started identifying with that community. People outside of the community felt more distant. More like “them”. It’s so easy to find “us” a little bit better than “them”. I noticed that it was very tempting for instance to blame other people for harming the environment. While “we spiritual people” were so conscious. It was also easy to be oblivious to the challenges of our bosses when the going got tough for the development team.

These are mini examples of what we are seeing on a much larger scale in the world. There is so much polarization going on right now and it is getting more extreme by the day. It is so tempting to choose sides. To choose the safety of our communities and close our hearts to the outside world. It’s so easy to judge people in terms of good and bad even when we know so little about them and the situations they are in. It’s challenging and tiring to constantly put ourselves in other people’s shoes and yet I feel we should, as much as possible. At the same time we should be mindful of our boundaries. We should dare to speak up without breaking the connection.

When I was still an outsider, I experienced the PHP community as very friendly and inclusive. I have met so many open-minded and open-hearted people. Yet I know that we are all human and prone to closing our hearts and our minds when we find ourselves under pressure or under attack. May we support and remind each other to keep our hearts open to all those others out there. May we actively look for similarities instead of differences. For instance that loud and dominant woman from the other department, she has grandchildren that she adores. She can talk about them with so much love! That person who is always complaining is actually under a lot of pressure. Hmm, I tend to nag as well when I’m under that much pressure. When we look deeply, we can always find aspects in which we are the same. When we focus on the sameness of people, we can more easily access our compassion. May we extend our sense of community to include as many others as possible. May we all belong.

Happy Holidays!

Growth is the part of every human being. We only grow when we start doing things that we did not do before. But, with time we develop a tendency to stay in doing what we are used to. The tendency is called being in comfort zone and we all know nothing grows in comfort zone. This is a journey of me and how dev community helped me to do new things.

At the beginning of my career, in the end of 2012, most of my time was spent with college and office tasks and did not have time to do anything except that. After some time in mid of 2013, I came to know about the developer communities and the meetups that are happening around. So I used to take out time and attend the events. With all the new faces and different kind of people, it was me just going to the event listening to the talk and coming back. But later I realize that Networking is also a great part of the meetup. Started from interacting in the group to later knowing some of them and sharing knowledge was helping me connect with people who worked in similar sectors.

In the year 2014, I gathered all the courage and decided to be a speaker in WordCamp Nepal. It was a huge step for me to go talk in an event that is one of the biggest by a community. Luckily, I was selected as a speaker and had a chance to speak. They helped me to improve my delivery skills and provided with different resources to help my presentation be better. After being a speaker, attending events was more fun because there were more people who I got connected with.

There came a time where the number of meetups in Developers Community dropped in Nepal. My college was over and I had some free time now. So, In June 2017, me and my friend Sujan, decided to organize PHP meetup. We both have never organized a meetup and it was totally new for us. This led us to interact with the previous meetup organizers. Some of them whom we have known before but not interacted much and some new people. Now, with the very supportive suggestions and rough planning, we were all set to organize the meetup. It was hard in the beginning to call for paper, finding a venue, getting the sponsor and managing the event. But it all went good and with the help of other community members the meetup successfully. after that, we organized 3 more meetups in a span of a year but we could not continue to do it due to many circumstances.

If you want to do something in your community than you should plan to do it because there is a whole lot of people in the community that are ready to help. The developer community is a place where it grooms and supports you to do things out of your comfort zone. So being part of it not only helps you to know new people or things but also to do new things and get out of your cocoon.

On the fifth day of blogmas a community member sent to you their FIIIIVE TOP TIPS for team agility!

Welcome reader,

Hopefully, unlike me, you are not already stuffed full of mince pies, eggnog lattes and on your 27th viewing of Elf. As we go into the new year, now is a great time to reflect and make small changes that should give you months of pure joy during 2019 in your work.

When I was asked to contribute, I realised I owed so much to this community for their help and support over the last year (especially at WeCamp) that the only way I could ever hope of repaying that back is by paying it forward.

So without further ado, allow me to share the most common problems I come across in organisations and teams as an Agile Coach and offer you some approaches you can experiment with (and I have used) to help improve your processes and team joy. Think of all of this as homework over the festive season. Yes, it is the post that keeps on giving.

Stop Starting Start Finishing

If I got paid everytime I saw individuals assigning work to themselves instead of working to keep the amount of work in process as a team low. I’m pretty sure I could have retired by now.

It may seem counterintuitive to do less to go faster, but you gain in terms of quality and no rework on defects, which leads to delighting your customer first time everytime.

Here are the books that cover this in more detail, I keep them in order of preference, however if you’re not in software development then switch A and B as it will may be easier to relate more, or you know, do what you want, i’m not the boss of you.

Focus on smaller deliverable chunks of work and keep asking what is the value and what is the goal and you’ll be on the right approach.

• The Phoenix Project
• The Goal
• The Toyota Way
• Mythical Man Month

Collaborate

You are not an island, you should be working on building those relationships with others, in your team and community. These are the people who can give you guidance when you need it the most.

Mob or Pair Program with your colleagues and invite others from across the business into the mix, tis the season of goodwill. Open your work to them and you will be amazed at the useful information you get back, nothing brings me more satisfaction than seeing a novice understand your world for the first time, don’t miss out on those moments.

By opening up and having a meaningful discussion on approaches or techniques, you start to build trust and can move on to meaningful experiments, teams who do less of this are often struggling with perception issues. I find being as open and visible as possible allowing constructive critique negates this and often people outside the team will move blockers and impediments for you.

The second tip here is to tell stories. “User story mapping – Jeff Patton” and “Example mapping” are great techniques to discover the unknown about work yet to be done. In here Cynefin and Clean Language can also help as techniques to help break down the complicated into simpler deliverable pieces. See how much you can discover about these tools and then go and share with the community what you’ve learned.

Seek feedback

No, don’t just seek, embrace feedback. I don’t see teams challenge themselves to improve often enough, that stale Definition of Done, team values or other parts of the process are not reviewed often and opportunities to improve or check in with each other are missed.

Start from where you are, create mini experiments that you all can agree to try, think scientific method, from here make it visible on the wall if possible, so you are all constantly working to prove or disprove the experiment and you can see the progress being made.

All of this starts to allow the team to view themselves from the outside in and become comfortable with the feedback. In turn, once comfortable, you can begin the process of being more honest about areas for improvement and this leads to effortless continuous improvement indefinitely and helps the team change and adapt when members leave or outside influences asserts pressure on the team.

Look after yourself

Don’t burn out, this is the toughest tip, you are on a journey and work will get tough for various reasons, agree as a team how you can support each other and tie this back to team or company values. Speak to your HR or People department who will only enthusiastically help create support networks within organisations. If any knows of the right way to do this outside the UK then please feedback.

If you are a line manager then maybe some of the following will allow you to help and enable others. Here are some tools I like that focus on the person and keeps you in a listening state of mind.

The Coaching Habit by Michael Bungay Stainer is a great place to start, follow this up with Clean language questions to help you focus on what the other person has said without reinterpretation.

That being said, the simplest thing, is to change the environment you are in by going for a walk or a coffee and just talk, that may be more than enough for the person in that moment. This is what I wish I could teach all leaders.

Have Fun

It’s Christmaaaasssssssssss 🎉🎉🎉🎉🎉🎉

Celebrate your strengths as a team, Improve your retros by playing Retros against Humanity, board games, team lunches and chatting, Exploding Kittens, quizzes and any manner of entertainment that introverts and extroverts can enjoy, also for more formal retros look here other fun ideas (http://www.funretrospectives.com).

To be honest most of my job is looking for opportunities to play games with people which means I need to be open and honest about what I like so I can find out what others like, I am yet to find a team ready for the hungry hungry hippos tournament I want to run, although in my new role, I have been given a team who do team lunches and board games every week and I look forward to this day the most.

You are in this together so have fun and look after each other.

Then tell the community about that one great thing you did and really helped.

I wish you all a Merry Christmas and Happy New Year!

What We All Do

As developers the core of what we do is probably pretty similar. We probably work on tickets or stories or some other tracked and recorded issue. This may be in a tool like Jira or Rally or Pivotal or it could be tracked in an Excel spreadsheet or even via email. In some cases, it’s just a post-it or a couple of lines in a notebook that we keep in order to not lose track of what we’re asked to do. But someone is asking us to make changes to the software (it could be us).

After that we have the process of actually writing or modifying the code. For me and for many I know it’s roughly this – create a branch, make the changes, commit the code (one or more times), push up the branch as a pull request. After that, there’s the waiting for feedback, making changes based on that feedback and then finally the code is merged back into the main code branch.

There’s more details, I’m sure, but it’s probably not too dissimilar from what you might be used to. For us, the feedback or code review is a critical part of our process. If the code doesn’t get approvals from the right people or enough people it never moves on to the merging part of the process. We have a server that knows about all the different projects and repositories as well as the rules the team has for how many approvals it needs and from whom. This server also does a lot more for us that I’ll get into later, but it didn’t start with all of that.

How It Started

In the long long ago, but at my current company (I’ve been here eight years which is close to an eternity for many developers I know) we worked with code in SVN. Branching was easy but merging was a nightmare, so mostly people just worked in the main branch and then when a release happened, someone would copy the files into a release branch and away we’d go. Shortly after I started I converted us to Mercurial. Mercurial, if you’re not familiar with it, is quite git-like but at the time the tooling was much better for Windows developers compared with Git. Funny enough, Git and Mercurial both began life within a week or two of each other.

Our process then was that each developer would “fork” the repository and do their work and then when the code was ready, they’d let the QA team know and when they were ready, they’d let me know and I’d pull together and merge all the code they’d asked for. If it failed due to a merge conflict, I’d let the developer know and they would merge in “default” (the “master” branch of a Mercurial repo) and then we’d try again. I was the human integrator. I got to be pretty good at it and out of the hundreds or thousands of merges I did manually that way, I only made a small number of mistakes. But even those were too many. So I set about creating a set of PHP shell scripts that would speed up the manual entry of commands I was needing to enter multiple times every day. Think of it as fancy macros that would take the list of repositories and branches that QA wanted integrated and this tool would spit out the commands that I needed to copy/paste and run.

After doing this a bit and smoothing out any rough edges, I updated the code so that given the same input, it would run the commands. Of course error handling was still manually done. When a merge failed or when we needed multi-repo merges to happen in a transaction — think web code that relies on database changes that are in another repository — if the merge on the latter repos failed, I needed to undo the merges I’d done previously. After doing this a lot of times I found the various patterns and wrote some code to automate various cleanup and undo activities. Of course I was still a human conditional statement and had to figure out which sort of failure I had run into and what the appropriate fix was I needed to run.

As I’m sure you can guess, these scripts eventually got combined, I was able to make the determination of what sort of failure and how to clean it up I might run into, but still, all of this was manually executed based on input from the QA team. After running this way for a couple of weeks without needing to make changes, I built a UI for it. Instead of asking me to do the merges, the QA team could use the UI and make their own requests and the code would execute it and either let them know it was all done successfully, or tell them something had gone awry and what needed to be done to resolve it.

Going Further

At one of the many conferences I attended, I saw Jeff Carouth speak about some of the automation he and his team had. They used emojis in the review comments on github to indicate a pull request’s ability to be merged. I forget if it merged automatically or not, but I remember learning the developers on that team could request an environment be created for testing that pull request and it would be automatically created. I wanted that.

Sometime around this point, we moved from an internally hosted repository to Bitbucket for hosting. There are certain things you give up when moving from hosting your own code to using a service. One of those is that the repositories are no longer a part of your network. This means that events that happen on the repository cannot send requests or “webhooks” to servers that are part of your internal network.

What I wanted, what I needed, was a server that would straddle the edge — it needed to be publicly accessible but also be able to make API calls to servers that were part of our internal network. What this would allow is for an external service, like Jira or Bitbucket or Slack to make a request and something on our network could respond to it. This could be Jenkins causing a build to happen, or a message to go to a Slack channel or a text message to be sent or any number of things.

Webhooks

Eventually, I got the server, but it was a number of years later and my responsibilities had grown to the point that I didn’t have a lot of time to implement any of these things myself. What did happen ultimately has been great for the project and amazing for what it provides to the developers on the team. We hired my brother as a developer. I was able to tell him about my goals and ideas for the project and fortunately, he had the time to start implementing. As such, in further paragraphs, please understand that “we” is almost always referring to my brother implementing and coding the entire project but with both of us collaborating on the ideas.

Using Zend Expressive’s middleware based framework as a starting point we’ve found over the past few years that the possibilities are endless. We were able to not only integrate my integrator tool, we were able to enhance it greatly. Now instead of polling the repository for changes, the moment a pull request comes in it will trigger a build on the Jenkins servers that are on the internal network. When the builds complete, or comments are made on the pull request, the Webhooks server can post a status to Slack. Additionally it checks a configurable set of criteria, including the builds have passed, there’s the right number of approvals, the right number of people in particular groups have approved and that there’s not any comments that change this. The comments can be that another individual’s approval is required or that the author’s own approval is required and more. Assuming all the criteria have passed, the Webhooks server can either automatically rebase and squash the code (again all configurable) or let the author know that they need to rebase.

We follow a rebase workflow for most projects. This is mainly because QA is able to test a pull requests on a branch and know that the code they’ve tested will be identical to what it will be after the merge. This leads to another feature that was added more recently. By posting a command in Slack, developers or QA can bring up a sandbox set of servers for our applications on whatever branches or code versions they desire.

The webhooks project started simply and has grown to become an even more important part of our workflow than we initially thought it would. Much of this functionality is configuration or initiated through Slack commands. These commands are all controllable via an ACL (access control list) which is also configurable through Slack. We can also set up automatic merges, rebases and Jenkins runs. We can manage email configurations through Mailgun into one of our products. You can look up Twilio error logs and you can ask the server why any particular pull request hasn’t merged yet.

Because of the ease of development using middleward with Expressive, some of the commands we’ve built are just for fun. There’s a feature to send an inspirational message to someone and even one that would allow you to order a burrito.

Let Computers Do the Boring Things

The point of all of this is that you don’t have to start off with a server that can handle everything. That’s not feasible. But you can start out and automate a little bit that makes your life a little bit easier. Then iterate on it. For us, we started with automation of merging code, later we added creation of environments, rebasing code and much more. It means the human developers can focus on the parts of the process only they can do – writing and reviewing code, while computers handle the boring, repetitive and error-prone stuff: rebasing, merging, bringing environments up and down and deployment. This will let you focus on the more interesting things like coding, solving problems, and going home on time.

About giving…

Traditionally, at least in Western cultures, December is a month of holidays and celebration. Often these festivities involve gifts, whether they are put under the Christmas tree by a white bearded man and his reindeers, delivered in a burlap sack by another white bearded man from Spain or exchanged at a family dinner. But as we hopefully have learned, not all those gifts have to be large, expensive or material to make an impact. Sometimes the most joy can be found in sharing moments with family and loved ones, having dinner together, bringing up old memories and creating new ones. All it requires is accepting their presence and sharing yours.

Also in our PHP and open source communities we put a lot of emphasis on giving or giving back. In December there is 24 Pull Requests, there’s Hacktoberfest in October, and there are hackathons and code sprints throughout the year. This is not without a reason: a lot of open source projects deal with a lack of capacity or (financial) resources for maintenance. However, a focus on giving might also be a barrier for people to enter the ecosystem. For newcomers, the expectation to give back can be paralyzing: What projects do I need to help on? Should I open-source parts of my own code? Do I need to (be willing to) speak at meetups to attend one?

… and accepting what’s given

Maybe it’s better to focus on making full use of what the community has to offer first. Once you accept the things others gave to the community, giving back will often follow naturally.

For example, the next time you need a logger, event dispatcher, dependency injection container or router, please don’t create your own. There are numerous implementations of these available on Packagist. Unless you really have a revolutionary approach, the world probably doesn’t need another one, whether closed or open source. Overcoming NIH syndrome helps the open source community focus efforts on the few implementations that really matter. For a healthy ecosystem, maintenance effort and usage have to be in balance. A well-maintained package that nobody uses is just as bad as a popular package that suffers from a lack of contributions.

Once you start using more components that are already out there, opportunities for giving back will arise spontaneously. If you run into a problem, report an issue. Or sharpen the details on a bug report sent by someone else. Maybe you can try to fix the problem and contribute it as a pull request. If that does not succeed, you might be able to help the maintainer by writing a failing test to reproduce the problem. Perhaps, based on your own needs, you develop a new feature that you can contribute back. Also remember that not all contributions have to be code. If you find something unclear or unexpected when using a package, that might be an excellent opportunity for a documentation improvement. And if some open source project ends up saving you a lot of time, why not thank the author by sending them a postcard or ‘thank you’ tweet, or supporting their work on Patreon?

I experienced this effect myself last week. Just using a package for a few hours led to two opportunities for pull requests that, albeit small, will hopefully save others some time.

Beyond code

But the community has more to offer that you can take advantage of than just code. Go visit a meeting of a PHP User Group near you! Just by being there and talking to fellow developers you give back your knowledge, experience and ideas. Maybe you will get inspired to give a talk yourself sometime, or help out with organizing a next edition. Meet new people at conferences. Read blog posts, listen to podcasts, and realize that you too have experiences that are worth writing and speaking about. All it requires is accepting the presence of others (whether online or offline) and sharing yours.

Fin

Yes, the community needs more involvement and contributions. But first and foremost, don’t forget to accept all the great resources people in the community are already giving away to you. If you do so, the opportunities to give something back will come naturally. And remember: no contribution or gift is ever too small to make an impact.

May you give and receive lots of joy this December!

Once upon a time, I was called a hobbit at a conference and it served as my introduction to the greater PHP community.

Since then, it’s been a whirlwind of ups, downs, short jokes, open source contributions, conference talks and more. However, let’s go back to the beginning and see how the community helped me get to where I am today. I will skip briefly to the ending, not so much a TL;DR but more of a “wow” factor. It’s to hopefully drive the point of my story home quickly. The point is this: if I ever get married the attendance list will look like a who’s who of the PHP community.

I started programming at the age of 26. Before that, I was a bartender as well as a guitar instructor. A lot of people don’t know I have a genetic condition which requires me to take steroids daily to stay alive, it’s great /s. Neither of my two jobs gave me health insurance (America!) so I looked for an avenue to get insurance and out of bartending. I read a post on Reddit from a programmer about being able to work from home, make good money and I didn’t need a college degree. I tried college a few times and neither time it worked out for me. A google search led me to Codecademy which in turn pointed me to Treehouse. I did the HTML, CSS and JS tracks (tracks back then weren’t what they are today). Immediately following the JS track, the very next video started down PHP so we could build a cart. PHP was something I had never heard of before this video. My mother at one point thought it was PCP, a hallucinogenic. I quickly learned the power of the include, require, dynamic date values and thought I was cool. Who knew the cool shit I would learn next.

It wasn’t until I was accepted into an internship program that I saw the power of the PHP community. The office we were at was about 45 minutes north of Atlanta but we trekked down on a cold night for AtlantaPHP. It was there I met Chris Spruck, the start of one awesome friendship which continues to this day. As I kept returning to AtlantaPHP, I kept meeting more people. I had the honor of meeting Ben Ramsey (who I thought was Ben Edmunds… a story for that wedding I suppose), Phil Sturgeon (who to this day we talk APIs and bicycles), Davey Shafik (a great advocate for diversity and mental health), Cal Evans (who hasn’t he had a hand in guiding?), and more. These people would be instrumental one way or another. Through this small community, I tapped into the larger community with Twitter. I followed everyone I could even if I had no business following them. I was in awe, it was like a kid in the candy shop. Brilliant people talking about concepts I’d never heard before. Things like HATEOAS, DI, CI, CD, HTTP, and 123s! Through this community, I got my first real job offer and led me to the next set of brilliant people, the Germans: Arne Blankets, Stefan Priebsch, and Sebastian Bergmann. It was through these guys I learned the power of PHP, the brilliance of OOP and I learned how to write a unit test.

At this point, you must be wondering where the hobbit thing comes to play so here it is. With this big kid job, I got a big kid conference ticket to Sunshine PHP. My first conference and I was unashamedly star struck. Through Twitter and IRC, I had a loose idea of some people I’d see there from Cal to Joe Ferguson to Phil and a few others. But one person I met who would ultimately change my life in more than one way was Jacques Woodcock. After a weekend with him at Sunshine, and through Twitter; he saw something in me and offered me a job to work with him and Elizabeth Smith, who is brilliant and I am not overstating that. While that only lasted 4 months, it opened more doors for me to speak at Nashville PHP (my future home), as well as Upstate PHP, Nomad PHP Lightning Talks, and more. But before most of that happened, I was called a hobbit in less than fun terms by Samantha Quinones. It shocked me and kind of popped my excitement. At the urging or some, a blog post later appeared detailing what was an incredible conference experience minus this one thing. Within an hour tweets and emails came in from people I didn’t even know offering support. People went out of their way to make me feel welcome. Samantha herself immediately reached out and apologized. Samantha and I even joke about it today, along with the majority of the community. But it was that incident that really showed me the PHP community cares.

In my short time in the community, we’ve had plenty of GoFundMe’s for elephpants and developers who need some help in between jobs or when tragedy strikes. When one of us loses a job we are quick to tweet out recommendations and words of support so that they are never without work for long. We respond to calls to action like when two conference organizers bit off more than they could chew and Cal put up the signal and helped them raise the money they needed. One of those organizers was me, by the way. This community has taken me across the country for conferences and helped me build meaningful relationships with people I would have never had met if I wasn’t writing code. This community was there when I moved to Nashville and I was immediately welcomed at NashvillePHP. However, one of the best memories I have of the PHP community being incredible isn’t at a PHP conference, but it was going up to NYC for 24 hours to see Ben Edmunds and his fiancé for their wedding party. What started as a day of drinking and bantering almost turned into Phil Sturgeon and I getting into a fight with a hot dog cart vendor and finished with me sleeping on Ben’s couch. These are the friendships I could never replace and the memories I wouldn’t be able to create without this community. It’s because of these friendships and connections I was able to coordinate getting David Stanley and Ben Edmunds to Nashville for my birthday and putting on a panel discussion for our user group that included Nicolas Grekas, Fabien Potencier, Ryan Weaver (as shoeless as you’d expect), Jacques Woodcock, Rachel Weaver and more.

I can’t possibly list all the friendships, acts of kindness and more that have happened during my short (hehe) time in the PHP Community, but I can tell you this: I am forever grateful and indebted to the people in this community who took a chance on me and forever grateful for the amazing friendships I have today. These people are the ones who see my tweets about anxiety or depression and reach out, celebrate successes together and make life better. The ones who will offer me help when I need it, and ask for my help even though I never know what I’m actually supposed to do.

As I look back at where I today, working on a team of people way more brilliant than I am (people like Jonathan H. Wage, Pablo Godel, Dan Revel, Jonathon Suggs, Cody Covey and so many more. I definitely married up in this case). I wouldn’t be on this team if it wasn’t for the community and the doors people opened for me. And because of people opening those doors, it’s my turn and my mission to open as many doors as I can for newer developers.

This community is so much more than framework flamewars (Laravel vs Symfony anyone? We all know the real answer is Kohana), debating if braces belong on the next line or not (they do), whether you should use Vim vs eMacs (PHPStorm, duh), or what conference is the best (Southeast PHP was pretty baller). Its identity for people, it’s a community that may or may not exist IRL for some but it absolutely exists online. Whether you know it or not, being a part of the community helps people far and way in ways. Some people live in remote areas where they may be the only programmer and our online community gives them belonging. People who were lost may have found happiness and solace in our community. It’s a resource for others to get that jump start in life they need. It’s friendship at the most basic level.

Attend your local user group and introduce yourself to someone new, just like someone did when you were new. If you don’t have a user group, roll up those sleeves and get one started. All you need is one more person. If you can’t for time reasons, or life is in the way, join NomadPHP, it’s a wonderful resource. Join us on Twitter and use the hashtag #phpc, introduce yourself and be prepared for something awesome.

We can’t wait to meet you.

I’m going to take some time to reflect on my introduction to the PHP community and how that’s affected my life.

I started programming and shipped my first web site when I was around 11 years old. I started with QBasic, then HTML, eventually making my way to Perl. I was homeschooled, so was able to begin working at 15 years old at a local computer repair / networking company near my hometown in Alabama. I started down the path of working in IT for awhile, with various small programming projects on the side. My first corporate job was at a robotic automotive manufacturing plant, I was hired to do IT support there but eventually saw the need for reporting and data visualization of the production processes. This evolved into my first job as a software developer and was also the first time I wrote a line of PHP code. Back in the PHP 4 days.

Another robotics engineer at the company hosted an NFL site/forum that was written in PHP so he introduced me to it there. We eventually built an app for reporting the plant’s various data using PHP, MySQL, Python, VB, C#, and lots and lots of duct tape. Thinking back on that app, it was some of the worst code I’ve ever written; SQL queries directly in views, no idea about APIs, security issues at every turn, but it solved a huge business need and was one of the most exciting projects I’ve ever worked on since it combined the digital and physical worlds in a very tangible way.

What really stuck with me most from this experience was the accesibility and flexibilty of PHP. I gained experience with many different languages, learned much better design patterns and best practices, but the experience of being able to create something so useful, so easily, with PHP really left an impression on me and it became my language of choice for web development.

I became involved with CodeIgniter a few years later. I ended up moving to Jacksonville, Florida for a web development job that was mostly in PHP and Javascript. Which was a pretty transformative experience for this Alabama boy. Moving to a new city sparked my love for travel and it led to my entry to the PHP community.

It was there that I started using CodeIgniter for several of our projects, which lead to getting involved on the CodeIgniter forums, #phpc, meetups, and eventually open source development. I still remember one of the first meetups I went to, Cal Evans was in Jacksonville promoting his employer at the time, Adobe, and trying to convince us all to start developing in Flex. I wonder how many people’s first exposure to the PHP community was from Cal Evans. That’s a damn scary thought…

I spoke at my first conference a few years later. Which was directly tied to my open source development and the friends I made there. I met Phil Sturgeon on the CodeIgniter forums, we started collaborating on open source software together, and built a friendship. Phil was organizing a conference in New York City and invited me to come speak. It’s really amazing how something as small as a forum post can evolve in to speaking at a conference and a long term friendship. Actually now that I think about it, I met two of my co-founders on that same forum and it turned in to us building multiple companies together over the years.

This community is one of the most inviting development communities I’ve ever been a part of and it has greatly improved my life. It started with a horribly written piece of duct tape software, a move, a forum, and then a meetup. Here I am now, 12 years in to using PHP, and it has given me the opportunity to do so many things. I’ve moved around the United States. I’ve met some of my best friends at conferences, on forums, and via open source projects. I’ve had the chance to speak at conferences around the world. I’ve met some of the smartest and kindest people I know. Been exposed to so many cultures and ideas. Worked on some really awesome projects with amazing people. Everyday I’m thankful for the opportunities presented and how much the community we’ve all built is a part of that.

In closing I want to implore you to do what you can to strengthen the community and add a bit of yourself to it. That might take the form of going out of your way to answer the newbie questions on forums, IRC, or slacks. It might take the form of giving talks at meetups and conference. Or it could be something as simple as going out of your way to show someone something new that helps them level up just a bit.

I hope that in another 12 years I’ve helped a few other people have the same great experience with you all as I have. This is our community, let’s appreciate it and contribute to it’s growth. As the year wraps up, use it as a good excuse to reflect back on your experience as well. I hope you had a great year.

During the last weeks we’ve read a lot about the community around the language PHP. And it seems to have influenced a lot of people.

And usually all the ideas about the community evolve around abstract ideas like learning or encouragement. Usually it’s all about non-monetary things.

But sometimes that’s not enough. And in those times the bonds of the community are strong enough to collect money to make things possible for fellow PHP-Coders that otherwise would not work. Whether that’s collecting money to bring a community member to the community or to collect money for the bereaved of a community member. People that can and want to, give a small amount. And these small amounts from a community add up. And make things possible.

And it’s one thing to reach out to the community to tell good stories. But it’s a completely different thing to reach out in bad times. To reach out and ask for help. But exactly that is it, what makes up a great community. That people dare to reach out in bad times and ask for help.

Yesterday I’ve seen this tweet by Cal Evans.

Dear PHP Community,

Let's help a child have a Christmas. ElePHPant Santa UNITE! 🙂https://t.co/d8nfPwkb3M

— Cal Evans (@CalEvans) December 23, 2017

Go, follow the link and have a read.

Let’s stand together and make this christmas an unforgetable one not only for a kid but also for its parents. Because we can!

Chances are that you’ve never heard of my company Spatie. We specialize in creating Laravel applications for our clients. Our team is rather small: we consist of only 6 developers and one manager. On first glance we are just a web agency like there are so many others. But there’s one thing that sets our company apart: we have an open source first policy. We try to create and contribute to open source as much as possible.

Currently we have around 170 open source repositories on GitHub. Our packages have been downloaded nearly 8 million times. They are being downloaded 800 000 times each month. Git awards is a site that ranks GitHub organisations based on the amount of stars their repos have. This past year we managed to take the #3 spot on Git Awards’ worldwide PHP developers list. And yeah, I know that the amount of stars is not an important metric, but it’s still a nice achievement for a smallish team.

This all did not happen overnight. Read on to learn the story behind our open source efforts.

The first package

When I got started to work for Spatie, somewhere around 2007, I dared to write my own framework. The projects I was working on at that time were very small. Submitting a simple form was the most advanced thing these sites should do.

After a few years our projects got a bit more advanced. I realised that writing and maintaining my own framework wasn’t going to cut it anymore. I heard about this fancy thing called Zend Framework 1 and starting using that.

Let’s skip ahead a few more years. In 2012 and 2013 I felt that the PHP ecosystem was pretty stale and I considered switching to Ruby and the Rails framework. But then I bumped into Laravel 4.0. I was immediately impressed by the expressive syntax and the big focus on developer happiness. I used it for a couple of projects and the more I learned about it, the more I loved using it.

At that time a guy called Jeffrey Way started his next project Laracasts: a video tutorial site dedicated to Laravel. Realising that his videos could speed up my learning process immensely I immediately bought a lifetime subscription.

On the 4th of March in 2014 Jeffrey published a video titled “Continuous Integration With Travis“. My mind was blown. Travis and the integration with GitHub looked so cool that I wanted to use it. A couple of months before he made the Travis video Jeffrey made a miniseries on package development. Those videos sparked the thought in my mind that I could create a package of my own.

In a project at the time we needed to automatically create screenshots of a website. With the things I learned in the Laracasts-videos I started working on my first package Browsershot. In essence it was just a simple wrapper around PhantomJS (the current version uses Headless Chrome and Puppeteer).

It was pretty exciting working in the open. I was thrilled every time the download counter got up and was incredibly happy that other people started writing about it.

More packages!

In the Zend Framework days I made used a custom-built application template, called Blender, to kickstart all client projects. It was a sort of mini-cms. Beside the traditional CMS-functions Blender could do a lot of cool things: pull in data from Analytics to show graphs about the usage of the site, handle uploaded files, subscribe users to a MailChimp list, …

To power new projects I needed a Laravel powered version of Blender and started creating it from scratch. I soon realised that some of the things I was porting to Laravel could be useful for other developers as well and decided to export these functionalities to external packages.

In quick succession packages like laravel-newsletter, laravel-medialibrary and laravel-analytics were made.

I started to enjoy package development more and more. The positive feedback that I got early on from package users was very encouraging. I always considered coding purely as work, but because it was so much fun creating code that others could use as well I started coding in my free time as well.

Besides working on packages I also polished the aformentioned application template called Blender and open sourced that too.

Currently every new package that we create gets born inside a client project. In almost every project we find some functionality that can be extracted to it’s own package.

The benefits of creating packages

There are many benefits of creating packages that makes time working on open source code well spent.

A lot can be learned while creating a package. Each package needs to be carefully crafted. It provides a clear and understandable syntax. Like Laravel, I want that all our packages put a great emphasis on developer hapiness. They should be easy to use. They should have great documentation. They should have clear tests. Thinking about how other people will use your code will make you a better developer.

The issues reported and the PRs submitted by the users of our packages provided another chance of learning. People can point to mistakes that are in our packages and can propose interesting new features that we didn’t think about.

Sometimes, as a package gains some traction, you get quality code for free. Our laravel-fractal package is a developer friendly wrapper around The League’s Fractal package. I coded up the basic functionality to I needed myself and tagged that 1.0.0. In the next weeks I almost daily got a pull request adding another great feature to the package. And now it supports almost everything League’s Fractal can do. I think 90% of the code of that package was written by the community.

Of course we’re also dogfooding ourselves. Our own packages get used on most projects. If we discover a bug in a package used in a project we can very quickly fix that and distribute that fix through the power of Composer to our other projects.

There are also commercial benefits. The past year we’ve landed some cool projects because of our open source work. In most cases these new clients were already using our stuff. Even though attracting clients isn’t the primary goal of our open source efforts, it sure is a nice side effect.

The positive feedback from package users also gave me enough confidence to start a blog and start speaking publicly. The past years I’ve spoken at several local users groups (and I’m co-organizing the one in my home town) and a lot of conferences world wide. The past few years I had the pleasure of giving talks in Washington, Amsterdam, Tokyo, New Delhi, New York, Istanbul and of course my hometown Antwerp. At all those occasions I got to meet a lot of awesome fellow developers, including Andreas, who runs this site. That all probably wouldn’t have happened if I stayed in my little bubble. Working on open source helped getting to connect to the community. That sounds a bit corny, but that doesn’t make it less true.

Making time to work on open source

People often ask if it isn’t very time-consuming to create packages. The truth is that it indeed takes a lot of time. Creating the code for the package itself, writing tests, writing documentation and getting the word out all takes a fair amount of time.

And that’s just the start. When a first stable release gets tagged the work is not over. Maintaining a package, responding to issues, reviewing PR’s takes a lot of time (and dedication) too. At the time of this writing we’ve responded to over 3 000 issues and reviewed more a lot of PRs.

We do long-term planning at Spatie, but we also have a weekly short-term planning meeting. When scheduling out to the coming week we only plan four days. So we have one work day we can be a bit flexible with. Do not imagine that day as like a fixed day, that time is mostly spread out in that week.

In that “fifth” day everybody in our company is allowed to work on open source stuff or their own projects (which, if possible, will be opensourced as well). For our employees this has a nice benifit that they can keep things interesting by switching between working on client projects and open sourcy stuff.

Personally I do enjoy working on packages in my free time as well. So a few times a week I spend some time in the evening to continue improving the released packages and create new stuff.

Meet the team

Because I blog, tweet and try to speak at conferences a lot I’ve become the public face of the company’s open source efforts. But you should know that I’m not doing it all by myself. I’ve got a great team behind me that does a lot of the work.

Since the start of Spatie I was the sole back-end developer at our company. That changed mid 2015 when Seb joined our team.He loves working on the more lower level PHP and JavaScript stuff. He’s the primary author of the regex, schema-org, phpunit-snapshot-assertions and many many more packages. And our dashboard and JavaScript code wouldn’t be as good if it weren’t for him. Be sure to bookmark his blog.

Last year we had a great intern, Alex, who has meanwhile joined our team. He’s helping out maintaining laravel-permission, which has gotten quite popular. He’s currenlty doing some kick-ass work on some non-released packages / projects that I can’t talk about yet.

A couple of months ago we hired Harish, our first remote employee. He’s helping out with issue across all our repos and laid the foundation of our dns package.

Brent, our latest hire, likes to focus on performance. His passion surely reflects on the opensource work he’s been doing. He created the laravel-binary-uuid package, he pushed me (in a friendly way) to add support for responsive images to our medialibrary. Currently he’s busy creating a very cool async package. He also has a cool blog.

And last but not least there’s Willem, who is the founder of Spatie. He’s responsible for the good looks of our dashboard, our dns lookup service, the various demo pages of our packages, the copy of our Patreon page and much much more.

I’m really happy that the every member of our team enjoys working on open source. Hopefully they all will keep working for Spatie in the foreseeable future. I do hope that if somebody would leave us for greener pastures, that they’ll bring the open source spirit to their new endeavours.

Top 10 of most popular packages

When taking amount of downloads into consideration these are our 10 most popular packages:

1. laravel-backup
2. laravel-fractal
3. db-dumper
4. laravel-permission
5. pdf-to-image
6. laravel-medialibrary
7. fractalistic
8. laravel-newsletter
9. laravel-glide
10. laravel-tail

Some of these packages, like db-dumper, probably get a big download boost because there are required by other packages.

Not so popular packages

There are some packages, that we ourselves use in every single project, that I expected to be more popular. I hope by mentioning them here they’ll get a little attention. If you decide to give the ones mentioned below a shot, I hope that you’ll enjoy using them as much as we do.

The first one in this category is laravel-uptime-monitor. This package can check the uptime of multiple sites. It will notify you when your site is down (and when it comes back up). You can also be notified a few days before an SSL certificate on one of your sites expires. Under the hood, the package leverages Laravel native notifications, so it’s easy to use Slack, Telegram or your preferred notification provider.

Secondly, there’s laravel-translatable. This one can make your Eloquent models hold translations. Unlike Dimitris Savvopoulos’ excellent translatable package, ours does not need separate translation tables to store translations. Our package stores the translations as json in a column of the table. It’s very easy to work with, there are no extra queries needed to fetch translations. We got the idea to store translations as json in a column from Mohamed Said (who now enjoys fame as Laravel employee #1 ?).

Even though you saw laravel-medialibrary int the top 10 above, I think this one deserves to be a few places higher. The package can associate all kind of media files (images, PDFs, …) with Eloquent models. It can generate thumbnails, and can store files on external filesystem and generate URLs to the files. It’s very easy to work with and it has excellent documentation. Our team is already hard at work in creating v7 which will add support for zipping assets on the fly, responsive images, client side components and much more.

How can you show appreciation for our efforts

Maybe I should have mentioned it before, but our packages are not entirely free. There’s a special license on them: Postcardware. If any of our stuff makes it into your production environment, we’d hight appreciate you sending us a postcard. This is our address:

Spatie bvba
Samberstraat 69D
2060 Antwerp
Belgium

Every week the postman delivers some postcards to us. For my team and I it’s nice to know that our stuff is being used all over the globe. We’ve gotten postcards from all continents. We even got one from Vanuatu which, for us, is litteraly on the other side of the globe. You can take a look at our postcard collection as well. They all are published on our website.

Another way you can show your appreciation is by becoming one of our patreons. Like mentioned on our Patreon page your donation will help us to dedicate even more time to maintain and create new open source code.

The future

We don’t have a fixed roadmap for new packages. It depends a bit on the client projects we’re handling. If there is something there that can be solved in a generic way, we’ll create a package.

There’s been a time when I though that, because we’d already solved a lot of common problems, the package output of our team was going to diminish a bit. But it’s quite the opposite. Almost every member of our team has some good package ideas.

One of the bigger things we’re working on now as a team is the aforementioned new upcoming version of the medialibrary. You can expect that one to drop somewhere Q1 2018.

In closing

Creating and working on open source packages continues to be a truly fun experience. On a technical level I’ve learned lots of things that I wouldn’t have learned when working solely on client projects. Like you’ve probably read between the lines, it also brings me great joy that my co-workers enjoy and appreciate the time given to work on our open source body of work.

I hope you’ve enjoyed the story behind our open source efforts. The big conclusion is that there are only winners in this story. If you are in a position in your company to advocate or to actively work on open source, I highly recommend you do so.

If you haven’t used our packages before, take a look at the list on our company website. Probably we’ve made some things that could be useful to you.

And last but not least I wish you happy holidays and a splendid 2018!