[Discuss] Publish or Perish - coming to sw dev & IT operations

[Tom Metro]

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/