Posted on by Bernhard Breytenbach

Your first successful open source project

There is something thrilling, rewarding, and even scary about getting your first open source project out there for the world to see. But where do you start? How do you end up with a project that is useful to the community?

As South Africa celebrates the Day of Reconciliation, a day to promote unity throughout the South African community, across all languages, traditions, races, cultures and genders. A day that we focus on being one as a country, despite all our differences, I can’t help but see it as a perfect day to share some of my personal experiences about open source with you.

Getting involved in open source has been one of the most rewarding things I’ve done. Seeing other developers blog, tweet and recommend one of your projects is priceless. Lets dive in to a few tips I believe is required to make any open source project a success!

A Selfish Act

The first open source project that I consider a success was my Laravel Migrations Generator. We started rewriting one of our legacy applications in Laravel at my company. The database had more than 100 tables, and some tables had more than 50 fields. It would’ve taken forever to rewrite everything by hand, and would’ve been very error prone.

I decided to look around to see if there was something already. I found a few options, but none of them could replicate our legacy database with 100% accuracy. After trying them all, I decided to write my own.

I didn’t try to create an open source project, and at the time I didn’t even know I was going to open source it. I was just looking after my own best interest, trying to solve my own problems.

While I was searching for a tool that could generate these migrations, I came across a lot of people asking for one. So once I was happy with the results, I decided to create a Composer package and open source it. This is a scary step, and I must’ve gone through the code 100 times to make sure I didn’t do something stupid. But the important thing is I did it. I pushed the code to Github for all to see.

Choosing a licence

Unlicenced code is unusable code. Without a license you are the only person allowed to do anything with the project, which is probably not what you want.

If you want to allow others to use your code, you’ll have to decide on how you want to allow them to use it. Have a look at choosealicense.com if you’re not sure or head over to opensource.org/licenses for a list of open source licenses. I generally use the MIT or GNU GPL licence for all my projects, but make sure you understand the full implications of the licence before adding it to the project. — Thanks to Andreas for pointing out the importance of this section

Easy easy easy!

To get people to contribute to your project, they need to first use your project. The easier it is to use, the more likely it is that someone will use it, and the more likely they are to contribute later.

If you manage to build something that is a thousand times better than any existing solution, and has the most beautifully written code, but takes a day to understand and set up, chances are people will end up using the less effective solution, mainly because they got it working in under 10 minutes. So the first and most important thing is, make sure it’s easy to find, use, set up and understand.

Easy to find and install

I’d highly recommend that you put your code on GitHub. Bitbucket and GitLab are great tools, but not everyone is familiar with them.

Secondly, make sure you use a package/dependency manager for the tool you’re using. Examples might be Composer, NPM and the WordPress Plugin Directory. Just make sure it’s as natural for the user as possible to install your project.

Easy to set up

Think about when you want to use someone else’s project. You want a short description on what it does, and then some copy/paste installation instructions, and perhaps a more detailed explanation as to what it does below.

Add a README.md that gives a short description of the project, and then lists everything a user needs to do to get it installed and working.

Easy to use

How many times have you installed something, and 10 seconds in it gives an error. Depending on the project, you might just decide to uninstall it and try another one. Similarly, if you read the documentation, and you need to jump through hoops to get it working, you might decide to rather jump to another solution.

If they can easily get past this step, and it seems to be doing more or less what they expect it to, chances are, they’re hooked. They are now going to use it in their current project, and hopefully tell their friends about it!

Marketing

I’m sure many of you have found a hidden treasure before – a great project that simply no one knew about. It doesn’t matter how good your project is, or how great the code is; if no one knows about it, it doesn’t help anyone.

I’ve spoken to other developers about this, and some have said: “I’m not that kinda person, if people want to use it they can, and if they don’t, they don’t”. At first these people seem very humble. They’re not trying to sound cool by telling everyone they just wrote this awesome tool. But sometimes it really is an awesome tool, and people need to hear about it. Simply putting it on Github is not enough.

How you may ask? If it is solving a common problem, it may have already been raised on Stack Overflow, forums, IRC, Twitter, etc. Find those questions and start answering them by promoting your project.

“You want me to shamelessly boast about my project, by spamming it all over the internet?”

Spam is something people don’t want. If your solution works, and helps them solve a problem, then it’s definitely not spam! But yes, I want you to let the world know that you have built a successful project, and that you think it’s worth looking into.

I started Googling for “Generate migrations from existing database”, finding questions, and answering them with a link to my project, adding a disclaimer that I am the author. I did this once or twice, unsure if my project really was any good, in fear of criticism. After I received a positive response from the community I went back and probably answered a dozen similar questions, getting my project out there.

