Rich Braun wrote: > ...I'd already come to the conclusion sometime around 2011 that I'd > better start building an open-source portfolio...
Sure, it is increasingly common to see job ads that request your Github profile URL as part of your application. > Gild is a startup that hopes to displace LinkedIn among employers who are > looking for the best applicants. The algorithm they're using relies on > searchable information that you as a potential applicant have published about > yourself: at this point, I think it's mostly open-source contributions in > places like GitHub or SourceForge. How much is this business model nullified by candidates voluntarily linking to their code hosting profiles from LinkedIn? What if LinkedIn starts prompting users at profile creation time to add these links? A tool like this could be good for finding developers who aren't looking for work, which some employers believe makes them better candidates. (The assumption being that if you are already happily employed, then you must be good at your job.) If the tool doesn't "go deep" and index details from their code hosting profiles, it'll be of limited usefulness in terms of narrowing down the list of candidates. On the other hand, inferring a developer's skills from their code hosting profile can be highly error prone. For example, I'm listed as an administrator of a project at Sourceforge for which I didn't write a line of code. (Well, not strictly true. I contributed some shell scripting, which lived outside the repository.) On that project my contribution was to documentation, design, and supporting users of the project. Conversely, these sites do a poor job of surfacing non-code contributions, like bug reports and architecture discussions. One of the reasons why seeing a candidate's open source contributions is so useful to an employer, even if they don't care about open source, is that it lets them see your code, which is widely recognized as one of the best ways to judge the technical skills of a developer. In the past this was addressed by walking into an interview with a folder with some code printouts. This was always tricky to pull off, as few developers have written code they own, so they were showing proprietary sample code belonging to a former employer, which they may or may not have gotten permission to show. Open source at least gets around this gray area of code sharing, and gets you a public URL to reference, instead of an antiquated folder of paper. But unless the candidate is the lead developer on the project they point to, it may be tough to determine what they were actually responsible for. (If the candidate (or the hosting site) provides links to specific commits, then not a problem.) Still, I'm skeptical that Gild can extract enough accurate information about a developer from the available metadata to meaningfully narrow the list of candidates to something a hiring manager can review. Compare that to the skill endorsement feature LinkedIn introduced a while back. Candidates often show a laundry list of skills, but now with them sorted by number of endorsements, its easy to see what skills someone has actually been hired to practice. > Is the open-source software movement going to create a new world of haves and > have-nots based on the amount of time and freedom that individuals working as > employees to contribute into open-source? Is this a good thing... Having a broad base of employee pressure on employers to let them contribute to open source to benefit their future careers is certainly a good thing from the perspective of open source. Is this any different from the way high school kids are motivated to do various community service activities to boost their college applications? To answer the question of whether this model creates "have-nots" you have to look at the barriers to contributing to open source. What are they? You need some minimal skills (which you presumably have, if you are working in a tech field), and computer equipment (ditto), and time, where time is likely to be the limiting factor for most. College kids should be off to a good start in this area, as they often have time, and class mandated projects, which can be applied to working on open source. (Lots of examples of this happening, with many well known projects evolving from student projects, like for example the Dovecot IMAP server. The Google Summer of Code program further encourages this.) For those already in the workforce, they'll have to negotiate with their employer for "open source time" the same way you might for training, or other job benefits that contribute to your future career prospects. > Thinking about the future of companies like Apple, which are firmly in the > closed-source/proprietary trade-secrets realm, it seems to me that if this > recent shift in the world of IT employment continues, it could speed such > companies' demise as their access to job applicants dries up. Such companies could always address the need in a way similar to Google's "20% time," where they let employers pursue projects of their own interest on the company dime, and not have open source "pollute" their products. It does seem likely that in the long run, as developers spending a portion of their career working on open source work their way up the ranks to managers and C-level executives, it will cause a cultural shift in these companies. Then again, there are plenty of companies that don't offer training and other career advancement opportunities and they still find plenty of employees. But they tend not to attract the top candidates. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
