Hacker News Reader

Comment by mgaunard | Hacker News Reader

The reasons you write open-source code:

  - training purposes to better yourself
  - as a showcase or to build up your reputation to get hired
  - because you have a niche need in your personal life that no one else already solved

None of those reasons are invalidated by big corporations using open-source without paying back.

View on HN

I'd like to include my reasons:

- It's a lot of fun

- It's addictive

Honestly I was a bit struck when a friend looked at my github and said it was a nice portfolio. The material view never hit me at all: my github is a product purely of what I've wasted/spent time on for fun, not to make a profile. :)

I'm not a fan of the trend I've seen where GitHub is treated as a portfolio- I once had a hiring manager I worked with tell me I should delete a few of my GitHub projects, as they made me appear "amateurish." I WAS an amateur! And I don't want to feel like I need to to hide random things I've tinkered with just to impress others. As a result, I know those who have multiple GitHub accts, one for fun personal stuff and one for showing off to potential employers.

Or, you could do every bit of work as if it were for a vital infrastructure project.

That’s what I do. Even my “farting around” projects have a lot of polish. I write everything I do as if it will ship.

I find it establishes great work habits and personal integrity, and my GH ids (I have a personal one, and a couple of org ones) make outstanding portfolios[0].

Not to worry, though. My experience, is that potential employers never look at at GH portfolios. Instead, they rely on leetcode tests to evaluate applicants.

[0] https://github.com/ChrisMarshallNY

If that's what you want to do and what you have the personal time for, that's fantastic. For others, being obligated to reach that level of polish means a ton of code will simply never happen.

I'd liken it to an artist's sketchbook. If every piece is required to have the appearance of a master work, lest you be judged by it, then the sketches must remain private or else be destroyed (which they often were). But the masterpieces don't jump to the canvas without sketches. Forgo one, forgo the other. And an artist's sketches often have an elegance that's lost in the translation to a finished piece. I see similar parallels in the rough line art for animation, and certainly in an architect's studies. Not all of it is destined to be finished, either, but such work is often prized regardless.

So why (aside from fearing for our careers) should we be afraid to share?

Some code is inherently low-stakes. Some code will only ever be useful, even to the public, for a few months. Sometimes I just want to express an idea, where the proof of concept matters far more than making something shippable, which might imply strapping it down to a particular platform or ecosystem where no one outside those walls is likely to see it.

Even on the job, there's a time and place for the quick & dirty script, where anything more would be an over-engineered waste of time.

Back to the artist analogy, the best advice for maintaining a good portfolio is edit, edit, edit. Constantly be looking to remove work, leaving only your best, as you'll be judged by the worst. Does that model really work for GitHub? If everyone started withdrawing work they were no longer satisfied with, we'd all be worse off, if not actively harmed. So that's where I believe my artist analogy ought to end.

