Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Do you contribute to open source projects?
68 points by dirtylowprofile on March 22, 2022 | hide | past | favorite | 81 comments
I'm looking to contribute to open source projects but just could not find the time since coding without pay is so foreign to me. I could not just approach my employer and ask if I could help code this open source project. What is your motivation for doing such things, thanks to all the open source maintainers!



Build it 'cos you need it. The things I have open-sourced I need/needed. The motivation then is clear.

Outside of that, there's the 'warm fuzzy' from others using your code, it's nice to be part of a wider solution and not just the small world of day-to-day coding. It also forces you to project the best version of you, and make sure you've really got something to say, especially when a project serious gets traction. This helps personal development as an engineer, but also as a diplomat ;)

If you're contributing to someone else's repo then know that effort from contributors is in itself motivating for the maintainers. Knowing that people care enough to get involved helps enormously. Granted, not every contribution is always of the quality needed, but still, on balance I think it is still great when others get involved and helps the project push on.

A nice side-benefit that's come along recently is the Github 'Arctic Code Vault' Archive Program [2]. It's good to have my projects be a small part of permanent history (well, at least a millennium!).

It isn't all fun and games, it can be a real drag at times. The amount of time I've spent on my open-source projects is enormous (which is also why you should build something you need). A project that gets a decent level of popularity will require regular effort to maintain both the code and the relationship with your community.

Ultimately though I think it's a rewarding experience, and one that I wouldn't undo.

[1] https://github.com/louthy

[2] https://archiveprogram.github.com


> Build it 'cos you need it. The things I have open-sourced I need/needed. The motivation then is clear.

On the contrary, the ability to find everything you need lowers the motivation :)


That only applies if there's a thing that does exactly what you want, how you want, within your constraints. Sometimes your contribution is adding a small feature that others will find useful.


Awesome answer thanks! Can I follow you on GitHub.


Sure :)


> I'm looking to contribute to open source projects but just could not find the time since coding without pay is so foreign to me.

I've made contributions to things that benefit me, mostly, e.g., if I'm working on a side project that uses a library, and during that, I notice a bug in the library. If it's simple enough to be fixed, then my side-project benefits. Sometimes, I just report the bug, of course. (Which I count as a contribution; especially a well-written bug report, containing the right level of detail to allow someone to track down a bug is a contribution. A badly written "it broke", not so much, ofc.…)

> I could not just approach my employer and ask if I could help code this open source project.

Most often, it's "this bug is bothering us, we've written a fix, and the cost of upstreaming the fix is < the cost of maintaining a fork." Good managers I've had readily understand that ROI/cost trade-off is to their benefit there; forks are terribly time-consuming. (And it's not something that's going to be the company's secret sauce, of course. But I've never had that happen… the bug fixes that crop up are almost always of the "mundane bullshit" variety, stuff you just want out of our way — which is precisely why they should be upstreamed.)


Like everyone else i rely on open source libraries. I sometimes need to change them either to fix bugs that i encounter or to improve them in some way to better fit my purposes.

It is in my best interest to send my changes to the library maintainer so that i do not have to maintain my own fork of the library.

It is not always in best interest of maintainers to merge my changes because it is either more work for them or their purposes for the library are too different from mine.

Maintaining an open source project is a lot of work and i would also like to hear more from maintainers about their motivation to do it.


Like the PP, I can be using a FOSS application or library and notice a bug, or try to run it against some unsupported device, or against the new version of something. I fix it for myself if I can, then I send the patch upstream. It is like stone soup - the original FOSS project implements something for their needs, I tweak it a little to work for me, and soon enough you have a program useful to a lot of people.

Also sometimes I write something for myself, then think it's possible someone else might find it useful, so I release it as FOSS on say Github. Later I see people watching it, starring it and forking it, and even adding commits to their forks, so I figure someone else must have found it useful.


You seem to imply that "contributing to open source projects" must mean coding, but there's lots of tasks that you can do that are not coding.

* Answering a question about PostgreSQL configuration files on Stack Overflow contributes to the PostgreSQL project.

* Tweeting about your favorite underrated Vim keybinding contributes to the Vim project.

* Supporting Jason Donenfeld on Patreon contributes to the Wireguard project.

