He’s sweet, but he’s just not good with other dogs

That used to be the description I gave to people when it came to our 3-year-old dog Baloo.

My wife and I both have a lot of experience with big dogs. I grew up with two Dobermann, and she owned a Rottweiler when we met. So while dogs are still animals and the teeth occasionally come out, neither of us feared those moments and knew how to handle them. But Baloo is different. Despite puppy training and additional guidance, at some point we realized that we could not predict his behavior with other dogs and trust was lost. He stays on the leash at all times when we’re outside.

When a dog is aggressive towards almost every other dog you meet, that has a greater impact on your day-to-day life than you realize. Like finding a kennel when you want to go on holiday, and not stressing out all the time if something bad has happened. Or asking someone else to walk him, when you want to go to a theme-park for an entire day. Or having our young kids bring friends over to play after school.

Or even something as simple as where, when and how you walk the dog. I started taking the less-used routes. I started to walk on less-popular hours. And most importantly, I started to avoid other dogs completely – crossing the street whenever I encountered one.

And I would say “he’s sweet, but he’s just not good with other dogs”…

When you feel your world and your options getting smaller and smaller, something is wrong. And both my wife and I experienced less joy from being dog owners than we would like to. So we decided to change what was happening. The simplest thing we changed, that had the most surprising effect on our daily lives, was the way we talked about the incidents.

So Baloo is now a dog still learning how to behave with other dogs, and whenever something happens, it’s a learning moment.

Where before we would say “he tried to attack another one today” or “he really can’t stand that beagle on the corner”, we would now say “I had another opportunity to correct him today”, or “I got really close to the beagle, and while his hair was standing up, he did not try to lunge this time”.

And the weirdest thing happened. In a few days time, I realized I was actively seeking out other dogs on the street. Not because everything was going so well, his behavior really didn’t change much in that short period of time (didn’t I mention this is not a success story? Sorry about that…). But because I wanted to have more “learning moments”. The dread of having to explain my dogs behavior made place for optimism in explaining he was still learning and that the incident was actually helping him get better.

We’ve noticed changes in others as well. The neighbor from across the street has a lovely dog that reacted to Baloo quite strongly, and got a strong reaction back. We’ve gotten to the point where they can both walk down the street without acknowledging each other, which is a great victory. But our change in attitude (and language) brought some confidence to our neighbor as well. He expected positive change because we allowed the option of improvement in our description of the situation.

You see “he’s just not good with other dogs” is a definitive statement. It places no responsibility on the issuer of the statement (me) and leaves no possibility of change. So just by changing the vocabulary used to describe a situation, we have changed our own experience of the same situation. I’ve always been a fan of ways to trick the mind. For example, you can improve your share of happy thoughts by sitting up straight.

Now I know this is just a story about some guy and his dog. But I think I’ve learned a few things that might come in handy at work:

Change the tone

Recognize definitive language (from you as well as others) and gently replace it with alternatives that leave options of success open. A client might come in with last-minute changes and the response could be “Wow, they never learn”. But perhaps “they repeated an earlier mistake” would be better. I don’t know about you, but my mind sees the second version as a fixable problem and tries to find solutions.

Celebrate small improvements

I also found that new descriptions left room to celebrate even the smallest improvement. “I had to correct Baloo, but he shook off the aggression faster than before” is not something I would have even mentioned (or noticed?) if it was just another incident. But now, those small improvements where noticed, shared between us and grew to become bigger victories. The same goes in a team. Don’t save the celebrations for the large accomplishments, but make small goals explicit and enjoy the moment that it happens. Especially in a large legacy big-ball-of-mud project those small victories start to add up to a general feeling of progress within a team.

You have the power!

Most importantly, I realized that your language is always within your own power to change. So even if you feel like there is nothing you can do, you can do something. Namely, describing the situation in a way that leaves the option for success open.

Because if the shape of your body can unconsciously influence the mind, the shape of your language might do the same, right?

To be perfectly honest, I have never had a professional PHP job.

Whilst most of my current personal projects are made with PHP and Laravel, I work as a Python developer in London mostly dealing with data ETL and analytical modelling. I love both languages, but I found myself doing completely different things with these two languages. With PHP, I do only web based applications; and with Python, I only deal with data. Come to think of it, except for playing with Flask, I have actually never made a proper web app with Python.

For the longest time, PHP and Laravel has been a hobby of mine. Especially when I was still in my last job, when I didn’t have nearly enough responsibility as I do now. All I was doing was writing scripts for web scraping and data extraction from external APIs, and the most I’d do was generating PDF reports.

At the time I was able to spend all my spare time focusing on my personal projects. At the same time, I felt really lonely, neither did I have anybody to talk about PHP with, nor did I know many people in the UK at all (I moved here from the US just a little over two years ago).