As an artist (by training. I don't really do that much, these days), I can relate.

I used to have a big Strathmore sketchbook, that I took with me, everywhere, and, whenever I had the time, I would practice in it. I have old photos of me, with it. I was fairly scruffy-looking [still are -Ed.], and the sketchbook was sort of my "brand." My classmates used to call me "Puff," because I liked drawing dragons.

It got to the point, where even my rough sketches would be as good as finished works.

The same goes with my code. For example, when I start writing code, I habitually add a headerdoc comment, almost immediately. I write about that here: https://littlegreenviper.com/miscellany/leaving-a-legacy/

I work surprisingly quickly. I can generally spin up a full-fat native swift app, App Store-ready, in a couple of days. I do that frequently for my test harnesses (but I prefer taking more time, for the apps I actually plan to release).

I never really warmed to Boris Valleho's work (he used to hang in a gallery that I had work in, and I met him), but I have to admit, that guy can draw.

Look up his sketches. He used to make a lot of money, selling them, so there's a lot of them out there. The gallery that I mentioned, had a big rack of his castoffs, selling for hundreds of dollars. They sold like hotcakes. He was that gallery's star (I, on the other hand, was chopped liver).

Here's a few of his marketed drawings, but his sketches are almost as good: https://www.borisjulie.com/product-category/prints/boris-pri...

> It got to the point, where even my rough sketches would be as good as finished works.

Hah, I feel like I understand more where you're coming from with that. I was the opposite, seeking to get my finished works to feel more like my rough sketches.

> I never really warmed to Boris Valleho's work (he used to hang in a gallery that I had work in, and I met him), but I have to admit, that guy can draw.

That he can draw is undeniable indeed. There are a few artists whose sketch work reaches that level of refinement almost immediately. Others get there after years of study and practice. Still others don't see that at as a goal at all for that stage of their process, and others still would see it as an antithesis to what they're after. Looking at Valleho's finished work, I can at least understand how his sketches are in service to that sort of end state.

Compare, perhaps, to some Rennaisance-era sketches. Typically far rougher compared to the finished works, but hardly less impressive. I'd suggest there's a great difference in what they were interested in: matters of anatomy, gesture, and composition. Of course, they were also inventing and rediscovering knowledge that modern artists have far easier access to. There's an interesting dichotomy in that some destroyed their sketch work, while others had far less interest in actually finishing anything.

I've forgotten an appalling degree of art history, so I can't readily name names, but as far as finished works go, I had a fondness for painters using relatively minimalist brush strokes, with each application of paint exactly the right color in exactly the right place.

I use a Rembrandt sketch as an example in this post: https://littlegreenviper.com/miscellany/thats-not-what-ships...

I prefer art to be a lot “rougher” than Valleho’s work, but had a difficult time, doing it, myself; which was one factor in my eventual retreat from art.

It really depends what your goals are. I often have a problem I want to solve in my personal life, and not very much time. (Ex: code that makes the figures for a blog post.) So I write quickly, doing the minimum to get it done.

I would never do that in a work context, because the environment there is so different, but it's often the right trade-off for things I'm doing for fun.

(And I still make all the code open source because, well, it might be useful to someone even in the state it's in)

Absolutely. I don't make any value judgements at all. I am quite aware that my own workflow is not for everyone, and is not inherently "better," in any way.

I do a lot of self-discipline "tricks," in order to enforce a certain habitual workflow, and this is one of them.

Many folks get far more done than I do, using very different techniques. I just enjoy the process and the Craft, as much as I do the end result.

One significant advantage, for me, is that I never have to worry about cleaning the house before the boss comes over for tea.

I find this materialistic view depressing. Not everything worth doing is ultimately about selling your lifetime to the highest bidder. Some things are just worth doing intrinsically. Like, fixing a bug that affects a high number of people. Or solving a problem just for the fun of it.

Yes, and there are some great take-aways that I didn't know I would get when starting, like connecting to very smart people and learning a lot, as well as being accepted as one (maybe) in the community of those.

That does not work.

After several years of hard work a prior open source project that grew to immense popularity got me employment a few times. It wasn’t the actual project, code, or capabilities that meant anything. The only thing appealing about that project was it’s popularity.

Nobody ever looked at the code, except people interested in submitting pull requests. If you think a prospective employer will take the time to analyze the code you are either applying for an exceptional specialized position or completely mistaken.

Work on open source because you like to solve tough problems, want to grow as a developer, or because you just want to build some interesting product. Don’t kid yourself into thinking the code will immediately solve some business interest.

A part of my job is to review CVs and select candidates to interview for my team. The first thing I do is check to see if they have a github account, and if they do I check their projects. Anything that looks relevant gets a quick inspection. It makes difference to whether they get an interview, and it makes for some topics of discussion during the interview. It confirms for me that the candidate is in fact actually interested in the field, and shows be the porential quality of their work.

If you think nobody ever looks at your public code, you're wrong. It's just like wearing a bathing suit at the beach or pool: people look.

Perhaps it’s because I write JavaScript. Interviews in JavaScript, at least this year, are leet code for backend and strangely the Node API never seems to come up. The front end is islands of declarative logic in React. That’s it.

GitHub and LinkedIn profiles only serve to reinforce the job experience printed on the resume.

I think it's great that you do this, but I agree with the parent that it's rare.

Speaking as someone who has the same thing on their job duties — yeah. Same here.

This is part of what's broken. If your users aren't examining your code, then they're vulnerable to supply-chain attacks from it.

Well that's precisely how it works, why would you expect an employer to review your code for free?

Instead they'll just look at whether you contributed to big projects.

Someone who managed to make significant contributions to Linux or LLVM for example might be better than the average joe.

> Someone who managed to make significant contributions to Linux or LLVM for example might be better than the average joe.

which leads to people who want to use this mechanism to claim credit in projects they don't actually have contributions in, and because the employer doesn't actually look at the code, they cannot tell.

I recall a while ago where someone would contribute a skeleton README or some random typo fixes to many different project, and using that to make their claim to fame.

So i reject the idea that employers should use open source contributions as a metric without closely examining what those contributions are.

There will always be people that lie or embelish what they did. One of the big reasons for technical interviews is to assess how much of what the candidate claims is true.

> Someone who managed to make significant contributions to Linux or LLVM for example might be better than the average joe.

Specifically, may be better at navigating the politics of organisations. Which is a key skill at many employers - likely equal to or more important than technical skill as one ascends through the ranks.

I agree with this, plus the "it's fun" reason others have mentioned.

I started work on my canvas library (licence: MIT) 8 years ago mainly so I'd have something to showcase to potential employers. It worked: the reason I finally managed to land a job as a web developer was because someone took time to check out the library and decided the work I'd put in was worth them taking a risk on an older new entrant.

Since that time I've continued to develop the library to help me deepen my knowledge of all things canvas. Especially since I started to look at ways to make canvas elements more responsive, and more accessible. But the main reason is just the joy I get from using it to create pretty demos and animations - the library scratches a creative itch.

I got used to the idea that I'll never be rich a long time ago. Good friends are more important than money.

Many also make money with open source software, for example a classic approach seems to be to offer consulting services around your product, or hosting.

WordPress and ElasticSearch come to mind, both made a lot of money.

You also get people adding to your product for free.

The original reason may not be invalidated.

But as a continuous activity, over years, what exactly is in it for maintainers to get up in the morning and trade their remaining lease on life for value to be consumed by rich leeches?

The value isn’t “consumed”. I get as much value out of my open source projects regardless of who is using them.

The fact that you consider users to be “leeches” means you’re missing the point of open source.

'Leech' is the correct term for this relationship.

https://en.m.wikipedia.org/wiki/Leech_(computing)

Contributors are not leeching the work.

Users who don't contribute are though, especially when they suck down developer time with issues.

You're not in a position to judge my understanding of FOSS because the word 'leech' makes you uncomfortable.

Eh... regardless of how it's generally used, I think "leech" implies a parasite that is actively harming a host. Generally users who don't contribute aren't directly _benefitting_ the author, but they generally aren't harming the author either.

They enjoy it.

They need to for their own needs.

It provides them with some other benefit.

Unfalsifiable. You're basically saying "they're adults, so if they do it they must necessarily get value from it".

Myth of the rational maintainer, if you will.

In real life, people get (mentally) stuck into suboptimal situations where leaving would make them happier all the friggin' time.

Bad jobs they should have quit. Bad partners they should have broken up with.

Why not bad open-source projects they should have stopped maintaining?

one would just assume that people doing it are making a rational choice, and don't need someone else to second guess it.

What's so wrong with this line of thinking?

The entire post your responding to is explaining what is wrong "this line of thinking" and while you may disagree you don't really argue, you just assert.

Over the years, the itch they were scratching tends to get fully scratched, people move on from their needs to other things.

What was enjoyable, becomes grunt work, like making the full set of unit tests for features users want, but you don't actually use yourself.

Whatever this handwavy 'other benefit' was, stops being beneficial.

But they're still paying the opportunity cost, sitting down as the older, greyer, burnt out maintainer while others get the benefit from their work.

Writing the software and releasing it with a non-foss license might be a better fit for such a person. Free for personal use? Sell it for a modest fee? Put the source on github without allowing people to modify it? Many possibilities.

Reply on news.ycombinator.com