* Proofreading the Linux kernel documentation contributes to the Linux project.

* Contributing a translation of the Blender GUI into a less common language contributes to the Blender project.

* Designing a wallpaper artwork for the Plasma desktop contributes to the KDE project.

* Writing a detailed bug report for a Sway crash contributes to the Sway project.

And so on, and so forth.


> I could not just approach my employer and ask if I could help code this open source project

I've open sourced multiple (small) changes I've made to various open source projects on company time. Usually it's projects we use and where I've either fixed bugs or added a small feature that we could use.

Employer doesn't have to apply patchsets to our dependencies and doesn't have to keep them up to date. Everyone else gets the fixes as well. => Everyone wins. Employer sees that.


I use FOSS in my personal computing needs which heavily intersects with my professional interests. Using 3rd party (FOSS) exposes me to bugs, issues with documentation, problems running things on esoteric hardware, security issues, eventually performance issues. Because of this I often need feedback from maintainers and I'm at their mercy for how fast my issue is resolved.

Supplying a patch, giving feedback for issues, is the least I can do to give back to the people who took the time to write that code.

Because some projects I contribute to are also relevant in my day job I get a deeper insight into that part. Money/financial aspects do not play into that decision but I'd be twisting the truth if I didn't admit the positive impact FOSS had to my career.

Having contributed to FOSS projects in a public way also says something about the person I'm interviewing. If most of my stack is built on FOSS and an applicant comes along with a cool CV but has not one contribution to a single project it's immediately a hard pass from me. I never put applicants through silly technical screening sessions unless they are fresh outta university. But no public commits are a red-flag for senior engineers.


The idea that senior engineers need public commits to be even considered for a job seems a little extreme to me. There are myriad reasons why an extremely competent senior engineer might not have public commits.

The lack of public commits does not signal whether or not someone is a competent senior engineer.


I guess if the rest of the CV was a really strong match, I'd give them a chance but they'd have to do a "technical interview" same as any other junior. I can only speak for myself that I haven't seen many CV's in my environment where 98% of the stack is built on FOSS and 100% of the tooling uses FOSS that an expert in that field has never contributed anything to a FOSS project, has never asked a question on an issue or created an issue (and also lacks any other public facing work like personal projects, talks, blogs, etc). I'd also interview them if they were recommended by a colleague.


Big corp I work for will not allow me to write single line of code for open source projects. I might leak something confidential this way. The reality is not black and white like you try to paint it. Heck I had problems with leaking confidential information when supplied electrical diagram with mechanical drawing for one of the suppliers.