Two months later, I saw someone else recommend my migrations generator as a solution on IRC in #laravel. I later found a blog post written on installing and using it, with step by step instructions and screenshots. After a while people started raising issues, and submitting PR’s. This was a great time for me!

The code must be perfect

I think people generally put way too much emphasis on “good code”. I think a working solution is much better than no solution, and bad code is much better than one that’s difficult to use.

Sure, the easier it is to read and understand your code, the higher the likelihood that someone will contribute, however, as you can see, this is by far the least important step. There’s a much bigger chance that someone will contribute if it’s easy to use, than if the code is good, because no one contributes to projects they don’t use.

Working with issues and PR’s

Think back to when you created issues on other projects, or have been brave enough to submit a Pull Request. For you, it’s a big moment. Will the maintainer respond? Will they accept your PR. You end up refreshing the page every 5 minutes just to see if something changed. And it’s very important to keep this in mind when going through issues and PR’s.

If someone has created a PR, it means they have put effort into it. It could very well be their first PR ever. Think how you would want someone to respond to make you want to contribute again. You want someone to recognise your work, your effort, and you probably want to see it 10 minutes after you opened the PR.

Be kind. Always thank people for creating issues and submitting pull requests. They took time out of their day to help improve your project!

Always try to accept a pull request. If the code is not up to the minimum standard you’ll accept, help them to improve it. Mentor them, and lift them up. Do everything you can to get those commits merged in. It’s a great feeling for a developer to get their code merged into a public open source repo and, chances are, they will do it again.

If it’s implementing a feature you really can’t accept, explain it to them. Tell them you’re sorry for not accepting it, but you don’t see it as part of the project. Also, recommend opening a ticket suggesting the idea, before spending hours of work on it, and urge them to submit again. Perhaps propose an easy task they can help you with.

Conclusion

Open source, in some way, is a lot like running a business. For it to be successful, you need a product that the community would be interested in. You need to market the product, work with people, and make tough decisions about accepting or declining pull requests, all while trying to keep everyone happy. The main difference being that you’re doing it for the community, with the community, and everyone is hoping you succeed!

I hope this post inspires you to release one of your projects as open source, and please, do tell us about it 🙂

Posted on by Jack Skinner

A call to arms, a call to patch

Security is a topic dear to my heart. It’s core to enabling the privacy of many billions of web citizens. We, as web craftspeople, have a duty and responsibility to care for, prioritise and make decisions that benefit our customers, clients, friends and family online. However we so often fall short of the mark either by time, knowledge or the sheer energy it can take. Building secure software can be hard.

When we get security wrong – either by laziness or neglect – the implications can be huge. We’ve seen high profile and high impact breaches like Ashley Madison and it’s with mild irony that I share my thoughts on security on the same day that yahoo shares 1 billion+ user accounts were breached. While each breach and vulnerability might be unique in its own right, it shows us what can happen when things go badly. The recent DDoS against Dyn also demonstrated the sheer scale that the insecure-internet of things has and its ability to be harnessed as a security threat against us. You might not consider PHP to be a popular language for embedded hardware & IoT, but the commonality is the lack of attention to security.

We, as craftspeople of 82.4% of the internet have a crucial role in fixing the security mindset of our community.

As a language, we are getting better. We’ve removed features that perpetuated set-and-forget mindsets, chosen smart and secure defaults, and even removed the ability for ourselves to make insecure decisions.

As a community however, we’re significantly falling short of the mark. In my recent state of the version post I show that – at a best-guess – a maximum of 40% of PHP installs in the wild can be considered probably-secure, leaving over 60% insecure.

A majority 60% of insecure installs merely perpetuates the levels of contempt culture towards PHP as a language and our community at large.

However, my friends and phpellow coders, security is everyone’s responsibility, not just a mailing list on internals.

Bad advice is everywhere, and it’s not helping us. And yet there are also some fantastic resources at our disposal too!

So here’s my call to arms: let’s make 2017 the year of the responsible, security-minded developer.

Posted on by Adam Culp

You’d Better Be Good, For Goodness Sake!

The U.S., and many other places in the world, celebrate the Christmas season during the month of December in a HUGE way. Whether you believe in the religious implication or not is irrelevant to the celebrations happening. It is a time of gift giving, sharing memories, getting families together, and being cheerful. But unfortunately these awesome things can lead to stress, and often what is being shared is not very good.

In a holiday song “Santa Claus is coming to town”, the song contains a list of things you should do as a child in order to receive presents from Old Saint Nick. The 3rd and 5th verse both contain the words: “He knows if you’ve been good or bad, so you’d better be good for goodness sake.”

“He knows if you’ve been good or bad, so you’d better be good for goodness sake.”