The Community

I had heard of PHP communities at one point, but I was hesitant to join, because I thought I had to at least be a professional to be a part of any communities. The hesitation didn’t stop me from trying, I was excited to have found PHPWomen slack channel, and I knew it would have been the perfect place for me to make some friends.

Not only did I make friends through PHPWomen, I was also invited to PHPSC on scholarship (Thank you so much @michellesanver !). That was the first ever conference I had been to, and it really gave me the chance to see how the PHP community is like: diverse, accepting, supportive and friendly.

Confidence had been one of my personal issues, I’d always be worried whether my skill level is good enough. Being around people at the conference had really made me feel comfortable and less insecure. Let’s be completely honest here, in the tech industry everyone is constantly learning and improving our skills. The concept of being good enough or not good enough probably doesn’t apply here. And this is what I have learned from the community.

What Happened After

Just a month after the conference, I got transferred to our company’s Data Labs department, where we process large amount of data from various different clients every single day. I got a lot more involved with developing in Python than I had ever been, and at the same time, I needed to constantly up my skill on not only Python, but all the other technologies I had not used before.

As I spend more and more of my free time learning and improving my skillsets relevant to my job, I got less and less involved with PHP. Because of that, I had distanced myself from the community as well.

Just when I was feeling a bit lonely again, I received a message on twitter from @heiglandreas asking if I could write a post for ’24 Days In December’. I was thrilled about this, but at the same time I was wondering if I deserved this honor. Especially when I haven’t been involved for months, and I haven’t contributed much back to the community.

“Would I be out of place?”

“Shouldn’t someone more involved be on the blog instead of me?”

All these thoughts came to me. After reading @grmpyprogrammer’s article, I felt much relieved that I’m not alone.

What The Future Holds

Although nobody knows what is going to happen in the future. I’m probably going to continue developing in Python professionally. Even though I might not have much time writing PHP code anymore, I will also continue involving myself in the PHP community, a place that I can call home. What’s most important is the friendship.

Merry Christmas everyone!

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.

Infrastructure

Before we go into deep, let’s take a look at the infrastructure that powers our favorite language and some of the technologies that is being used behind the scenes.

Technology

PHP is written in C. C89 to be more exact, while this is an old standard, PHP strives to be able to be compiled out of the box on virtually any operating system out there, even your PlayStation! This naturally means that all extensions are also written in C, however it is possible to write extensions in C++.

The PHP Documentation is written in Docbook XML, which is as the name says, an XML based documentation system. The PHP Project have developed its own Docbook rendering system named PhD (PHP Docbook Renderer), written entirely in PHP that can render Docbook XML based projects!

Servers

The entire PHP.net website (including mirrors and systems) are spread across about 100 servers, where almost 90% is mirrors hosting the documentation in 58 countries, so the manual is always available to a location near you, no matter where you are in the world!

Besides documentation mirrors, PHP.net also hosts both an SVN and Git repository (The Github repository is a mirror of PHP.net). Nowadays almost every project within the PHP umbrella are developed under Git, however the PHP Documentation and a few PECL extensions are still hosted under SVN.

Communication

All official communication is done by mailing lists, the PHP project hosts a ton of mailing lists (which is viewable online), this is where all discussions regarding features (RFCs) and other technical details are exchanged. This is naturally, where the notorious internals mailing list is hosted. Subscribing to a mailing list can be done by sending an empty email to <name>-subscribe@lists.php.net (e.g. internals-subscribe@lists.php.net) or by using the web interface for popular lists. The mailing list software used is ezmlm (which of course is the reason why PHP have the ezmlm_hash() function in the standard library).

There are also 2 common IRC channels, where you can find some members of the PHP Project, both of these are hosted on EFNet under the #php.doc and #php.pecl channels, whereas #php.pecl is primarily internals.

Other resources

Like any other large project, the PHP project also hosts a bug tracker where all bugs should be filed, as well as simple feature requests (more on that in the next paragraph). The bug tracker also hosts bugs for most extensions published at PECL, including the PHP.net website and other system related issues.

Lastly, there is also a wiki, this is where RFCs are described and voted upon. Larger change sets, such as new language features should have an accompanying RFC that explains the feature in great details, its typical that all RFCs have an implementation patch attached. Smaller features, for example “Add the latest cURL constants”, are small and self explanatory enough to be filed in the bug tracker.

PHP needs you!

Like any other large open source project, PHP is always in need of creative minds that are interested in making PHP even better. You don’t need to be able to do C or understand the massive Docbook XML DTD to join, all you need is a positive attitude and be able to read and write PHP (but you already know this!).

First I would suggest you to join the mailing lists, especially internals (medium volume) and phpdoc (if you are interested in the documentation) and take part of the discussions, or at least keep yourself familiar with the day to day discussions about PHP.

