How to get involved with PHP and support open source software
I noticed a post from an past college Scott MacVicar about getting involved with and helping out PHP. Personally I've always thought about it and wanted to, though have always focused on hard core C, thinking :
"Helping PHP, means writing hardcore C, and building libraries"
The more I thought about that statement, and the way I typically think about software, Open Source and communities, I realized what nonsense that is. There is so much more going on in a project and community, therefor there are many more ways to help.
Developing a technology & community is a holistic activity. Some of us are writers, framework developers, application developers, business decision makers, power users, clients making requirements, community members, and so on. Though a lot of us, are more than one role, it takes us all and there is always room for more.
Though you could use these points for any OSS project, I'm just focused on PHP. Here are 10 I've thought of, in some kind of progressive intensity.
0. Talking about PHP
Quite the opposite of fight club here. By talking about PHP I mean when you are in a development environment, where decisions are being made. Or a business environment where people are nervous of open source (yes places like that still exist......). A common rebuttal I hear is "It's just a scripting language, is it really up to the job" ........ this by people who are on Facebook/Digg/various forums at the same time!
Combat the fear and ignorance with some numbers.
1. Actually using PHP
There are a few aspects of acceptance, talking about something doesn't mean it's accepted. When something is used and considered de facto, it's accepted. I believe it's akin to evolving development methods in teams (which is something I focus on).
Just because I advise a team about a development technique, doesn't mean it is accepted, and the standard. When they are used daily and accepted, it is.
There are various was of using and supporting PHP, not only writing raw PHP code at work. You can also use a project (growing its install base), where the project itself is written in PHP. Giving lots of cash to SAP or Salesforce.com ....... has SugarCRM been evaluated?
3. Writing about PHP
I suppose to a degree what I'm doing here. Make some noise, let people know what is going on, get more people on board. There are always things to do, as well as people joining and leaving their roles in the community.
You could be writing some kind of howto for the technical people, or and introduction targeted at new developers.
If you're a business type maybe a paper, or review of how using PHP in your business helped things - positive engagement with OSS. Enterprise might move slowly, though when it does, it turns up with big cheque books and looks for people who know what they are talking about.
More importantly people who've done it before and can demonstrate that success.
Maybe you've seen a blog post that you disagree with, or that you want to add too. I did that a little while ago with another Top 10 list of PHP developer improvements just because I wanted to by my own 2 cents.
4. In Person Community
As I mentioned above great things get done in teams, and communication is key to this. We are usually surrounded by like minded people and just think we aren't because we've never met them ! A bit of a truism if there ever was one.
MeetUp.com is a perfect example of how to get involved with a local community, or show and tell. http://www.phpusergroups.org has links to specific groups (a few broken ones in there, though you can Google around that !).
Not only are you going to potentially make new friends, which is rarely a bad thing, you'll get to share your ideas, see others ideas, get to ask questions, feel good when you answer some and even network for jobs and contracts.
5. Presenting about PHP
Personally this terrifies me. When I trained as a counselor I found out that public speaking is the number 1 fear, 2nd is flying.
Though it gets better with practice and is a lot easier when you're talking about something you're involved with and passionate about.
Just about all people want to hear what you have to say or they wouldn't be there, and even if they don't they'll be tweeting away on their laptops.
Presenting doesn't have to be to hundreds of people at a big conference either, starting at that point would be brave and more than a little scary. Though once you've talked to 2 or more people at work or say a MeetUp, you are presenting, you're most of the way there. The rest is just scale and organisation.
Find your passion and go for it, Rasmus Lerdorf is still at it.
8. Test Cases
Believing something works and being correct most of the time is nice, though it's a cowboy way of doing things and best left to the fly by night hackers. It's not engineering. If you want to be sure of something you should be able to prove it, and prove it continuously. Confidence is key.
My personal favorite on PHP projects themselves is : http://phpundercontrol.org for continuous integration. There is no real excuse for not doing it on any sizable PHP project, or in any main stream language really.
Personally I use ZendStudio and it's built in, even wizard driven. Though all this is to test applications, which is great, being happy with Test Driven Development and knowing it's value is great for quality.
Though there are test cases for PHP itself, same idea, just one layer down in the stack. Is the language doing what it says on the tin ? Over at PHP QA, they have a great How to Help page explaining it all, and what to do.
Being asked in an interview "Do you use or understand TDD" and being able to say yes, is one thing, saying that you help or are are of the team that does it for the language itself ! .... well that is mighty kung fu indeed.
And to think I didn't like mathematical proofs in university .......
9. Developing the PHP source
The point of this blog post was more to do with the activities you can engage in without actually programming for the source.
Though who knows, one day!
Getting happy working with the source, compiling it and writing your own extensions would likely be a good start, here is a book for that : Extending and Embedding PHP
. Though in all practical terms finding and reproducing bugs is a good way of helping and finding out how things work : http://bugs.php.net
And if you've gotten this far you don't need my suggestions any more.
First rule of PHP club
Well all know the first rule of PHP club..... is talk about PHP club.
Talk is good, though action is better. PHP has helped give lots of us great jobs, careers and opportunities. What are you going to do to give back and help PHP?
@JeremyHutchings
"Helping PHP, means writing hardcore C, and building libraries"
The more I thought about that statement, and the way I typically think about software, Open Source and communities, I realized what nonsense that is. There is so much more going on in a project and community, therefor there are many more ways to help.
Developing a technology & community is a holistic activity. Some of us are writers, framework developers, application developers, business decision makers, power users, clients making requirements, community members, and so on. Though a lot of us, are more than one role, it takes us all and there is always room for more.
Though you could use these points for any OSS project, I'm just focused on PHP. Here are 10 I've thought of, in some kind of progressive intensity.
- 0. Talking about PHP
- 1. Actually using PHP
- 2. Online Community
- 3. Writing about PHP
- 4. In Person Community
- 5. Presenting about PHP
- 6. Helping Open Source Projects
- 7. Documentation for PHP
- 8. Test Cases
- 9. Developing the PHP source
0. Talking about PHP
Quite the opposite of fight club here. By talking about PHP I mean when you are in a development environment, where decisions are being made. Or a business environment where people are nervous of open source (yes places like that still exist......). A common rebuttal I hear is "It's just a scripting language, is it really up to the job" ........ this by people who are on Facebook/Digg/various forums at the same time!
Combat the fear and ignorance with some numbers.
- The trend of PHP usage
- Use stats on builtwith.com (I like the Frameworks Distribution graph, take that RoR !)
- By version on http://w3techs.com (So happy to see the vast majority on 5.x)
Talked the talk, also walk the walk.
Knowing PHP is one thing, but by actually using it you're creating more software and systems in it. So there is more of it in the world, making it more ubiquitous. When things become more prevalent, they typically become more accepted.
Knowing PHP is one thing, but by actually using it you're creating more software and systems in it. So there is more of it in the world, making it more ubiquitous. When things become more prevalent, they typically become more accepted.
There are a few aspects of acceptance, talking about something doesn't mean it's accepted. When something is used and considered de facto, it's accepted. I believe it's akin to evolving development methods in teams (which is something I focus on).
Just because I advise a team about a development technique, doesn't mean it is accepted, and the standard. When they are used daily and accepted, it is.
There are various was of using and supporting PHP, not only writing raw PHP code at work. You can also use a project (growing its install base), where the project itself is written in PHP. Giving lots of cash to SAP or Salesforce.com ....... has SugarCRM been evaluated?
2. Online Community
The whole point of the internet is information sharing and connection. The resources and communities out there are vast. A quick Google of "PHP development forum" will give you pages to go though.
And that is just for the language itself, there are lots of communities that are focused on the development of something specific (which you might be more interested in) that just happen to use PHP.
So you approach it from both sides, language first or interest first.
Most of the greatest works are done in teams, not by super star individuals (some are, though it's rare). We all have our areas of specialty, and more important our areas of interest. For instance there is little I don't know about migrating data between forums and CMSs and still get emails and IMs about various issues. Being able to share the information, pass it on, get feedback and make it better is a core philosophy of what we do.
And that is just for the language itself, there are lots of communities that are focused on the development of something specific (which you might be more interested in) that just happen to use PHP.
So you approach it from both sides, language first or interest first.
Most of the greatest works are done in teams, not by super star individuals (some are, though it's rare). We all have our areas of specialty, and more important our areas of interest. For instance there is little I don't know about migrating data between forums and CMSs and still get emails and IMs about various issues. Being able to share the information, pass it on, get feedback and make it better is a core philosophy of what we do.
by Eric S. Raymond for community and OSS.
I suppose to a degree what I'm doing here. Make some noise, let people know what is going on, get more people on board. There are always things to do, as well as people joining and leaving their roles in the community.
You could be writing some kind of howto for the technical people, or and introduction targeted at new developers.
If you're a business type maybe a paper, or review of how using PHP in your business helped things - positive engagement with OSS. Enterprise might move slowly, though when it does, it turns up with big cheque books and looks for people who know what they are talking about.
More importantly people who've done it before and can demonstrate that success.
Maybe you've seen a blog post that you disagree with, or that you want to add too. I did that a little while ago with another Top 10 list of PHP developer improvements just because I wanted to by my own 2 cents.
As I mentioned above great things get done in teams, and communication is key to this. We are usually surrounded by like minded people and just think we aren't because we've never met them ! A bit of a truism if there ever was one.
MeetUp.com is a perfect example of how to get involved with a local community, or show and tell. http://www.phpusergroups.org has links to specific groups (a few broken ones in there, though you can Google around that !).
Not only are you going to potentially make new friends, which is rarely a bad thing, you'll get to share your ideas, see others ideas, get to ask questions, feel good when you answer some and even network for jobs and contracts.
Personally this terrifies me. When I trained as a counselor I found out that public speaking is the number 1 fear, 2nd is flying.
Though it gets better with practice and is a lot easier when you're talking about something you're involved with and passionate about.
Just about all people want to hear what you have to say or they wouldn't be there, and even if they don't they'll be tweeting away on their laptops.
Presenting doesn't have to be to hundreds of people at a big conference either, starting at that point would be brave and more than a little scary. Though once you've talked to 2 or more people at work or say a MeetUp, you are presenting, you're most of the way there. The rest is just scale and organisation.
Find your passion and go for it, Rasmus Lerdorf is still at it.
6. Helping Open Source Projects
Just about all of the ten points here you could apply to any OSS project.
The spirit of the movement is the reason we have PHP in the first place Its because of people (starting with Rasmus Lerdorf in 1995) putting in the effort to solve a problem and then sharing it for everyone.
If there is a OSS project you use, there is very likely instructions on how to help or where to engage. Or even better maybe there is an app or tool that you've developed and use yourself because you couldn't find anything else. In all likelihood you're not alone, so why not share it?
GitHub is an ideal place for this, I've recently had a few ideas myself and have put them there for a current project. I just need some more hours in the day now .......
The spirit of the movement is the reason we have PHP in the first place Its because of people (starting with Rasmus Lerdorf in 1995) putting in the effort to solve a problem and then sharing it for everyone.
If there is a OSS project you use, there is very likely instructions on how to help or where to engage. Or even better maybe there is an app or tool that you've developed and use yourself because you couldn't find anything else. In all likelihood you're not alone, so why not share it?
GitHub is an ideal place for this, I've recently had a few ideas myself and have put them there for a current project. I just need some more hours in the day now .......
7. Documentation for PHP
I think the documentation of a project is likely one of (if not the) main criteria for success, aside from the technology doing what is supposed to of course! Documentation in coding standards is one of the things I always encourage and support (read enforce!) when I'm leading a project.
Also it's a very valuable skill for employers who know the value of quality technology. Delivery of system, fully documented is a great thing.
It's the first port of call for new people, and then for everyone as they learn, look up errors, check arguments, etc. One of the main reasons I think closed book syntax test for developers are completely pointless, it's not how we work.
The comments and feed back are another excellent example of a way to help. Many times I've seen an example or how to in a comment that's saved me hours.
Rather than just reword Scott for how to help out with documentation, I'll just quote him :
Also it's a very valuable skill for employers who know the value of quality technology. Delivery of system, fully documented is a great thing.
It's the first port of call for new people, and then for everyone as they learn, look up errors, check arguments, etc. One of the main reasons I think closed book syntax test for developers are completely pointless, it's not how we work.
The comments and feed back are another excellent example of a way to help. Many times I've seen an example or how to in a comment that's saved me hours.
Rather than just reword Scott for how to help out with documentation, I'll just quote him :
"To get involved with documentation, the only thing you need to know is that the format used is DocBook. While it can be somewhat complex to understand, it does a good job of abstracting the actual documentation from the output format so the same source can produce the PDF, HTML and the Windows compiled formats. There is a live editor you can use anonymously to generate patches. There is also a wiki page that explains more."
Believing something works and being correct most of the time is nice, though it's a cowboy way of doing things and best left to the fly by night hackers. It's not engineering. If you want to be sure of something you should be able to prove it, and prove it continuously. Confidence is key.
My personal favorite on PHP projects themselves is : http://phpundercontrol.org for continuous integration. There is no real excuse for not doing it on any sizable PHP project, or in any main stream language really.
Personally I use ZendStudio and it's built in, even wizard driven. Though all this is to test applications, which is great, being happy with Test Driven Development and knowing it's value is great for quality.
Though there are test cases for PHP itself, same idea, just one layer down in the stack. Is the language doing what it says on the tin ? Over at PHP QA, they have a great How to Help page explaining it all, and what to do.
Being asked in an interview "Do you use or understand TDD" and being able to say yes, is one thing, saying that you help or are are of the team that does it for the language itself ! .... well that is mighty kung fu indeed.
And to think I didn't like mathematical proofs in university .......
The point of this blog post was more to do with the activities you can engage in without actually programming for the source.
Though who knows, one day!
Getting happy working with the source, compiling it and writing your own extensions would likely be a good start, here is a book for that : Extending and Embedding PHP
. Though in all practical terms finding and reproducing bugs is a good way of helping and finding out how things work : http://bugs.php.netAnd if you've gotten this far you don't need my suggestions any more.
First rule of PHP clubWell all know the first rule of PHP club..... is talk about PHP club.
Talk is good, though action is better. PHP has helped give lots of us great jobs, careers and opportunities. What are you going to do to give back and help PHP?
@JeremyHutchings
Correct. The bulk of what developers do pretty much boils down to how the online community will react to it. Web developers and designers make pages for people.
ReplyDelete