With this in mind, let’s take a peek at one way we can be good…for the sake of being good. Despite obvious challenges we experience in a modern society. Because being good is a good thing to do, after all.

Why are we bad?

In tech circles people tend to spend more time with tech related “things” and communication is typically remote. (Twitter, Skype, IRC, Facebook, Github, etc.) Therefore it’s too easy to mentally associate somebody with a piece of code, technology, library, or framework. Thus creating an imprint that doesn’t contain a face, personality, or a living and breathing human being with “feels”. In short, we dehumanize humans through association.

No, you are not a bad person for doing this, it is…human.

There is a saying that “Developers are lazy”, but in reality it’s actually their brain. A more proper response would be, “Brains are lazy.” Our brains constantly create shortcuts in how it associates things. By “Association” our brains automatically create internal links in an attempt to make future recognition and recollection easier. The process of how our brains create these shortcuts is nothing new. In fact these have been observed, and written about, since the days of Aristotle and Plato.

Hurting Feelings and Bullying

As a result of how our brains create these shortcuts, it often leads to poor communication leaving much to be desired. I know I’ve been guilty of responding to a question very brash, or I’ve questioned somebody’s methods in a very rough manner. Though I did not intend to be offensive, the communication tone and words I used were not “nice”. In fact my words were very harsh and could even be interpreted as bullying. While the gains achieved by expedience may seem acceptable in the short-term, eventually reality does catch up.

Again, not very good. No presents for me.

Seriously though, people lose jobs, friends, communities, and families over poor communication with others. People get into fights over it, and many other more severe things can happen because of it. This is quite serious.

Get Control

The realization of what I’ve shared above has led me on a journey over the past decade. That’s right. It is a never ending battle, and I struggle with it daily. You should too.

We humans are an intelligent species, and as such we have the mental capacity to change our bad ways. (Unless you are truly bad, then you may get coal as a present from Santa Claus this year.) Please pay close attention to how you are communicating with others. Pause prior to hitting “send” and read what you wrote. Ask yourself, “Is this constructive? Will it halt forward progress, or will it allow those reading it to think of better ideas?”

“…read what you wrote. Ask yourself, “Is this constructive?…”

By doing this I often rewrite much of my emails, and in the process calmed myself down from ranting to being productive. No, I’m not perfect. Sometimes I still make mistakes. But many of my communications are of a higher quality than in the past.

Conclusion

Please take this to heart, and don’t let the hectic holiday season block you from being good. Happy Holidays!

Posted on by Chris Shiflett

A Few of My Favorite Things

For many of us, December is a natural time to reflect on the year, and 2016 has provided plenty to ponder. While there are arguably more important things I should be writing about, I’d rather provide a brief respite from the serious issues facing the world.

In that spirit, here are a few of my favorite things.

1. Copy as cURL

Regardless of how complex a web app is, it’s still just HTTP requests and responses underneath it all. I used to use telnet to debug stuff, but for things like SSL or edge cases that require a particular cookie to trigger, I find curl to be much more useful, particularly with the “Copy as cURL” option in Firefox and Chrome.

It’s easy to miss, because you have to right-click a particular request in the inspector to find it. Here’s how this looks in Firefox and Chrome.

The nice thing about this is that it’s the exact request your browser sent, and it helps you test one change at a time to pinpoint a problem. It can also help you make a bug reproducible, which might be important if you discovered it, but someone else needs to fix it.

2. WonderVPN

The PHP community’s own Paul Reinheimer is one of the people behind WonderNetwork, a global network with servers in 216 locations, covering 78 countries across 6 continents.

I’ve used several of their products, and while all are useful, WonderVPN is my favorite. You don’t have access to the entire network, but you do get a few choices of locations, including the US, UK, and Canada.

3. Blogs

I still believe in RSS! In fact, I still read my own personal aggregator, Planet Chris, almost every day. In 2017, I hope to finally get back on the horse and start blogging regularly again. To those of you who never stopped, thank you.

4. Video Calls

I collaborate with a lot of people remotely, including colleagues, friends, clients, and business partners. For calls, nothing beats video. Here are the ones I use most:

Google Hangouts
As long as you’re signed into a Google account, you can start a hangout whenever you want. Share the link with anyone you want to join. You can also add someone via phone, which is nice.
Zoom
If you have a lot of participants, or you just want to be kinder to your processor and battery, Zoom is a great option.
Join.me
Join.me admittedly strays into the enterprise realm, but for good reason. There are dial-in numbers for almost every country, and the app is pretty good for those of us who prefer computers.

5. Using the Clipboard from the Command Line

I had never used pbcopy or pbpaste until I read about them on Sean’s blog, and he takes things one step further by showing you how to use them on remote servers.

