Ask HN: Is open source ruining your job satisfaction too?

My job is to solve problems, programming is just one tool in my toolbox.

I love to write code but most of the projects can be solved by assembling a few components with some YAML glue and little code. And I use an AI, Github Copilot, to help me doing that.

OpenSource is great for me. The alternative is the enterprise proprietary software with often a "contact us" price tag, which is hell. It takes a while, requires multiple calls to just get a quote, you need to sign legals documents, and then you can see that it's shit. Also, sometimes the price is stupidly too high. With OpenSource you can pull your software containers and start playing immediately.

What you're describing is a lack of engineering in modern software. That's not inherently a bad thing. Arguably a good thing, because we have more problems solved enough to be boxed/canned. But I'm not satisfied with a lot of these boxes/cans, which is why I started rewriting my personal website using completely new techniques based entirely on generic engineering and problem-solving principles [https://novocantico.org/]. My day job is still gluing other software together, but at least I'm able to try to innovate something in my spare time, and open-source it.

I've been programming a long time and I feel the opposite about modern software. Not having to implement your own batch queuing engine, or write your own map software, or struggle to implement the client side of some vendors API is wonderful.

I would say the combination of cloud services and open source means there is no better time to be a developer. You can get things done as a solo developer that would have been impossible 20 years ago: not having to fret over backups and OS versions because your cloud vendor does it in a serverless system is a massive time saver by itself.

If you're struggling to compete with open source packages when you write code, it's a good sign you are writing the wrong code.

It should be obvious though that the very best systems are always boring to work on. The vast majority of software does boring things (ETL or CRUD or security stuff) and there is no way to make it exciting. There is plenty of satisfaction in making it reliable though. Not everyone can work on the exciting stuff, not everyone is suited to working on the exciting stuff either.

Anecdote time:

Once upon a time, I wrote a program to handle email in VB6, it used POP2, SMTP and some crappy logic to decide what to reply. It was a long time ago, when you could still send messages from mickey@disney.com to your friends without worrying about DKIM, juts plain text.

Now I had to make something similar, but the level of security and signatures is insane. Lucky I just glued a few standard libraries in Racket and call it a day. Writing it was much much faster than the old project and I didn't have to study again the difference of HELO and EHLO.

Back to your problem:

Enjoy the new tools. One interesting part of programing is figuring out which libraries to glue to get high level result that is useful. Magician call it "effects" and "method".

Try to get permission to contribute to some of the projects you are using. Explain that it's better that it's merged mainstream instead of keeping a local fork. Choose the one that are interesting to you. Start with small features because you never know if it is not in the vision of the maintainer or if the maintainer is a moron.

> When I've tried to talk to my manager, he's told me we have to think about how maintainable the project is.

Let me guess your packages aren’t up to date either and no one checks if they’re maintained?

Tell your manager when there are no challenges in the job the most skilled people will leave.

> Any code I do write myself eventually gets replaced with another open-source package. Even if the package is worse! When I've tried to talk to my manager, he's told me we have to think about how maintainable the project is.

There's a very strong argument to be made to never reinvent the wheel when building something new. However, if your product is only gluing together packages without doing any work, then the value it can produce is extremely limited. Where is the business logic? Certainly not inside Open Source packages.

There are lots of reasons to use open source packages for your code. Making the code more maintainable isn't one of them. Adding dependencies needs to be considered as a potential future risk, and integrations need to be carefully encapsulated to minimize the risk and allow easy switching later.

If anything, dependencies make your product more brittle, because you are now at the whim of Open Source contributors who may take the package in a direction you don't want, leave unpatched security holes, or abandon the project entirely.

Yes, you can fork the project if that happens, but then you're in the same place you were to start with, maintaining the functionality internally.. except now since no one on your team wrote it originally, you have no expertise on it.

In your situation I would be sorely tempted to look for a new job with a better engineering manager. And with more interesting business cases to build.

There are relatively few technical problems in software, and the easy ones got solved a long time ago and packaged as libraries etc. On the other hand, there are countless business applications for software built on top of these libraries - that's why 99% of us are working on glueing other people's code together in order to provide some business value.

If you don't like that, there are still some paths that are different: low-level embedded development, kernel development, driver development, database engine development etc. They're fairly niche compared to regular business apps development, and I suspect they expect more out of you as well.

Also, I wouldn't blame Opensource, as what you describe does not have anything to do with how the libraries are developed (for profit or FOSS). For example, back in early 2000 there were no good FOSS application servers (a concept from the age of J2EE) and people built their web apps on top of commercial application servers, such as BEA Weblogic or IBM Websphere.

> all I do is edit YAML files (I don't work in DevOps, it's not k8s) and write glue for code that I'm not allowed to write myself

What is this ecosystem where you can declaratively specify your program in YAML? And what are these magical dependencies that let you do this? Is it specific to an industry vertical? Could it be replicated for others?

If there is such a capability, I'd want to get in the business of making the tools rather than the apps.

That quote is taken out of context. I said:

> I've had entire weeks at work where all I do is edit YAML files

Editing config files isn't what I do every day, it's just an example of the consequence of using multiple massive frameworks combined with hundreds of libraries. So much work is done for you that at times you just need to configure everything.

AWS Cloudformation templates with pre-defined lambdas for example.

I'd expect you'd be writing those in typescript on CDK, rather than YAML

I think I kinda agree to certain degree. Would be nice if there is a paying job saying hey here is something figure out how to get an OS running on top of it, how to run C or something else on it, how to move some toolchain, etc. And it's one man's job, not a tiny bit in a huge say compiler team.

But this is not realistic. The best time of programming (80-90) as long gone. Who is the architect engineer for UE5? No one, it has to be a huge team.

Here at croit.io our devs solve real problems and can not just glue together parts. Of course we do use a lot of them, but the major part is R&D. In fact, we have crazy hard topics to solve where most devs come to their limits. If you are looking for a interesting job and have the right skills, send us your CV.

Isn't it awesome to not have to write undifferentiated code? Leaves more time to work on other problems.

Do you mean business logic? Because large parts of that are also farmed out to opensource packages. If someone has implemented it on GitHub, my manager will find it, pull it in, and hack it until it does what is needed.

What can't be done this way is dictated by my manager. I have to implement it as specified in JIRA. There's very little room for creativity.

That just sounds like a bad manager.

why are managers pulling in this code?

"hack it" sounds outside their scope

I feel like this but with cloud services (AWS, Azure) instead of Open Source. They have solved most problems, are cost efficient and easily get buy in from upper management. Developers jobs are then to write configuration and plug things together. Very boring stuff!

Good systems are boring, that's kind of the point. Trying to support some fragile web of home-built infrastructure might seem exciting but long-term it's just frustrating and a massive waste of time.

Maybe work in banking so that you get to create crazy solutions such as bank python? But again the lucky fellows already trampled those green fields...

> What can't be done this way is dictated by my manager. I have to implement it as specified in JIRA. There's very little room for creativity.

This isn't really an open source thing... if you replace it with $TEAM_IN_CHEAP_REGION it's nothing new.

Psychopathic managers just see FOSS as the new team in India, team in China except it costs $0.

One way might be to negotiate some time to contribute to the projects to get features mentioned in the Jira. Then you could code again, get public recogonition and help others.

Learn to (not) code?