If you got 5 or 10 minutes to kill while on a form of public transportation, then helping to review pull requests (by testing, reading code and commenting) is a great way to begin the wonderous journey into contributing to the PHP project. The same goes for bugs, and there is even a nifty feature to find a random, open bug report if you feel adventurous: bugs.php.net/random.

If you got a little more time than that, then writing tests to help coverage is also an area that is very easy for new contributors who wish to contribute to the PHP project

The “Unthankful” job is more “Thankful” than you might think

The title above is of course very subjective, as we all have each our agendas, and goals here in life. However here is a small personal anecdote, on why I keep contributing, and why I feel contributing many thankless hours, becomes some of the most thankful in the end:

I myself would never in a thousand years, have thought that I would contributing to PHP (even less thinking about being a programmer in the first place). I got a book back in 2002 from my mom (I was only 13 at the time) about PHP. It was some of a read, but I got through it and I was able to enhance my already poor understanding of PHP into something more structural, and while reading about user input through $_POST ($HTTP_POST_VARS), the book was talking about register_globals, which would let PHP auto populate the global scope with variables from the $_POST array. I never really thought more about it back then, but 8 years after, I would think back to this moment, as I would be the one to remove this feature from PHP. However for me personally, this was where I began to really see the thankfulness of being a contributor, as it helped millions world wide create more productive applications even easier, and that sense of accomplishment is making all those unthankful hours spend culminated into moments like this.

Final words

Like I said above, this is very subjective topic as everyone look at how we are attributed different, but for me, looking at other passengers on the bus or the train (who are glued to their smartphones), and knowing that there is a good chance that one of them is using an app or webservice with a PHP backend, meaning that somewhere they are using code I helped write, is a very accomplished feeling of being a part of an amazing community like PHP.

I hope this blog post gave you some insight to the PHP project, and perhaps some interest to begin contributing to PHP. Perhaps 2018 is the year where we will welcome YOU to the development team!

For those who don’t know me, I spent three years with a team of fantastic individuals organising an annual PHP conference – PHP South Coast, in the sunny seaside city of Portsmouth, UK. This was a very rewarding experience for me, and paired with my unexpected career in speaking, I’ve been lucky enough to visit many conferences. It’s been very fulfilling, quite an adventure, and way out my comfort zone. Whilst I can’t speak for the rest of the team, I had several goals in mind when starting the conference.

Firstly, to provide a platform and opportunity for new speakers to be able to speak at a real conference. I spent a lot of time trying to start getting accepted to conferences. I followed all the advice out there as best I could. I visited user groups up and down the United Kingdom – even a trip to Manchester and back to Portsmouth where I used to live in one evening, which in good traffic is about a 4 hour drive. I saw it as an investment, and it’s paid off. Right now I’m sat in a hotel in Vancouver, ready to give three talks at ConFoo. I’ve visited countries I’ve never been to – South Africa, Bulgaria, Czech Republic, Italy, Romania, Ukraine and more. I’ve been lucky, but I’ve also put in a lot of effort to try and build my speaker profile. I wanted to give other budding speakers the same chance. For this goal, I’m proud to say we achieved it – around 40% of our speakers year on year were “new and upcoming” speakers, most of whom had never spoken at a conference. The lesson learnt? It is possible for new speakers to get accepted. The advice put out there works, but you need to work at it. Speak at user groups and get experience – don’t just submit to conferences having never spoken anywhere and expect to be accepted (although, it might happen!).

Another personal goal when organising PHP South Coast was to bring awesome speakers to the south at an affordable ticket price. There was already PHP North West and PHP UK conferences, and both these conferences really were inspirational for me; I like to think of it as a complimentary homage to the conferences. With the new speakers with exciting new proposals, and also some “big names” in the speaking circuit, I feel we were able to put on what I feel was an interesting selection of great, diverse content. We budgeted hard – really hard – to keep ticket prices as low as possible. The highest ticket price in the last year was just £130 – which is a fraction of many conferences with similar calibre of content. To make this possible, we had to skimp on many things. Each year there was only one or two speakers we could afford to pay for travel for. The catering was the most expensive part of the conference, and even then we pushed the catering company hard to bring the price down – in the end that cost us a smidge under £10,000 – just for the food. We didn’t print t-shirts, as much as we wanted to, but making t-shirts gets expensive. We discussed every year whether we should, but we agreed it was a cost we couldn’t afford without raising ticket prices to account for that. The lesson learnt here was that it is possible to keep ticket prices down, but there are some things that will suffer for it. It’s a trade-off, because money is not unlimited. And of course, our sponsors were amazing with helping out with around half the cost of the conference. Thank you sponsors!