Even locally, using the clipboard from the command line is incredibly useful. As the names imply, pbcopy copies to your clipboard, and pbpaste pastes from your clipboard.

6. AWS

With some hand holding from Sean, I’m now hosting my blog on AWS. Their UI is not the best, but the product is great.

Until I made the switch, I thought of AWS as something to consider for large-scale needs, not a simple blog. Now, I expect I’ll never run my own server again (or beg my way onto a friend’s), much like I’d never consider hosting my own email. Let someone else do it; you’ll find plenty of other things to fill your time with.

Google Cloud Platform looks like an interesting alternative, too.

7. Google Docs and Google Sheets

I’ve done everything from collaborate on an email to manage a company’s finances with Google Docs and Google Sheets. I even organize my my backpacking gear in Google Sheets. Being able to easily collaborate and share is a big plus.

8. Amazon Echo

I’ve had the Echo since the pilot in early 2015, and I only bought it because it was cheap. I didn’t expect to be impressed, but I was.

It sits on my kitchen counter, and although we only use it for simple things, we use it every day. Having someone (Alexa is a real person, right?) always available to tell you the time or the weather, set a timer, play music, or turn the lights on is really handy. The voice recognition is better than you’d expect if you’re only familiar with Siri.

9. Mailinator

Ever need to let a site send you an email, but dread the long-term relationship (and spam) you’re signing up for by giving away your email address? That’s exactly where Mailinator thrives. It’s free, public email that lets you check any inbox. Just use something like 24days@mailinator.com as your email address, then check it anytime.

10. Recordit

Recordit is a nifty little tool that lets you record a quick screencast and share it as an animated GIF. It’s a really convenient way to demonstrate something to someone, whether it’s how to reproduce a bug or how to navigate a poorly-designed UI.

I’ve got dozens of other things I could write about, but I decided to stop at 10. Got any personal favorites I missed? Let me know, or just use the #24favs hashtag to share.

Happy Holidays!

Posted on by Alain Schlesser

The Year I Got Hooked

The year 2016 has been revelatory for me. It is the year that I finally became hooked to the Community aspect of the tools I work with on a daily basis. To explain why this needed to be explicitly “revealed” to me, I’ll take a step back and tell you about my background.

Changing Careers

I have been working for some time as a government agent before, working on IT integrations amongst others. After several years of working on fruitless tasks and turning in elected circles, I was so fed up that I decided to quit that job and start freelancing. As there’s no such thing as a “general-purpose government freelancer”, I opted to do web development instead.

I primarily chose the platform to specialize on based on sheer market volume, to make sure I had a sizable target audience: WordPress. This meant that I spent the first year mostly working in isolation on smaller client projects to get to grips with WordPress and PHP development (and web development in general, as I had almost exclusively worked on desktop applications up until then). As I have been doing development with varying degrees of intensity for about 25 years now and working on many different platforms and languages, I was able to make rapid progress, and after that initial year, I started to put myself out there to position myself as an advanced developer (in the WordPress space).

Dabbling In Social Interactions

It started with Slack teams, where I made sure that I was the one answering all the more difficult questions. If I didn’t know the answer right away, I looked it up (as I should have known it from the start). I also enjoyed the “watercooler talk”, as working from home can be very isolating. I couldn’t talk about my daily challenges with my wife Carole, so it felt good to have people I was able to speak to regarding these topics. In the beginning, I was not aware how important that aspect was, though.

After some time of doing this, people started to notice the value I was offering, and they often also wanted to meet at Meetups or WordCamps. Now comes the part where I was missing a piece of the puzzle…

In my mind, Meetups and WordCamps were mainly targeted at end users and provided a laid-back weekend activity for people that are deeply involved in one single platform/language/project. I was after business value and a return on investment of my time, so I wasn’t interested in meeting with other people to discuss WordPress drama. When I was looking at the session plan of a WordCamp or other conference, I always thought: “That topic has already been covered in a blog post two years ago. Why bother?”. I am a very practical and goal-oriented person, and these events didn’t seem to help me achieve any of my immediate goals. Add to this that I’m more of an introvert, although I can hide it most of the time.

Vienna

Fast-forward to the summer of 2016. Slack as a networking tool had worked wonders for me, and I had been discussing and working on a daily basis with people I had still looked up to one year before. WordCamp Europe was held in Vienna, and it just so happened that a lot of these people were assembling in the same city for a week, because of the WordCamp. I had never met these people in person, so I decided to head there as well. And given that Vienna is a beautiful city, my wife was coming along.

WordCamp Europe was a delightful experience for us both. It had about 2200 attendees, which meant that there was always a dinner or party to go to after sessions, or a fun activity to do on your extra days. It allowed me to get a real feel for the people I was constantly communicating with online. This adds another layer to the communications and prevents a lot of the misunderstandings you constantly face when only communicating in written form. What’s better to defuse a potentially ambiguous statement in Slack or email than to imagine the smiling face of the author while reading?