how much does your employer benefit from FOSS? if they do use it but prevent their own people from giving back it sounds like they're terrible people but also pretty dumb because they're losing out on building knowhow about those systems among their own workforce (I'm obviously not shocked if that is the case).


That’s exactly the case. We are allowed to do open source request, legal team writes a list what can we do (don’t share, don’t distribute, don’t release, internal use only, etc) and this goes on like this. Since legal team takes weeks, we write our own half baked solutions and use open source extremely seldom.


I like to contribute to open source! Mostly in the form of documentation and guides. I find writing proper how-to tutorials very rewarding and a good way that I can contribute to any given project.

Everyone appreciates guides about integrating various tooling with other tools, and there's a lot of decent work to be done in this area.

I also like to use the opportunity to hone my writing skills. I haven't written too many guides, but the most popular one is a POC on using playwright to create simple tests. It still gets a modest amount of views per day, 20-30. I also get a kick out of seeing my work linked within a Microsoft project. Always brings a smile out of me.


Sometimes

> Why do you do it?

Because I can so, why not?

Sometimes the help offer has been enthusiastically accepted, other politely refused (I don't have any problem with that) and sometimes I never received an answer.

So my advice would be to try the waters first, before to start spending time or talking with your boss, and contact the maintainers. Some open source teams are more open to external help than other. Some have a hard nucleus and are wary of introducing a foreigner in the team (probably a wise move), and sometimes people just move on with their lives and forget about their single person home project. You could find also that the contact emails are obsolete and need to research and use a different one.

And if you don't feel comfortable with the team or the project direction after a reasonable period of time, just quit. Don't start a war by leadership, or boycott or badmouth anybody, just detach yourself gradually and move on to other personal projects. Is as simple as that. You are not marrying anybody.


My motivation has usually been to add features/fixes that *I* would consider useful for my particular use cases, and most times it's for software I use in my personal time or personal projects.

Expecting to get paid for your first contributions to open source sounds, to me, like the wrong motivation.


>What is your motivation for doing such things

I use Linux and most s/w I've installed are free and open source. Also, not software as such, but I've benefitted a lot from free programming learning resources.

So, I try to pay it forward similarly by answering questions on stackoverflow/reddit/etc, giving away free copies of my ebooks, open sourcing s/w I've written, promoting open source, etc.

See also: https://opensource.guide/how-to-contribute/ - section 4 has handy links to find projects


>> What is your motivation for doing such things?

I've used open source whenever possible for a long time but never "gave back". It was a matter of finding the right thing to contribute to. When I found and used SolveSpace, I loved the tool but found it a bit limited in capability. Looking at the dates on the repository I found that the areas I thought needed work hadn't been touched in at least 2 years. Then I realized if I wanted it to be better it's my job to make it so. It's still the only project I really contribute to, but there are a couple others I may get involved in at some point. I no longer have a lot of time for programming as a hobby, so I view this as me doing volunteer work. It's a bit of responsibility I've decided to take on at least as much as it is a fun thing.

Your reasons for doing and your choice of project will be your own.


I do get joy from coding but with regards to OS:

- I simply don't know where to begin... which one to contribute to? I don't have an area of computing that excites me to such a degree for longer than a week.

- I worry that anything meaningful that warrants open-source contribution is going to established - and will feel more like a dayjob in terms of creativity (or lack thereof; implementing a shopping list of FRs) and formality.

I could be entirely wrong but I've never tested this hypothesis as I have a huge backlog of (useless/unprofitable) side-projects to build. Perhaps I'm more of a lone wolf :)

EDIT: One thing that I do assume would be better in established OS is focusing on complexity and going deeper. With side projects you'll often spend far more time on boilerplate stuff than on the "big idea" that might have drawn you in.


I have made PRs to patch bugs I find on projects that I have used in production applications. Sadly that is as much as I have done, I would love to contribute more but I'm so burned out from work I don't have the energy to do more outside of it.


Certainly not as much as I used to, but yes I contribute to open source projects. It's a combination of making things I'm interested in, drive by patches for tools that almost do what I want or have a bug that I've managed to trigger, and chatting with others building things they're interested in. Being a maintainer is a different ballgame than contributing to a project without the long term responsibility, though both can scratch an itch and help develop new skillsets while helping to create new pieces of software.


When I worked as an employee I contributed mostly just with docs fixes or bug reports (and not that often). I think it's mostly a mindset of seeing an issue yourself and noticing that others probably also are confused or misled by something so you go and report it!

Now that I'm working full-time on open-source and my own company I can contribute more easily to projects like upgrading SQLite source in a few bindings libraries [0], [1], [2] when 3.38 came out.

If anyone is interested in contributing to open-source and wants a bit more guidance though I have a number of good "first timer" projects related to data tooling for [3]. Only expectation is that you have some experience with Go. Join discord.multiprocess.io, go to the #dev channel and say hi!

[0] https://github.com/mattn/go-sqlite3/pull/1019

[1] https://github.com/mapbox/node-sqlite3/pull/1550

[2] https://github.com/JoshuaWise/better-sqlite3/pull/778

[3] https://github.com/multiprocessio/datastation


I am building an open source web framework comparison. It is aimed at experienced developers who want to get a quick overview of how the current web framework landscape looks like. My intention is to make it a long-running project that will be an up-to-date reference point at any time in the future.

The idea is to put together a project that gives an overview of how to set up a minimal viable web application from scratch via all the different frameworks.

For each framework the project features a self-explanatory shell script that builds a web app with routing, templates and user accounts. So there is no ambiguity of how to reproduce the results. And it is even possible to just copy&paste the steps into a fresh Linux installation, see the framework in action and build your own application on top of it.

The scripts have one part for every aspect like routing, templates, accounts. So if you want to compare how the frameworks do templating, you can look at the "Let's use templates" part and have a quick overview of how it is done in Django, Laravel, Flask, Symfony, NextJS...

So far, 5 developers have joined and contributed. Django and Flask are complete. Laravel and Symfony have routing and templates but no user accounts yet. I wonder if this distribution of contributions across the frameworks is somehow telling about their ecosystems?

Here is the repo:

https://github.com/no-gravity/web_app_from_scratch


I have contributed work I've done in the context of paid employment. Very very occasionally I do so outside of work (maybe I use a tool at home, it doesn't work properly for what I want, I patch it and send a PR upstream).