The first year we made a big mistake with the social. Whilst we provided board games and laser quest games, which were superbly received and we had great feedback about, the bar offering was somewhat lacklustre. We actually did this intentionally. We wanted the social to focus on networking, and having folks enjoy themselves with board games and the fast-paced laser quest games, and we wanted to take away the emphasis on alcohol at the social. So we offered a bottle bar, but the pricing was set by the caterers, and it wasn’t exactly cheap. These combined factors unfortunately meant our plan backfired, and a lot of folk left the social early to go to nearby pubs for more reasonably priced drinks. We learnt our lesson from this, and so in the second and third editions of the conference, we put money behind the bar – a token system which I feel worked much better. The socials were busier, more sociable, and those who came were able to network at the tables, enjoy a board game or two, or exhaust themselves running around shooting laser guns at each other. We put an extra twist on the bar too. The conference was held in the Portsmouth Historic Dockyard, and so as a nod to the Royal Navy traditions, we gave away a tot of rum to those who wanted it; this is a tradition known as “splice the mainbrace”, so it fit in nicely with the theme of the conference.

Finally, another lesson learnt is that having a code of conduct is an absolute necessity for an event such as PHP South Coast, especially when serving alcohol. I am so thankful to say that we didn’t have any serious incidents that we were made aware of, and although there were a couple of minor complaints, they were dealt with appropriately. The couple of issues were things like inappropriate comments, but were sorted swiftly. I wanted to make everyone feel welcome and comfortable at PHP South Coast, so I made sure we had the code of conduct clearly in place, and although we used the standard PyCon template, we chose that because it details the procedure for handling incidents.

There are many other things I’ve learnt from running this conference. I’ve improved myself as well, and hopefully I’ve helped others improve. It was an incredible experience for me, and seeing all the great feedback made it all worthwhile. I admit, I was a little sad to end it, but maybe one day someone will take over the mantle, whether resurrecting the conference, or maybe something new, but I feel we did the community a great service for the short, but sweet, run of PHP South Coast conferences.

Life is like a box of chocolates. You never know what you’re gonna get.

When I was twenty, the Forrest Gump was just entering the cinema screens. I’ve really enjoyed it, but I didn’t know that it become one of most important sentences of my life.

Everyone is the architect of his fate, isn’t it?

It turned out that unfortunately not. Not always, at least. My humble life went different than I planned earlier and now I can say that it’s fairly well for me.

Nowadays, I often meet PHP people who exactly know what they want to do, who plan their career in details. I envy and pity to them at the same time. Why? Because on the one hand they used to have precisely defined business, skill improvement and impressive knowledge. It transfers to abnormally high salaries and this is the reason to proud, obviously. But, on the other hand, I know how easy is to professional burnout in early years. Every precise plan of career can collapse like a house of cards, in a moment.

Be ready to be carried away by the wave of destiny!

When I graduated my university, I had completely no idea what to do with myself. It was a time of quite unstable economy in Poland. My graduate work was the IT system for trade, written in Clipper (who does remember it?), but I didn’t want to involve trade for a long time, so further development of my system was out of question. Finally I decided to take a full-time job as IT specialist in heavy industry. Time has shown, that it was not too cool idea: it coincided with ownership transformations due to change of state structure in Poland and first two my employers bankrupted quickly. Next I took a job in a bank. It looked like a dream job, really! Of course it still had no luck, because crawling Polish capitalism hunted me down again: bank has been taken over a bigger one and my branch was closed after circa three years, just when I planned to get married.

In effect, I found my next job in IT division of the Polish Customs Service after my wedding, to the delight of my wife. Do you think I have ever planned to be customs officer? No, absolutely not! But I politely dressed up a new uniform and became IT specialist in one of Polish railway border crossings.

It was a time when I interested Free Software and became Polish Linux Users Group member. Note that the Linux group, not PHP! There was no PHP UG’s in Poland at all, at the time – we still talk about early 2000’s.

From sysop to event manager

I got learn more and more about Free Software. Such knowledge was much appreciated by my manager and helped me at once to learn more on WAN administration, which was also very desirable knowledge in customs due to large dispersion of branches. However, having a soul of creator, I still dreamed about going back to coding, because I always treated developers as Creators, as top level of IT know-how.

It became true, when I created new registration system for attendee’s of the Linux Autumn – annual GNU/Linux conference for PLUG members and FLOSS enthusiasts. It was 2007. At that time I was a lead organiser of that conference and acted both as business and development, so I did regular “sprints” inside my head and code creation was definitely easier

The system proved useful next year, 2008, when my friend from PLUG fired up the first edition of the PyCon PL conference and asked me for customizing my system for his needs. Imagine my proud, when I replaced HTTP headers to feel attendees that they register using Python software.