Carole does not work professionally with computers at all; she merely uses them for basic surfing and communication needs. She was worried that we “nerds” would just talk “nerdish” all day long and exclude her in the discussions. What happened though was quite the contrary. These were people I had come to associate with based on shared interests and values, not on geographical proximity. Apart from this making them generally more diverse and open-minded, it also meant that they were mirroring some of the traits she was valuing in me. She was highly inspired by all the discussions she’d had and felt withdrawal symptoms when we got back home. She also did much better on the following up than I did…

Being Part Of The Community

After this experience, we started to more systematically attend WordCamps. We also made sure that we applied as volunteers whenever it was possible. We felt the need to give back to this great group of people and truly enjoyed doing so.

carole-olinger-alain-schlesser-wordcamp-frankfurt-2016-2
Carole and me with our three dogs at WordCamp Frankfurt 2016.

 

At one point, Carole also took part in a “Contributor Day”, an optional extra day on WordCamps where everyone gathers to help work on WordPress itself. Several teams are formed, and Carole got to participate in both the Polyglots team as well as the Community team, as these don’t require technical knowledge. At the end of the day, she had localized one free theme into German (which was committed the same day) and joined the discussions for organizing a new type of WordCamp, which she now seems to be an integral part of.

After attending some WordCamps as a “developer + developer’s boss” team, I noticed that our discussions were changing. She knew the people I was talking about, she understood the projects and concepts I was referring to, and she was not bored out of her mind when I talked about my current development issues.

Impact Of The Community

A lot of people will tell you that a Community is a big family by choice, where you’ll meet great people, have lots of fun and reap networking benefits as a perk on top of that. This is all true. But to me, the Community has had an additional impact I didn’t expect. The Community has actually allowed Carole to take part in the life I’m leading during the day, where she was locked out of before that. She still does not code or understand WordPress specifics. But she can finally relate to what I’m talking about.

I now intend to get to know the PHP community better as well. I guess this will be a bit more challenging, as I will need to bridge the gap between these two communities that seem to grow further and further apart (because of technical reasons).

But this time around, I know that it’s worth the effort, so I won’t be easily discouraged.

Let’s meet in 2017!

Posted on by Gary Hockin

Be Brave – Put Yourself Out There

I’m fortunate enough to be releasing this on Day 11 of this grand event and having read some of the other posts that have come before, I’m worried. I’m a worrier anyway, and not just because I suffer from an anxiety disorder; I’m lucky enough to have inherited this worrisome trait from my own father (thanks, Dad!) who suffers from a similarly over-active worry gland. In this case, I’m worried that my measly attempt to educate and entertain will go down badly after such a parade of big names in the community hit it out of the park in the 10 days before me.

I’ve come to a conclusion (as I approach my fortieth birthday) that it’s entirely natural and expected to be concerned when you release any kind of content out into the wild. Be it writings, podcasts, videos, conference talks, or worst of all, code. As a stoic and obvious Welshman, I wince every time I hear my own voice on a podcast or video, and I’m sure others (even the non-Welsh) will empathise with that. The first time that I heard myself speak on a podcast, I was pretty close to asking Cal Evans (the podcast host) to pull it down.

“For the love of Phil Sturgeon! I sound like a complete fool, and as soon as people hear this they are going to be all over Twitter mocking my terrible accent!”.

This was a genuine fear I had. Like most people, I forget that I speak with a pronounced accent and thought my voice sounded awful when I heard my voice on tape, but it turns out nobody else cares. I’ve had a few people comment on my accent in videos I’ve released for my heroic employer JetBrains, but it’s mainly been along the lines of “I like your accent” rather than “Why do you sound like your speaking with a whole custard slice in your mouth”. Since that first podcast I’ve done much more, and my career has definitely benefitted from it.

Stepping on stage to give my first talk was another huge fear to be overcome. Public speaking is probably the ultimate way of putting yourself out there; when I speak I leave so much of my actual personality on that stage that I have nothing left to hide. I’m lucky in that even though I have terrible nerves in the hours before stepping on stage, those get shaken off almost immediately once I step up to the podium and start speaking. I fully understand that other’s aren’t as lucky as this (and believe that public speaking isn’t for everyone, but that’s probably another post for another day). But if you can get over to your local user group and deliver a talk, it may well open the door to another hugely rewarding set of experiences that you can only access if you put yourself out there that first time. I know that I wouldn’t be doing this job I love if I hadn’t been brave and got on stage that first time.