My motivation to do so is if everyone puts in just a little bit of extra effort to contribute upstream we can get many people making small patches. It's nice for a contributor to see folks care (as opposed to just complaining of issues).


Yes, although mostly in small, incremental ways.

I try to use entirely free and open source software on my personal laptop (and I'm fortunate enough that my work environment is fairly similar too).

When I encounter some kind of annoying issue, I'll take a look at the code that caused the problem (and sometimes the components that it interacts with), and if there's a way to improve the situation then I'll consider putting together at least an issue report.

In practice the time and thought required to write a code-level description of the problem can sometimes be 90% of the work to develop a fix, so frequently the issue report is followed swiftly by a patch / pull request / merge request.

Review, merge and release can all take time - at various points I've had over twenty changes pending to more than ten separate projects.

It's extremely satisfying and encouraging to wake up or check your email and be reminded about some kind of nagging bug/problem that you encountered months or even years ago and to hear that it's now solved for you and anyone else who would have run into the same issue in future.

A suggestion, although everyone can learn in their own way: consider treating open source contributions the same way that you might do for small tickets or tasks at work.


Nowadays mainly when talking projects that are related to mine or to future work.For example, a package that I want to use and I see it's buggy/not working properly.I'll point out the issue, offer some testing/feedback.If I really need it working I'll invest the time 'out of my pocket' to solve it and propose a solution to the dev(s).That way I know I also gave and received something.

To me, contributing to OSS for 'community' brownie points never had any meaning, mainly because it sometimes skews the perception of actual interest in a project with interest of a person to be recognized by contributing to that project.The latter is a legitimate goal, but most people are not coming forward with this aspect.I don't recommend entering OSS contributions if you're not comfortable with financial risk.It sounds cliche but it's true: OSS contributions and activity should not be influenced by money, but rather (and it still often is) mainly by actual interest: hobbyists, researchers, etc.However this is not a fairy tale and things still get moved by money: it's just a matter of priority and where do you see the value.


I've been involved in FOSS since '99 and have been a prolific contributor since 2012. It's a hobby, a passion, something to keep my skills fresh and the edge sharp. It's also fun for me to put my stuff out there and see how others might use it. I'm on a few core teams of some major projects. I usually time box open source to 4-6 hours a week, unless sponsored by my employer.


I would like to do so more. I have contributed small things like small bug fixes or documentation fixes, but these have been very minor (basically fixes I could make directly in the GitHub web interface). Definitely have filed issues, and I always try to do due diligence and provide a lot of info in the issues I have filed.

There are two ways I could see contributing more. One is by creating some libraries that would hopefully be used by others. This is something I'm definitely trying to push myself to do, which includes gaining some confidence of just getting something out there. The other way is to contribute to existing projects, but I have personally found this difficult. Code bases are often extremely complex, and I personally just don't understand how some people are able to dive into foreign code bases and be productive. It's possible I'm not smart enough, but the other excuse is that there's often a lot of documentation missing or nonexistent and it's tough to get some mentoring on things since everyone else contributing is already so busy.


I contribute to Our World In Data [0] and some of the Rails repos. I also run my own open source projects [1][2].

I've just recently started doing it, and I only put in a few hours each week. Slow and steady wins the race. My motivation is three-fold: First, it's gratifying to give something back to software I love using for free. Second, I learn a lot. Third, if I ever want to work with one of the companies who are stewarding these repos, it gives me a leg up in the application process.

0: https://github.com/owid/owid-grapher

1: https://github.com/shafy/fugu

2: https://github.com/mapzy/mapzy


There are many ways to contribute to Open Source projects, depending on the project and what sort of contributions, if any, it is open to. There are financial contributions, bug reports, feedback, a thank you / letting the project maintainers know how you use the project, promoting the project to others, documentation improvements, code improvements, helping with infrastructure, verifying bug reports... its not just coding, and some of these you may be able to do with little or no time involved. All are forms of contribution. Not all Open Source projects are open to all of these, some aren't open to any of them (except perhaps promotion). So it is best to get familiar with the project by checking the site, docs, trackers, etc or maybe reaching out to the maintainers if you still have questions before jumping in.


For me, the primary motivation is giving to the community. I believe that doing this makes the world just a little better in one way or another. For every person who does this, the effect multiplies. Think about how someone else's open source made your life better. You could do that for other people too.


I started contributing to a project named Vorta ( https://vorta.borgbase.com/ ) because:

1- I use the app and wanted to give back something.

2- I use many open source software and wanted to help a small open source tool.

3- Practice my coding skills on a open source project.

It does require some commitment from your part but you can help with small things that don't require a lot of your time, like writing documentation, translating, testing. You can commit maybe 1hr a day/week to write/translate documentation, or test a bug someone fixed.

I started doing translations because it was simple enough for me to begin understanding the projects processes and the code.

Also, it feels good that you are helping the project continue and be used by other people like you even if they don't contribute.


The best motivation is a need for yourself or your job.

If you're using open source and inevitably find bugs or missing features start with opening good and thorough issues for them. That's already a (minor) contribution that is more often appreciated than not. Then ask if the maintainers are open to accept a PR for the issue and if they say they are go on and do the work. Expect feedback and criticism on the PR and respect that it's the maintainers that have to deal with your contribution once it's merged.

If you do all that in a respectful manner, it usually will be appreciated and you will have given something back.

Another option is to just start your own project if you encounter something that is missing, possibly during your job, and get permission to open source that.


I wanna add my own story below my comment as it's justvtangential to my point and the question.

I maintain a couple open source projects and one of them solved a business need for my employer back then. I asked permission and got clearance to contribute my work to open source.

The project solves a rather small very specialized problem that any other option didn't sufficiently. I had initially written it to replace a central part of another open source project that was just way to inefficient. Instead of just adding the code there, I created a standalone library that then got used by that project. That way I was putting less burden on the maintainer of the bigger project by reducing his code base and taking over that part in a separate project. As it was also open source he could always fork it and adjust if necessary and the change was completely compatible with previous versions, just that it was two orders of magnitude more performant. On top of that others could use my project standalone if they only required that functionality.

By now it's multiple years old, has been downloaded nearly 10 million times, requires nearly no support (it's that simple), has less than 10 stars on Github, but is used in hundreds of projects on Github.

Of course, I'm proud of it and I consider it a success story of open source without too much sustained effort.


I have, but I barely do it at all because I have too many of my own projects to work on, and deciphering someone else's codebase isn't a good use of my time for the kinds of minor problems I'd be solving that someone else could solve better.


I make things because I need them, and I open source them because it's a nice thing to do.

Ask your employer if you can submit documentation or a patch to a project if you notice a bug. It's unlikely they would say no as long as it contains no proprietary information. You can give them a whole pitch about how open source is free software that somebody else maintains, and that you contributing a fix is much cheaper than you having to maintain your own private patches and apply and fix them every time the software is changed upstream. It's saving them time and money. It also gives your company a better reputation among hackers, making it easier to hire good people.


I exclusively work on open source projects without pay or for donations. Granted, I don't work that much, but when I do it is not for money.

I wrote code for money before. I loved the work, hated the environment, didn't believe in the product. I would do it again, only if I had to. I'd rather work at a gas station.

My motivation is to use what skills I have to enact changes on the world I'd like to see happen, no matter how small. It's not much, you won't catch me maintaining a logging library or something like that, usually it's little tools for people to use.


We consume open source libraries at work and sometimes we discover a bug or a small missing feature. When it makes sense to make a change in the library (i.e., the problem is not our misuse of the library), I'll get permission to contribute to that open source project on work time. It's a small way to give back. Also, it is sometimes less effort to fix the root cause rather than working around it in our code.

I'd like to contribute more, given how much I use open source software. It's really hard to keep writing code after a day spent writing code for work.


My motivation is still the fun and that I learn on the way and from others.

And before I made money from open source, I always did it with the (very tiny) hope of making this a full-time job. Basically I created a dream job for myself. (Of course this wasn't easy and isn't for everyone as this took a long time, talented other people, luck, hard effort, more good than bad decisions, ...)

> I could not just approach my employer and ask if I could help code this open source project.

Why not? (Your chances are probably higher, when the project is related but still you should try.)


I do not, though I have done so in the past to a small extent. Long before I came of age the notion of "free" software (in any context) had been well down the path of corruption by corporate interests. My opinion is that these days just about anyone who works on open source code (especially popular, widely used code) without remuneration is effectively a tool to accelerate the race to the bottom in the labor vs capital holder struggle. Why would I want to contribute to that?


I can't critique the risk you raise about reward for worker time; that's valid concern.

But isn't part of the thesis of capitalism that it should drive market efficiencies and thus reduce the cost of goods and services for consumers?

(that could have sounded tongue-in-cheek; it's not intended to be. as I genuinely understand it, cost reductions over time are supposed to be one of the benefits of the free market system. and if those savings are being achieved thanks to open source software in industry -- which I believe they are -- then I think it's worthwhile questioning the effects. do profit margins and tax burdens increase accordingly with the efficiency savings, for example?)


I don’t think the premise of market efficiency gains in capitalism rests on having a pool of free exploitable labor, though. Even in very strictly capitalist systems labor is supposed to be compensated (with money or equivalent value, not stars on a GitHub repo): just less than the value their labor provides the owner of capital.


Agreed. For what it's worth: when contributing to FOSS projects without financial compensation, I generally don't feel exploited.

Perhaps I would feel exploited if I learned that the systems I was contributing to were being used for purposes that I disagree with -- but to counteract that, I think that I can choose to select to contribute to systems that are more likely to be used, on aggregate, for good, thanks to the (perceived?) nature of the projects themselves (and the fact that there are usually at least a few projects that fulfil the dependency gap for any given problem).

Most of the value I derive is selfish in terms of solving my own problems, building my profile (ego, essentially), and a kind of satisfaction (smug even, sometimes, perhaps) at helping solve future problems for a larger audience than myself.

But at the same time I'm very aware that this is a privileged position to be in, to have learned software skills and to be able to pay the bills using those. I think a lot of experienced developers want to provide something back to the next generation: the question is whether the same compensation models are going to apply, or whether the industry is going through a strange topological change that could make for different social contracts for developers.


There are many other ways to contribute to open source projects other than coding!

Depends on what your skillset is, you can help add and/or improve docs, design a logo/swag/icon, author a blog post about your experience with the project, etc.

Sharing a tweet for inspiration: https://twitter.com/DynamicWebPaige/status/10968202457155051...


> I could not just approach my employer and ask if I could help code this open source project.

Why not? Every open source contributor I know is because we worked together and they got paid to write open source software that was valuable to the company.

I know many do it outside of work and my sample set is certainly biased, but I also know that a lot of companies will pay for it if they use that software and see value in it getting better.

Certainly doesn't hurt to ask!


I would really like to, but I've only had time when it's necessary for my full-time work.

..sort of. I'm sure I could make time if I were determined enough, but it's hard to feel good about spending 8+ hours working in front of a screen, then spending more hours working in front of a screen for free. It's probably more of a mental + physical health concern than anything else.


Mind if I ask why you would really like to do it? It sounds like you view programming as just a job. A lot of the people who work on this stuff in their free time just view it as a hobby that they do for fun, not as a second job (although there are people like that, too). Why would you "like" to do something you apparently don't enjoy, and apparently would only do if you got paid to do it? I'm not being snarky, I'm honestly asking.


I don't view it as just a job. It started as a childhood hobby and will always be a part of who I am, but as I've gotten older I've found it more important to balance it out with physical/outdoor/social activities. I'd just spend way too long not moving.


If it's a matter of balance, then there are two possibilities: either you are currently approximately in balance with the amount of programming you do at work and would not do any more unless paid to do so (maybe not even then?), or the amount of programming you do at work is slightly below the balance point and you could do allow yourself to do a little bit more at home; say, 30-60 minutes a day.

If it's the former, then regardless of what what place it used to have in your life, programming right now is just your job. There's no more room for it in other parts of your life because they're being occupied by the things you balance it out with. So my question stands: why would you like to do it?

If it's the latter, then why aren't you doing it already?


I do it a few times a year because many open-source softwares have glaring bugs. This is true in the JS/TS world, at least.

I don't know how you can avoid doing it at all, unless you're just messily working around issues in your codebase or leaving a TODO or item in the backlog to fix it in the distant future. (Which can be a better use of time sometimes of course.)


I make incidental contributions, usually of the form of fixes to bugs I encounter or extensions of function that I need.

My motivation is saving others the ass-ache I just went through. There’s no reason in my mind that I should have a fix and not share it, especially after all of the lift/savings I've gotten over the years from emacs, Linux, apache, svn, git, etc.


I try to contribute fixes/features I want and think make sense to upstream as much as I can, on projects I'm using either for myself or at work. I've mostly worked for companies that recognise it's worth the extra time to get a patch in a good state to upstream/do the docs/PR properly to avoid being forced to use a fork.


> What is your motivation for doing such things

I program for the joy of it. My dad got me a Commodore 64 when I was little. Later I had an IBM XT PCjr. I read Abrash's black book and wrote Wu anti-alias line drawing routines in assembly using DOS debug. ( https://en.wikipedia.org/wiki/Debug_(command) ) It was brutal and I loved it.

I encountered "The Next Whole Earth Catalog" and learned about Christopher Alexander (Pattern Language), Bill Mollison (Permaculture), and Bucky Fuller (Design Science Revolution), among others, and I developed a vision of a different, better world, where drudgery was eliminated by science and technology.

To me software is really only important as a means to this end, and charging for copies of it adds unnecessary and even regressive friction.

> coding without pay is so foreign to me

Ha! I wrote software for about a decade before getting a job doing it. I had been homeless for several years and got tired of e.g. not having a refrigerator or indoor plumbing, so I whumped up a project, presented it at CodeCon 2004, and was hired for my first real computer job later that day. (I'm still messing around with that project BTW: https://xerblin.readthedocs.io/en/latest/index.html )

I should mention that computers can also serve as a kind of spiritual investigation tool, but that's really only for folks on what is called the "mind-only" path.

Anyway, to sum up: to me FOSS is only important as a way to transform economic paradigm to a better. more humane world. Otherwise you're just automating this current shitty system, and "Where's the fun in that?"


I'm lucky enough to work for an employer that defaults to open. The project I'm working on right now is open source.


Me too, though not entirely by luck: when I was looking for a job I specifically went for smallish, open source friendly, remote friendly companies. Then I started contributing to the projects they worked on in my free time, met the people at FOSDEM and chatted with them. This made the hiring process much smoother.

So, maybe I was lucky the plan worked, but it was not just a coincidence.

BTW, that company is still in full hiring attitude, in case you like working on free software.


I've been helped countless times by people filing issues with their problems & workarounds. So when I run into stuff, I try to do a good, thorough job documenting wherever I got to debugging a problem.

nixpkgs' issue tracker has helped (and taught!) me a lot of things :)

All the better if the issue leads to a PR by me or someone else :D


I started an opensource project to solve a problem I was facing at the time. I continue to develop the project alongside another core maintainer. It's a rewarding process. We aren't beholden to any project managers or deadlines - we just hack on what we feel like, when we feel like it.


I used to but the number of projects I use that enforce CLAs is ever increasing and I don't want to run to a lawyer every time I open a PR. My employers have been more than happy for me to contribute but lawyers aren't free (and I haven't worked somewhere with staff lawyers, yet).


I'm planning to release a large part of my self-written tech-stack as Open Source: https://nexusdev.tools/

I write my web apps with Nim on the back-end and Flutter on the front-end. The release will also feature a Python SDK.


Yes, I've been doing it since around 2003-2004. I've never been on any core team or council and tend to go off and come back, but usually stick to a project for a few years (except random drive-by PRs when I found a bug and feel able to solve it without weeks of research).

Why? First of all I like software with less bugs, so that's what I tend to do, all my greenfield development usually happens in my own toy projects. One of the reasons is that I don't have to think about long-term quality and getting it exactly right, like at $dayjob (mostly for architectural decisions, obviously I try to fix the bugs properly...).

A smaller part is also just giving back. I've profited immensely from open source stuff over the last 24ish years, including most of my income in the first years.

That said, I also take extensive breaks. If I don't feel like coding outside of work for a few months, I won't - that's also one of the reasons I am not interested in leading a bigger project, although just doing some releases or merges and bugfixes once in a while is perfectly fine.

I don't think anyone must feel pressured to contribute to the greater open source system, but I absolutely ask any 'bystanders' that they're not entitled to anything, including prompt replies or bugfixes - but if I see that a prolific open source contributor has a problem I might be expediting that issue. (Yes, I might be doing the meritocracy thing wrong :P)

Regarding "at the workplace" - sadly it diverges greatly from employer to employer. I had jobs where there was no question whether I get a day to investigate a bug and properly repro and report it upstream (or do a fix), and others where it was more like "no you can't do that" (and then sometimes I fixed it at night on my own time, but rarely) and many in between. But in my experience it's usually in the company's best interest if the developers understand the things they depend on and have familiarity with the code base, so upstreaming stuff should be a nobrainer... so it has mostly worked out for me.


I do, under pseudonyms. Usually for software I use for personal enjoyment or hobbies.

As long as your work is clean, understandable, and approachable, not having some long-tail back story or 'real identity" is completely fine.


Valid reasons for me are: particular interest in a project, desire to learn a language/technique/framework, genuine and intrinsic interest in a community and the open source movement.


nitpick: 30 or so years later, can we still call Open Source a "movement"?


Yes


the point I'm trying to make is that open source is already the status-quo today. calling it a movement makes it sound like it might not be here to stay. movements come and go but open source is _the_ natural state for a SW to be in. the times when we had to battle Microsoft on ideological grounds on their claims that FOSS is a problem are long gone. Nobody at Microsoft today would claim that FOSS isn't here to stay without getting laughed at by their own colleagues.


Open source / free software and its ethos are more relevant than ever today. Cloud services, automobile software, and IoT devices are just a few examples of how computing is increasingly opaque to end users.


Yes, I have contributed to projects I use in my own time. I do this to make improvements I care about, not because it is something the project has prioritised.


Yes! But I mostly get lost in the landscape. Have tried a few times, but came out confused. May be I am impatient.


I'm not a developer so I focus on translation and localization. Why I do it? Giving back to community :)


Even today when, because if the pandemic, the work in line. I know it is hard to find a team to join or a project seeking help. I dream of the days when the old “bulletin boards” where people used to ask for help to complete a program or join the ongoing project ! John


Like all the time. Whenever I find a bug, I create bug reports and when possible I submit a pr


Usually opensource projects miss something I need at work. So I fork, add code, test it at work and create a pr to upstream so that I don't have to maintain a fork. That's it, really. No touchy-feely stuff.


> I could not just approach my employer and ask if I could help code this open source project.

Way easier to ask for forgiveness than permission. Just do it as long as it’s somewhat relevant to your job.


It's useful to do components independently as open source, to make sure they work in any context, then integrate them into your main project. This makes both of them better products.


"Scratch your own itch" isn't just for starting a company. You can fix a bug in an open source app you use. Or build a small service that solves a problem you have.


Yes by using them thereby giving the developers reason to get out of bed.

More seriously; no. The license gives no warranty for the software, or potential issues I encounter. If the developer would take more professional responsibility there, I might feel like funding or contributing somehow. But if their approach is this is free stuff no strings, my approach is freely take and provide no guarantees in return.


Which is fine but why be so mean about it? Do you have the same attitude to benovalent people in real life?


You inferred a moral judgment where none was intended.

Was it the use of “more”?

Do such folks have some indelible claim to the premise and conclusion and a monopoly on refusing to go further for others?

I did nothing but establish my line in the sand is similar to theirs. If you’re hurt by it, find a therapist.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: