I get asked all the time from people on what they need to do to become a Linux developer. Reading this article was a good rehash of what I explain to a fair amount of people. Sure there are certain technical skills and communication skills that companies look for just like they have all along. But, there is the one main thing that separates Linux/Open Source based positions from one that you see from traditional proprietary companies.
Purely stated, it is the opportunity to get involved and create a name for yourself. No longer do you have to look for acceptance by a certain institution to realize your development aspirations. Instead, you have the ability to participate no matter who you are or where you are. It is all open, so participate to the best of your ability and create a name for yourself. The more you get involved, the greater the value of your personal brand per se. You are creating your own product and that is yourself. As you fine tune it and create a brand worth significant value, corporations will be clamoring for your services. It is that plain and simple.
Anyhow, if you are an aspiring Linux developer, please take a moment and read the two part series of that article. And, if you have any further questions, please do not hesitate to contact HotLinuxJobs. Our goal is always to provide as much information and assistance as we can to people looking to get involved in open source based development.
Monday, July 30, 2007
Friday, July 27, 2007
Is the LKML's tone preventing up and coming kernel developers from particitpating
I was recently reading the interview with Con Kolivas, a former active kernel developer with a wide following. He recently decided to hang up his shoes as far as Linux kernel development goes. It appears that he was just fed up with the focus of where the kernel was going. From his vantage point, he did not feel there was enough emphasis on the desktop issues within the kernel.
Whether right or wrong on his take of the kernel development's direction, what I found interesting was his comments regarding the LKML. He appears to be not too fond (that is an understatement) of the attitude/professionalism/interaction of other kernel developers that take part in the development process. In one part of his interview with APC Magazine , he goes so far as to mention, "The Linux kernel mailing list is the way to communicate with the kernel developers. To put it mildly, the Linux kernel mailing list (lkml) is about as scary a communication forum as they come. Most people are absolutely terrified of mailing the list lest they get flamed for their inexperience, an inappropriate bug report, being stupid or whatever. And for the most part they're absolutely right. There is no friendly way to communicate normal users' issues that are kernel related. Yes of course the kernel developers are fun loving, happy-go-lucky friendly people. Just look at any interview with Linus and see how he views himself."
Now, we have known for years about the sometimes harshness of developers on the LKML. But, I had started to hear that times were changing, and people were more open with their responses. Of course, there will always be your flame wars, that is not going to go away, nor should it. However, my big concern is if people's interest in getting involved is diminished by certain behavior that takes place on LKML. With the lack of talent that exists to go along with the demand of corporations for solid Linux kernel programming skills, there must be an open door for developers.
Now, they have also set up other lists, such as kernel mentors and others that have been a great asset, in my opinion, to getting people to participate. The real question is who Con is speaking of. Is he speaking of developers that do not have enough experience to participate at that level, or are there experienced people that just do not want to participate for the fear of personal ridicule. If that latter is the case, it does not help the Linux and Open Source community from moving forward.
Whether right or wrong on his take of the kernel development's direction, what I found interesting was his comments regarding the LKML. He appears to be not too fond (that is an understatement) of the attitude/professionalism/interaction of other kernel developers that take part in the development process. In one part of his interview with APC Magazine , he goes so far as to mention, "The Linux kernel mailing list is the way to communicate with the kernel developers. To put it mildly, the Linux kernel mailing list (lkml) is about as scary a communication forum as they come. Most people are absolutely terrified of mailing the list lest they get flamed for their inexperience, an inappropriate bug report, being stupid or whatever. And for the most part they're absolutely right. There is no friendly way to communicate normal users' issues that are kernel related. Yes of course the kernel developers are fun loving, happy-go-lucky friendly people. Just look at any interview with Linus and see how he views himself."
Now, we have known for years about the sometimes harshness of developers on the LKML. But, I had started to hear that times were changing, and people were more open with their responses. Of course, there will always be your flame wars, that is not going to go away, nor should it. However, my big concern is if people's interest in getting involved is diminished by certain behavior that takes place on LKML. With the lack of talent that exists to go along with the demand of corporations for solid Linux kernel programming skills, there must be an open door for developers.
Now, they have also set up other lists, such as kernel mentors and others that have been a great asset, in my opinion, to getting people to participate. The real question is who Con is speaking of. Is he speaking of developers that do not have enough experience to participate at that level, or are there experienced people that just do not want to participate for the fear of personal ridicule. If that latter is the case, it does not help the Linux and Open Source community from moving forward.
Wednesday, July 25, 2007
Open Source Developers in demand
A new article out by TechWorld mentions a list of much needed skill sets for IT professionals. Amazingly, Linux and Open Source made the list! (of course a bit of sarcasm there). The only thing I wonder is about a comment made by Sean Ebner of Spherion Pacific Enterprises that said, "Some people thought the sun was setting on open source, but it's coming back in a big way, both at the operating system level and in application development". I do not know, but I have been involved in open source recruiting for over 7 years, and I do not think I ever witnessed a time when the "sun might be setting" per se. The only time we have ever witnessed a slow down is when the whole market was slow after the major market correction after 9/11. Anyhow, if you want to find out the hot areas of the IT job market from the folks involved with this article, you can read it there. I am just glad that they were able to squeeze open source within the top 10.
Wednesday, July 18, 2007
Looking for good Open Source Developers
Just a quick mention that we are aggressively looking for talented developers in a number of areas.
They are as follows:
- Linux kernel engineers - locations on the west coast and east coast, but we would be happy to speak with any kernel engineers with authorization to work in the U.S.
- PHP developers - locations on the east and west coast (heavy needs in southern California at the moment)
- Ruby on Rails developers - primarily in the Bay area in California
- Toolchain developers - in the Seattle area at the moment
- Embedded Linux engineers - heavy needs in the Bay area in California
These are just a few of our needs at the moment. You can find out more details about these openings here .
They are as follows:
- Linux kernel engineers - locations on the west coast and east coast, but we would be happy to speak with any kernel engineers with authorization to work in the U.S.
- PHP developers - locations on the east and west coast (heavy needs in southern California at the moment)
- Ruby on Rails developers - primarily in the Bay area in California
- Toolchain developers - in the Seattle area at the moment
- Embedded Linux engineers - heavy needs in the Bay area in California
These are just a few of our needs at the moment. You can find out more details about these openings here .
Thursday, July 12, 2007
Interesting article on Compensation for Open Source Developers
Earlier this week, I read an article in Datamation about what the Open Source Researcher at SAP Labs thinks Open Source developers will be paid moving forward. Overall, he has some insightful ideas.
He goes on to state that "Committers" (a.k.a maintainers and other leaders of an open source project) will be compensated to a higher standard than other members of that project. That of course makes sense from a structural point, and we have seen this to be accurate in the marketplace. After making this point, he mentions that he believes the other open source developers (general project contributors) will actually see a dip in pay. I have to disagree with this point. I am not sure anyone is going to see a dip in pay, especially in this marketplace. And, I would hope that these contributors, through hard work and perseverance, will become the next maintainers. As a result they will see an uptick in their pay as this transition takes place. At the end of the day, the open source structure has similarities to other corporate structures in that certain individuals will experience growth and increased responsibilities which will result in higher pay, while there will be others that are not as motivated and become somewhat stagnant in their pay scale. This happens in basically every known entity that I have ever recruited for. Nothing new here.
One of the parts that I truly enjoy about this article is the mention of open source developers being "free agents". I think he is right on the money with this assessment. This is something that I have thought about for a few years, and I think it will take shape, if it has not started to do so already. In fact it has to some extent, with a lot of the open source maintainers being employed by some of the leading open source technology companies. However, I do not think we have seen the compensation piece take full effect yet. Me being a huge sports fan, I put it in that context. I see it no different than baseball players, football players, etc. If you are a good offensive tackle for the Chicago Bears, you more than likely will be a good offensive tackle for the Green Bay Packers. Sure, there is a new playbook, but you know the position well, and you should be able to adapt fairly easily. When these players make that move as a free agent, they reap the monetary effects of such a move. Same will be the case for open source developers. If you are the maintainer of a particular open source project at one company, and there are going to be other companies utilizing that project that are interested in your services, you should be able to continue your work without too many interruptions at your next place of employment. Sure, it is a different company with a different culture, but that is just like a different playbook for a different organization. At the end of the day, you are going to be doing the same work, for the most part, because that is what you were hired to do. They are going to provide you increased compensation because not only do you write solid code, but you are also an influential member of that community project.
My prediction, due to this scenario, is that the open source developer's future compensation levels is very bright. There is no question that the top developer's are going to see the biggest gains, but there will be gains throughout the ranks. We continue to experience a shortage of open source talent in the marketplace and this will just reinforce this notion. The beauty of open source, as has been mentioned countless times, is that you control your destiny no matter who you are or where you come from. You do not have to be a MS in EE from Stanford to excel in the open source world. Throw out the resume, it boils down to who's code is the most solid.
Overall, this is a very good read with other good examples and points that I did not have time to mention here. Take a peak at it when you get the chance.
He goes on to state that "Committers" (a.k.a maintainers and other leaders of an open source project) will be compensated to a higher standard than other members of that project. That of course makes sense from a structural point, and we have seen this to be accurate in the marketplace. After making this point, he mentions that he believes the other open source developers (general project contributors) will actually see a dip in pay. I have to disagree with this point. I am not sure anyone is going to see a dip in pay, especially in this marketplace. And, I would hope that these contributors, through hard work and perseverance, will become the next maintainers. As a result they will see an uptick in their pay as this transition takes place. At the end of the day, the open source structure has similarities to other corporate structures in that certain individuals will experience growth and increased responsibilities which will result in higher pay, while there will be others that are not as motivated and become somewhat stagnant in their pay scale. This happens in basically every known entity that I have ever recruited for. Nothing new here.
One of the parts that I truly enjoy about this article is the mention of open source developers being "free agents". I think he is right on the money with this assessment. This is something that I have thought about for a few years, and I think it will take shape, if it has not started to do so already. In fact it has to some extent, with a lot of the open source maintainers being employed by some of the leading open source technology companies. However, I do not think we have seen the compensation piece take full effect yet. Me being a huge sports fan, I put it in that context. I see it no different than baseball players, football players, etc. If you are a good offensive tackle for the Chicago Bears, you more than likely will be a good offensive tackle for the Green Bay Packers. Sure, there is a new playbook, but you know the position well, and you should be able to adapt fairly easily. When these players make that move as a free agent, they reap the monetary effects of such a move. Same will be the case for open source developers. If you are the maintainer of a particular open source project at one company, and there are going to be other companies utilizing that project that are interested in your services, you should be able to continue your work without too many interruptions at your next place of employment. Sure, it is a different company with a different culture, but that is just like a different playbook for a different organization. At the end of the day, you are going to be doing the same work, for the most part, because that is what you were hired to do. They are going to provide you increased compensation because not only do you write solid code, but you are also an influential member of that community project.
My prediction, due to this scenario, is that the open source developer's future compensation levels is very bright. There is no question that the top developer's are going to see the biggest gains, but there will be gains throughout the ranks. We continue to experience a shortage of open source talent in the marketplace and this will just reinforce this notion. The beauty of open source, as has been mentioned countless times, is that you control your destiny no matter who you are or where you come from. You do not have to be a MS in EE from Stanford to excel in the open source world. Throw out the resume, it boils down to who's code is the most solid.
Overall, this is a very good read with other good examples and points that I did not have time to mention here. Take a peak at it when you get the chance.
Monday, July 9, 2007
Mentioned in LKML FAQ's
We have known this for some time, but it is worth a mention for a shameless plug here. We are delighted that HotLinuxJobs is mentioned in the Linux Kernel Mailing List's (LKML) FAQ's , This mention comes at Question 21 in Section 3. That question relates to whether or not they accept job offer/request postings on the list, which of course is a huge NO, but they do mention that you might find www.hotlinuxjobs.com a useful site. We extend our gratitude to Richard Gooch (FAQ Maintainer) for this mention, or the person that brought it to his attention. Thanks for the recognition!
Tuesday, July 3, 2007
Is it good that senior Linux kernel contributors are doing more managing than coding?
In a recent LinuxWorld article about Greg Kroah-Hartman's keynote at OLS this year, he spoke about how more of his time is spent reviewing code as opposed to producing it. Greg goes on to mention that in the latest kernel release, the 30 most active kernel developers only contributed about 30% of the code, while the 20 most active kernel developers contributed 80% of the code just two years ago. So, through this maturation process in Linux kernel development, is this good for overall Linux kernel development?
On the plus side, you have the most experienced kernel developers doing code review, so the code should be solid once it is officially integrated into one of the mainline kernel trees. Perhaps on the downside, with the experience that these kernel developers have, would they have been able produce the high quality code in a more efficient manner? I of course do not know the answer to that question, but it is something to ponder.
As the kernel matures and the organizational chart of Linux kernel development starts to look more like a corporation's organizational chart, it is very interesting to watch this transition. It sure starts to mirror the career decisions that developers are forced to make at one point or another in their career. They reach that "fork in the road" per se, and the decision has to be made as to whether or not they go the management route or stay in a development role. This appears to be the decision that is forced upon these well known kernel developers, and it will be interesting to see which ones take which path.
On the plus side, you have the most experienced kernel developers doing code review, so the code should be solid once it is officially integrated into one of the mainline kernel trees. Perhaps on the downside, with the experience that these kernel developers have, would they have been able produce the high quality code in a more efficient manner? I of course do not know the answer to that question, but it is something to ponder.
As the kernel matures and the organizational chart of Linux kernel development starts to look more like a corporation's organizational chart, it is very interesting to watch this transition. It sure starts to mirror the career decisions that developers are forced to make at one point or another in their career. They reach that "fork in the road" per se, and the decision has to be made as to whether or not they go the management route or stay in a development role. This appears to be the decision that is forced upon these well known kernel developers, and it will be interesting to see which ones take which path.
Subscribe to:
Posts (Atom)