Code is a whole different beast. Putting your code out into the wild for other people to read, use, and ultimately critique is putting an entirely different aspect of your professional life out there. Submitting code to open source projects is daunting because you’re opening up your most important professional skill to be judged, and that is very, very scary. But there’s a truly amazing upside to putting your code in a public arena to be commented upon, and that is that people will help you improve for free. You get a complete perspective shift once you stop looking at code reviews as a chance for people to criticise you, and start looking at them as free opportunities to learn. I wouldn’t be half the developer I am if I hadn’t contributed to the Zend Framework open source project and had excellent and completely free teaching from some of the communities most talented programmers.

I recently recorded myself solving the superb Advent of Code problems to try and explain not just my how I solve a problem, but why I make certain decisions when programming. I’m fascinated by the decision-making process that individuals use when coding, but once again was apprehensive to publish such intimate details of how I solve a problem, expecting me to be told I’m doing it all wrong. It turns out this stuff is really helpful to others, and most of the feedback was along the lines of “great video, you could change those three lines to this single line though”. This is amazing as I not only helped some people but learned something too!

I would go so far as to say that every time I’ve put myself out there, the good results have outweighed the bad. I can directly trace a path from my first ever open source pull request to me being sat here writing a blog post for a fantastic series. Sure, I’m worried this won’t go down well, but I think I’ve come to a conclusion; it’s human nature and happens to (nearly) everyone. Having spoken to other speakers, even those people who come across as being confident and well-rehearsed will tell you they were petrified minutes before taking to the stage. So be brave, and put yourself out there. After all, what’s the worst that can happen?

Posted on by Maximilian Berghoff

Community Driven Development

When talking about development I mostly mean personal and educational development. So this post is not about a new fancy way of writing software.

Why Community

I personally felt the power of a community on my way to the position I’m currently at. I started working with zero practical experience at small company in Germany. It was a good way to get into the business, but very soon I realized, that there is an other world out there. So I started experimenting with Symfony. At the same time I heard a conference talk by Lukas about the Symfony CMF. As content management was my daily business, I tried to dig into that Content Management Framework. I admit, I couldn’t understand how it worked. My first attempts on implementing it had been a disaster. But then I started committing to that ecosystem. It had not been my first contribution, but it was the first that ever got merged into something bigger. But that is not the point. While working on my own CMF component and committing to the main packages, I had an impressive learning experience.

When Working on such an project I learned a lot of the internal processes of Symfony. I really had helpful but demanding guys on every review. And indeed I would like to thank David and Wouter. With their help I made my biggest step in my personal development. Instead of declining a pull request, I got a lot of helping words. Those words contained more and better advice than a documentation can ever give.

So I became a core developer of the CMF. Currently I prepare a new major release with the same guys. We are planning to serve before Christmas. And again I learn. I currently don’t work on a Symfony application in my job. But with the work for the community I stay in touch.

Not your Story?

I believe, that not every open source project can bring on the same success, but most of the community driven projects do. Almost every bigger project has got chats, user groups or meetups and sometimes their own conferences. That can be an easy starting point. When using those projects in daily business, you should visit the community one way or the other. You will gain insights you will never get by simply reading documentation. Those visits combined with public speaking is the first contribution to such a project. There is no code or documentation involved yet, but it gives every internal contributor some self confidence. Realizing that one or more people use the code you wrote or contributed to is a really good feeling. Trust me. I stand in front of more than 500 Symfony developers and asked who knows or got in touch with the CMF. And almost the complete crowd raised their hand. I can’t really describe what that did to me. I is absolutely amazing.

Why not starting to commit?

Most often it starts with a bug or missing feature when using an open source project. Instead of ranting you should fork, fix and push. Maybe you realize why that bug had happened or the feature hasn’t been implemented yet. It is easy to yell for a specific behavior of an application or library, but the implementation of it can be more difficult than expected. Libraries used by lots of developers need a special kind of extensibility. Contributing to those libraries is the best way to understanding those concepts. And doing so, it also helps to get aware of the work, that is needed to get a feature on the road.. That said I have to add, that the code isn’t the only possible contribution.

The Documentation often needs some effort. So how often did you say “This isn’t documented well”? Fork, fix and push! Same answer here.

It is open source. It is implemented by a community of moms, dads and other people, who sacrifice their free time. There is no service hotline you can call and shout “I paid a lot of money for that, so it has to work the way I want.”. In my opinion there has to be a kind of compensation. The more you take, the more you should give.

Commit while your job

Yes! You should discuss in you company about a way of contributing to open source projects. It is not only about reinvesting. It is mostly about bringing company’s developers forward. As I described some lines above, I learned so much contributing to open source projects. Employees can too. Instead of spending a lot of money on workshops, get in touch with the community, contribute and learn. It is much cheaper. And what can be better marketing for a company selling experts in Project X, than having contributors to the same project on your team?