The time has flowed and I still asked myself: how come there’s brilliant Python conference in Poland, but not PHP? It’s impossible, we must do similar event for PHP community! In fact, there’s the reason that the first PHPCon Poland conference started in the spring of 2010 in Holy Cross Mountain in the Central Poland.

Python is a kind of religion. PHP is for masses.

It’s true. Both PyConPL and PHPCon Poland grew up year by year, but PHPCon fairly faster, from 90 heads in 2010 to 957 in 2016 and even 1120 in 2017, after merging with PHP Brno Conference and creating php Central Europe Conference.

I must claim that organising conference for three hundred people is hard, but easier than doing the same for five or six hundreds. Going further, doing it for eleven hundred people is completely new challenge and it’s the opportunity to feel the real scale effect. You must be often prepared to serve solution for trivial problem, which rised up to strategical one in a moment. Everything is ok if you know what to do and you’re prepared for such amount of people. Sometimes, when the six-hundred-sixty-seventh attendee brings a new problem, you still must be gently and patient. It’s not easy, in fact.

Today

I still work for customs! I don’t know how long time it’ll be, because my plans for events still evaluates.

My friend asked me years ago, if I plan to do conferences up to be retired. Then we laughed about it. Nowadays, I stopped laughing.

If you think I must be the PHP geek, as an organiser of such huge PHP event – the answer is: I’m definitely not. I’m going to specialise in the international event management, still beeing the IT engineer, as well.

If you want to support the PHP community in Central Europe, please google “phpCE” or “PHPCon Poland”, book a ticket and visit us. I’m looking forward to meet you in CE, in Poland, and maybe also somewhere else in Southern Europe in near future. But it is subject for another post, definitely

And now…

Merry Christmas!