Conclusion

There are several ways of learning programming language specific skills, but contributing to and working on open source projects, you will also meet kind people and get a lot more information than just reading documentation.

Posted on by Daniel Shaw

The community of open source

When I think back to the things that have helped me in my career, one of the biggest has to be the community.

The chats during local usergroup meetings, the conference hallway track, the Slack groups. All are great ways to get to know other people in the community, learn something new, and even teach somebody else something they didn’t know.

But another way to grow as a developer is by contributing to open source. It may be unpaid work, but being part of the community can provide many benefits.

It lets you tackle something new

Often, trying out some new tech isn’t commercially viable for a day job. It can be hard to justify the cost and the time when a company needs to make money.

In 2017, I plan to get more experience in automated testing. As a member of the joind.in community, I am able to contribute to the automated tests on a real project, and a real website, with real peers. I’ll be working with other people’s code, and I will probably also learn from the other contributors.

You’re giving back

We all make use of open source software as part of our day job, so to be able to give back in some small part helps you grow. You’re not only contributing to the world we all work in, but you’re also contributing to the community. A community that you’ve made that little bit better.

You’re making friends

Among the pull requests, bug tickets, and reviewing of code, you soon start to get to know about your fellow contributors. If there’s a project Slack channel, you might find yourself talking about non-project things.

If you contribute to WordPress or Drupal, you might attend a Wordcamp or Drupalcon — or a local WordPress or Drupal usergroup. You might find yourself eating lunch with someone you’ve been talking to over Slack.

If you ask me, this is the most fruitful of benefits to contributing to open source. I don’t always find time to contribute code to open source projects: often it can be months between my pull requests. But I’m always around, in the community, in the background.

And that’s because I made some friends. Friends who have taught me, and friends who I’ve taught. Friends who I’ve shared both a feature ticket and a laugh with.

My year of open source

A few months ago, I set up a local group where once a month, people can come along and spend some time talking, drinking tea, and contributing to open source. I call it Patch:Manchester.

Next year, in 2017, I want to continue learning and growing, and I will be using open source to do that. I’ll also be using Patch:Manchester to do that.

Why don’t you do the same?

Posted on by Phil Sturgeon

Treat Yourself to a “New” Language This Christmas

Every few months, PHP gets a major bashing from developers who prefer other languages. These jeers are often from those who treat PHP like the runt of the litter; mainly because they’ve not used it in a decade and think it’s still PHP 5.2. Alternatively, they often make fun of it because they switched to some other language and noticed it has some cool stuff.

All of those jeers – as unproductive and annoying as they are – have an element of truth to them. PHP does have plenty of faults, and other languages do have plenty of awesome things. Those other languages have plenty of faults too, and are also often missing a lot of things, but folks who use the same language most of the time grow used to its faults, and don’t notice what they’re missing.

In general, only knowing one programming language blows. It’s certainly ok and absolutely recommended to start out just learning the one, as you don’t want overload yourself learning everything at once. When you’ve got a foothold with one programming language, you should try to start picking up other languages, even if you are only dabbling with them.

I spent a decade only writing PHP before branching out into using Rails, and later ended up doing a few projects in Python and Go. When I was starting out, learning other languages seemed really hard, and in the early 2000s it was all thick books, and trial & error. Now there are educational videos and quizzes, from sites like CodeAcadamy, Treehouse, Teachable, Pluralsight, etc., which make this easier than ever before.

Learning multiple languages widens your career opportunities, makes it easier to work in a service-orientated architecture where things might not all be PHP, and helps you make sure you’re using the right tool for the job, instead of just hammering every nail with the double-claw.

One great benefit of learning multiple languages, is that you get to see how things work in other communities. Most of the time it’s not even the language itself, but the ecosystem. Sure Go has a more consistent standard library, and Ruby has a pile of lovely syntactic sugar, but what really gets my attention is the tooling other languages have.

After a fair chunk of Rails experience, I helped bring back some of the features I liked into FuelPHP and CodeIgniter. Since then those two projects have fallen by the wayside, but all of the Rails-based features that went into FuelPHP seemed to find their way into Laravel, meaning PHP had benefited greatly from Rails. Taylor Otwell himself having a strong background in ASP.NET meant some of his ideas for Laravel were fresh and different to the norm in PHP, which again, benefited PHP.

Since I started playing with Rails back in 2010, a lot of other things I liked from that framework found there way into PHP in some form. I took ideas from OmniAuth and made NinjAuth, but sadly that was FuelPHP-only and is no more. I took some ideas from their oauth 1 and 2 clients, and brought them over, but again they were FuelPHP only.

The framework specific thing got a bit annoying, so some friends and I started up The League of Extraordinary Packages, a place where these packages ideas could come, with no ties to any frameworks. A place where folks could bring new and interesting ideas, get some traction, share the responsibilities of maintenance with others, and never get stuck in a situation where they were begrudgingly looking after code they no longer used.

Other tools have been ported to PHP by other awesome developers:

The PHP community is made stronger by those who use more than just PHP. Folks who take the time to learn multiple languages can share the fruits of their knowledge with everyone, and build some really interesting stuff.

Not only that, but having experience with other languages can really help get you through those awkward “oh you’re a PHP developer?” snarky runnings. We’ve all been there; You mention at a non-PHP conference the tool you use, and folks judge you harshly and immediately. Well, one side benefit of knowing more languages, is that folks generally assume you’re smarter if you know more than “just PHP”.

The amount of times I’d say “PHP” and they’d start being patronizing, then I’d say “Oh I use the best tool for the job, and in many scenarios that’s been PHP. I often write distributed software, and PHP has the largest potential install-base. Of course I’ve plenty of experience with Go, Python, Node and Rails too.” They’ll usually change their tone substantially, but if they keep it up, follow with: “Do you mind if I ask, what’s your issue with PHP? Have you used PHP 7 at all or were you back on PHP 5 something?” Watch as they shrink back when they realize you’re not a fool.

Learning from the progress of other communities is always helpful, for yourself, and for the communities you consider yourself part of. Even if you don’t think of any awesome packages that PHP is needing, learning other languages will generally improve how you write PHP anyway.

So, go learn a another language, and make PHP better while you’re at it.

Posted on by Amanda Folson

On “Finding Time”

I hated school as a kid, but learning was always a big part of my life. It wasn’t uncommon to see me with my nose in a book soaking up whatever esoteric thing I could find that day. (Seriously, I read a book on the pasteurization process in middle school. I’ve never lived on a farm but I can tell you a lot about milk.)

As an adult, I’ve found that my time gets split amongst various things like work, hobbies, and random adulting tasks such as fighting with Comcast. The result of this is that I don’t have enough time to read books and learn new things like I used to. Or at least, that’s the excuse I make for not doing the things I desire to do.

You see, I do have enough time. The issue is not that time is finite, the issue is that I prioritize other things over these goals. It’s not that I don’t want to learn new things or that the things I spend my time on are a waste of time, it’s just that I spend a lot of time on things that don’t move the needle towards my goals.

An example of this is that I “don’t have enough time” to keep my apartment spotless. It’s a goal of mine that I regularly fail at achieving. I travel a lot for work and I’m only home for 3-4 days at a time. As I’m unpacking from the last trip and re-packing for my next one, I tornado through my apartment and leave a path of unorganized destruction in my wake. As I write this, there’s an unopened box from Amazon in my living room that contains a paper shredder I ordered 6 months ago. I just “haven’t had time” to open it and start shredding papers.

Lies. All lies. I could have tackled the stack of papers 6 months ago, but I chose to go out with friends instead. I could have shredded those papers 3 months ago, but I chose to wrap up some last minute work projects. I could have shredded those papers last weekend, but I chose to fold laundry and organize my closet. That weekend I chose to binge watch Orange is the New Black again? I definitely could have taken care of those papers while that was playing in the background. None of these choices are wrong, and I’d argue that it’s important to find time to unwind and relax, but none of these choices resulted in my apartment becoming less cluttered. Organizing my closet actually made a larger mess. As I decided to do these other things, I didn’t even realize I was prioritizing them or making a choice — it just happened on its own as if I were on autopilot. The stack of papers never entered my mind as something to do instead of these other things.

How we spend our time is a choice that we make every day, but we often don’t realize we have a say in the matter. Every time something “comes up” we’re making a decision to tackle whatever it is that came up. There’s nothing wrong with these choices — you spend your time how you want to, and that’s your business. However, you should become aware of these choices and evaluate whether these choices are the best for you and your goals.

Once we start to focus on the things we spend our time on rather than the things themselves, we can start to manage our time a bit better. Suddenly, we “find time” to accomplish the things we want to accomplish. We can stop feeling like we’re spinning our wheels on all of these projects and ideas and start moving the needle in the right direction. We can start to feel like we’re getting something done.

Just as we budget our money every month (we do do that, right?), we should focus on budgeting our time. Allocate time to the things that REALLY matter (which includes leisure activities, by the way) and stop allocating time to things that don’t matter as much. For 2017, my challenge to you is to start recognizing how you spend your time and start spending time on the things that are important to you. Whether that’s family, learning new things, writing a book, or watching the entirety of the Netflix catalogue, you can always find time for your goals.