I am not language agnostic! I think that PHP is the best for web development (and if it`s not web development I am not even the slightest interested….). My saying is “Anything is possible on the web”, and PHP supports that! Inspired by @coderabbi`s talk at PHP UK Conference about user groups, I started KristiansandPHP in 2015. My mission is to spread the knowledge and awareness of PHP in my area (Kristiansand south in Norway).

Why do I prefer PHP?

PHP is a fast (thank you PHP7-team!) and simple scripting language. You can have a small application in one PHP file, or you can have a large system with thousands of files. PHP is designed primarily for web development, it is not something that is added on top of a generic language. I don`t need to think of pointers, memory leaks, garbage collection and all that boring stuff, but I can consentrate on the user request and the respons that is expected

Online resources

Documentation is an important aspect of programming. To be honest I am quit dependent on online resources (blogs, forums, documentation etc), and I`m happy to say that when it comes online resources, PHP is the best! It is easy to find good code examples, and excellent explanations.

Don`t reinvent the wheel

There are many handy functions and features in PHP, for handling strings, arrays, json, xml, files, datatabases and so on. And most of us use a framework (i.e. Laravel or Symfony) that gives you even more out-of-the-box. And if you need even more, then Composer makes it really easy to include other components. There are components for logging, UUID, image manipulation, routing, events, backups and so on. And if you want async there is no need for a other language, because PHP has that too – actually we have several projects for handling asynchronous requests.

We got frameworks!

Just like most modern langugaes, we got frameworks: Zend, Symfony, Laravel, and a bunch of others. Laravel is for RAD (rappid application development), you can quikly spin up a prototype to have proof of concept, and then you can continue in the same framework and build the finnished product. If you have a large database in production, you might be better of with the Symfony framewok (I use both..). I have friends using Zend Framework for both small and large projects, and would never dream of using anything else. I used to think frameworks would quicly get me almost finished, but never match requirements 100%, but after using frameworks for several years,

Frameworks give you a lot out-of-the-box features, it gives your code struckture, and it helps you with the things like CSRF, XSS, SQLinjcetion, dependency injection, validation and so on, the things you don`t want to be bothered with…

I am never going back to writing everything my self, it`s a waist of time and money. What ever your preferances and needs are, there probably is a good framework out there for you!

The right tool is half the job

When your codebase is large and complicated, it can be hard to find bugs. luckely we have Xdebug, that Derick has maintained since 2002! I use it every day, it is my first tool when trying to figure out a bug, and the integration with IDE`s like PhpStorm is superb!

And don`t forget testing! There are many ways to do testing in PHP, i.e. PHPUnit for unit tests, Codeception for function tests, and Selenium for acceptance test, and then there is Behat for BDD. If you don`t run test, you better watch out for a grumpy guy…

PHP is maturing

PHP does not need to be amateur spagetti code that all of us have writen when we were young..
We have standards (PSR), namespaces, type hinting, callables, exceptions, password hashing, interfaces and so on. There are lots of pro features you can choose to use, there is nothing stoping us from making great enterprise solutions!

Say thank you, to contributors!

There are some amazing people out there, that gives talks. document and maintains projects, open source their code, and put up with haters and ungreatful demanding people. Fabien Potencier (Symfony), Taylor Otwell (Laravel), Sebastian Bergmann (PHPUnit), Derick Rethans (Xdebug), Jordi Boggiano (Composer and Monolog), Freek van der Herten (more then150 packages). No one mentioned, no one forgotten. Oops…

Please give something back to them: buy their books, online training, pick something from their Amazone wishlist, or become a patreon. Or at lease give them a “thank you” on twitter.

And thank you Rasmus, for creating PHP, I love it!

I love the PHP community and I love all the people who, each in their own way, help bring people together, help us to connect, to learn from each other, to get better. Whether it is Cal, Emir, Mark, Michelangelo, Michelle, Stefan, Theo or any of the countless other people out there. I love how we all come together to make PHP and the community around it better.

With so many good people out there, I have to admit, it scares me that some of the most used projects in the PHP sphere are largely maintained by one person.

When I say “PHPUnit“, you say Sebastian Bergmann, when I say “Xdebug“, you say Derick Rethans, when I say “PHP_CodeSniffer“, you say Greg Sherwood, PHPDocumentor, Mike van Riel, Composer, Jordi Boggiano etc.

Of course, they do have help, sometimes even co-maintainers, but when I look at the contributors pages of each of these projects, I truly do get scared.

These projects often have hundreds of contributors with maybe one or two commits and then the main maintainer with the bulk of the commits and the bulk of lines of code contributions. Often the distance between the main maintainer and the next co-maintainer or contributor is a factor 10 or even 100.

Of course, looking at the contributors page is arbitrary. At the end of the day, the quality of contributions is/should be more important than the quantity and the contributors page also doesn’t show who has been most active recently, but it still gives quite a good indication of how many, or rather, how few, people actively contribute to a project.

It is easy to speculate why these projects have few active contributors: they “just” work. But for these projects to “just work”, a lot of work has been done and still continues to be done. And is mostly done quietly by these awesome maintainers, without complaint and often without getting nearly enough credits or praise to keep them motivated.

These are semi-“invisible” projects. You set them up once & they do their job, helping you do your job, every single day.

Unless you have an error or the build is breaking, you don’t even notice they are there, other than in the peace of mind it gives you knowing that these tools are running the background.

Each of these projects is a de-facto industry standard. There are alternatives out there, but generally speaking, these projects have hardly any direct competition in their field as they are good, have earned a reputation, and – as mentioned before – “just work”.

And while it’s bad enough that it’s a relatively thankless job for the maintainers, what scares me is this: what will happen if one of them steps down ? Or changes job and won’t get much time from their new employer to continue working on the project ? Or just loses interest ? Or – while we don’t like to think about this -: what will happen if one of them would die ?

We sometimes talk about the “bus factor“, i.e. if a bus crashes with a certain group of people what would the impact be ? Can a project survive even after the bus crash ? Each of these projects has a bus factor of one. If one particular person would die or withdraw from the project, the project would effectively be dead.

Our dependency as an industry on a few key projects with only one primary maintainer is enormous. Can we honestly afford to allow this situation to continue ?

Of course, the old adage “when one door closes, a window opens” holds true. If one of these projects would “die”, other projects would rise up in their wake. And other projects do rise up now and again anyway, completely naturally, like how Composer effectively replaced PEAR. The difference between this happening naturally and happening suddenly and unexpectedly, is the havoc which we’ll see in the interim before the next project has gained enough momentum to be said to be the rightful successor.

We’ve all seen the drama that happened when left-pad, one of the NPM-hosted projects which was a dependency for thousands of projects, got withdrawn.

Essentially, if there is only one person with admin rights on the repository, there is only one person with the keys to the castle.

Yes, someone could fork the project, but the project “move” can not be registered in Packagist, dependent projects can not easily be informed about the new “official” fork and quite soon there will be a hundred unofficial forks, each slightly differently and nobody knows which one to use anymore.

Still, unless someone actively withdraws a project and/or disables the account under which the project repo is hosted, a project should still be around for a while. But it will slowly disintegrate. A new PHP version will come out and suddenly something doesn’t work anymore, a new PHP feature is not supported while it should be, etc.

And just imagine the sheer amount of effort which would be needed to re-code all unit tests to use an alternative to PHPUnit…. yes, take a moment to let that sink in.

We are talking centuries of dev-hours. CENTURIES.

No matter how awesome we may be as a community, we also have a responsibility.

A responsibility to our fellow developers as well as a responsibility to the projects we maintain. And being dependent on so many one-maintainer projects is irresponsible. So let’s show the world how awesome we are and give these maintainers the support they deserve.

We all use these projects, we all use PHP. All these projects – with the exception of Xdebug – are written in PHP.

My challenge to you for the new year is to have a look at the (dev-)dependencies you use in nearly all projects, have a look at their repositories, have a look at their open issues, open PRs and to ask yourself what you can do to mitigate the risks of using these one-maintainer projects.

It may not be “sexy” to contribute to these kind of projects. They are not the latest “hip” thing, nor the newest bleeding edge technology, but that shouldn’t matter.

By contributing to any of these projects – or any of the other typical dependencies I haven’t mentioned -, you end up making the whole of the PHP sphere better as every other project using these projects will also get the benefit of your work.

And risk mitigation can take many forms, whether it is:

• validating open issues (arbitrage)
• reviewing & testing open PRs
• writing, improving or translating documentation
• claiming an issue and creating a PR to fix it
• or donating to the project

And, please, consider the same if you are the sole or main maintainer of a package which could be classed as risky from this point of view. Consider what you can do to on-board more contributors.

Consider adding “good-first-bug” or “up-for-grabs” tags and using them actively to signal easy-pick issues for new contributors to get started. Make sure there is a useful Contributing.md file. Be welcoming to new contributors, even if their ideas do not (currently) fit your project and be willing to spend time on reviewing pull requests, even when it would be quicker to fix something yourself.

Now, I realize on-boarding new contributors onto a project is not a small thing. For some maintainers, it may take a while before they are mentally ready to share their baby with co-maintainers. For others, it will be more of a challenge on how to educate new co-maintainers on the philosophy behind the project and to stay true to it.

So let’s be patient and kind towards each other while we each figure out our new roles.

Of course, the projects I have mentioned here are just examples. There are plenty of other projects out there of which the same can be said. Be it certain Symfony components, Flysystem, Guzzle, Twig or Swiftmailer.

I challenge you to look at the contributor stability of your dependencies and think about what you can contribute to improve the long-term sustainability of these projects.

Let’s show them as much love as we show our beloved elephpants.

Let’s all, in our own way, try to show how great a community we are, by behaving like one and supporting the people and projects who need and deserve it.

I salute you and wish you all a happy & productive 2018.

Juliette

Links:

• PHPUnit :: contribute :: donate
• PHP_CodeSniffer :: contribute
• PHPDocumentor :: contribute :: donate
• Xdebug :: contribute :: donate
• Composer :: contribute :: buy private packagist to support financially

Don’t know where to start contributing ?

• Up for grabs
• 24 pull requests

With gracious thanks to Norbert de Langen, Andreas Heigl and Michelangelo van Dam for reviewing the article before publication.

On December 23rd, it will be two years since I wrote to a counsellor and said “I’m not happy.” Since then, I’ve seen Jo pretty much once a week for fifty minutes at a time.

I’m not going to lie. It’s not been easy. As someone who spent 33 years of his life not talking about myself – not really anyway – I almost resented it. I dodged some appointments, dreading it. I was combative with her; closed. I wanted her to drive the conversation and ask all the questions – I had to plan what I was going to say on the car drive over, panicking that I had nothing.

But the fact remained that on some level I knew I was hurting, that something was pretty wrong – that for some unknown or specious reason, I was unhappy, and had no way of identifying or fixing it on my own. I knew I’d be resistant to the experience, so I set up an obligation. I’d go and see her, because otherwise I’d disappoint her.

As time went by, this experience didn’t change – I’d be stand-offish, double-guessing every suggestion of hers, trying to out-silence her. No progress, no openness, nothing. Sure, I shared some big news pieces with her, frustrations etc. but it was all just something to get done and get over with.

Then, in November last year, something clicked. I stumbled on a topic that was so emotive that I realized I had to talk about it – but it was five minutes from the end of the session, and there was no time left. So I resolved to talk about it next time – and said as much in the session. Another obligation.

The next week I was totally different – trying desperately to hold back the tears as I relayed the story of a trauma I went through a year and a half earlier. That I talked about it a month after being made redundant from my job of the time was probably no coincidence – I was opening up emotionally, letting the deep, negative feelings out finally, revealing the seething mess I am underneath to someone I know nothing much more than the name of.

Since then, I’ve made a little progress – certainly in dealing with her, or relating to her, as Jo puts it. I go to sessions willingly, and I even walk through the door and up those stairs without a clue what to say. But there always is. And there’s so much more work to do – I feel like I’ve broken a lot of eggs, but I’m still a dozen or two off starting to make an omelette.

I’ve realised that for the longest time I’ve been lonely – even when surrounded by people, I can feel so very alone – and that my self-esteem has hit rock-bottom, and has actually been there for a long, long time. There has been an undercurrent of negative feeling about myself throughout my life, but a lack of introspection, an uncanny ability to compartmentalize and a huge focus on the happiness of others (at the expense of my own) has covered that up.

Ironically, that last point – selflessness – has led me to be selfish, to cover up my feelings with those I care for and love for fear of darkening their lives, and perhaps to cause them to reject me. My very inability to relate to them, to share myself and my vulnerability, has led to them distancing themselves from me, and ultimately contributing to the very rejection I was desperate to avoid.

The thing that I’m only coming to realize – and just starting out on accepting – is that it’s OK to feel bad. It’s OK to reveal your feelings to others. If I have something negative to share with someone and they react poorly – that’s their reaction to own. And telling others how I feel – to share my vulnerability – brings me closer to them; I get just a little closer to feeling accepted by them, warts and all.

And that’s where community comes in too. When I wrote about loneliness earlier this year, my fellow PHPers stepped up. They shared their own stories and fears, and I came to start to feel like perhaps I have another family. A group of people just like me, people with fears, self esteem issues and things weighing on their minds other than backwards compatibility issues and whether you should use static methods or not. I got offers of friendship, offers to go out, to visit other countries – and just a small part of me started opening up to the possibility that maybe, just maybe, I’m not alone.

So, this Christmas, whether you’re a Christian, Muslim, Jew, Hindu or Pastafarian, please take some time to check in with those you like to spend time with – go to your local user group, take your colleagues out for a meal, even make new friends – and maybe share a little bit about yourself.

You never know, you might just feel a tiny bit happier.

This year has been quite overwhelming for me. I got invited to speak at conferences all over the world, visited a few usergroups in Europe, finally managed to attended WeCamp and met amazing people in real life that I knew only via chats and emails or not at all before we met.

And throughout these encounters every now and then there was someone thanking me for something I did. And I usually try to play that down. In my eyes that “something” isn’t noteworthy for me. It isn’t something “big” or “important”. It’s not something that I created to become famous. Usually that “something” was created to scratch my own itch. And suddenly people thank me for me scratching my itch. That somehow doesn’t seem “right” for me.

Accepting a Thank You for something that everyone else could have done feels weird. But the thing is: I did it. Not someone else. And what I thought is just my itch seems to have been the itch of so many other people as well. But they didn’t step up and scratch it. Some might not even have known that it was their itch. But by having it scratched others realized that it was “scratchworthy”. And so I came to realize that it’s OK to accept a Thank You. It’s not only for doing whatever people thank me, it’s also for realizing that something should be done. It’s for going from “someone should” to “I will”. For making a general wish actually actionable.

And even though I wrote about me in these lines so far, the same applies to everyone out there: Most of the awesome things created out there where created because someone was solving an issue they had, and not because they wanted to become famous for something. Becoming famous sort of happens along the way. I remember a friend of mine telling me that he didn’t understand “Twitter-Fame”: People stepping up to him at conferences just to take a selfie with him. But that was exactly the thing. Those people valued him for what he did for them, even without realizing that he did something. And by now every time someone steps up to me for a selfie (which doesn’t happen that often) I’m grinning for myself and mumble “Thank you too”.

So accepting a Thank You is still not easy (and I think that’s good because it shows me it’s not the default) but I can accept it now. And it is a nice way of getting a bit of reward back for time and effort put into that scratching my own itch.

Which brings me to the other side of that Thank You.

As I just said: Most projects where born by solving a problem someone had. And from that point on it also suddenly solved the same problem for a lot of people. So if you haven’t done so already, why not say Thank You to those projects, people, companies that made it possible to help you with your work?

Think about which projects, people of companies have actually helped you with your days to day job? Sit down (or stand up) and thank them! You might ask: “How can I thank them?” Well, nothing is easier than that: Write them a mail or a tweet with a plain and simple “Thank you”. Or a more elaborate “Thank you for your hard work that makes my life as Developer easier”. Or have a look around the internet to see whether there is an Amazon Wishlist to get something from or a Patreon you can support or a consulting-gig you can use to support the project. Or hire one of the developers for a certain amount of time to allow them working full-time on their project.

Say Thank you to the people that created your framework of choice, your DBAL of choice, your programming-language of choice, your WebServer of choice, your TLS of choice. Thank the people that provide your serverless-environment, your billing-plattform or your tax-return. And even if you pay for those services, that’s a matter of allowing them to continue to run the service. But that Thank You also shows them that it’s been the right thing to do in the first place. And that it’s not only a business but also something their customers value.

And isn’t this the best time of the year to say Thank You?

So from me a big Thank You to all the usergroup-organizers, all the conference-organizers, all the Chat-Channel moderators, all the volunteers that help keeping and making my language of choice awesome, all the maintainers of all the awesome libraries and projects, all the companies that support OpenSourceSoftware, all the people doing their share to make this community awesome and to everyone I forgot!

And also – last but not least – a big Thank you to you for reading this! And perhaps Thank You for saying Thank you?