4 ms·

I get what you're saying but I only like to release to the public something that actually works. Sometimes when I have just hacked something together it is ful

I get what you're saying but I only like to release to the public something that actually works. Sometimes when I have just hacked something together it is full of hardcoded paths for my local system as I never planned for it to be anything more. I made the mistake once of putting some code up that was full of machine specific and OS install specific stuff as several people asked. I ended up getting a tonne of emails moaning at me for "releasing" something that doesn't work for them. They didn't want to have to figure out every little hardcoded hack and demanded I fix it. Often very rudely. That's the problem with "working on it in public" when it doesn't actually work anywhere other than your dev machine. People don't see it as a 'work in progress' and so will bitch and moan when it doesn't build for them. And trust me developer users can be even worse than normal users as not only do they bitch about something not working then will often resort to name calling and such about the quality of the code. Sure many understand it was a weekend hack project but there are always a few that will really pull you down and not everyone can handle such personal attacks when all they are trying to do is share some code for something they think is cool.

dTal 5y ago
They're releasing binaries, so presumably it does work.
- mattowen_uk 5y ago
  I have plenty of utilities that I've written over the years that work perfectly on my machine, but I know they'll probably fail on some else's due to hardcoded file paths and assumptions as to what libraries are installed. The thing is, there's a big difference between writing something for your use case, and writing something for others.
  - dTal 5y ago
    Uh huh, and did you release binaries of those utilities for public consumption?
    - mattowen_uk 5y ago
      Nope. Because as I said, they wouldn't work, due to the hardcoded file paths etc. Expanding on this further - I have a few apps I've written out there in the wild, and for one (which also found it's way onto a magazine cover CD-ROM back in the day) I had immense pressure to open source it, so against my better judgement I did. I then had to endure lots of negative feedback about the quality of my code. The whole experience put me off going open-source ever again[1]. I am a hobbyist coder, and my code quality will never be 'up there' with the professionals, but the moment you release something (even for free) people expect it to be perfect, which is unrealistic. --- [1] Not quite true, I do have a GitHub with a few tiny repos, but nothing important.
- satysin 5y ago
  The compilation works on their system to produce a binary sure but that doesn't mean he can just upload the source tree and it will work for anyone else out of the box. When I talk about releasing something that "actually works" (as I put it) I mean a simple git clone, make, make install (or equivalent). Not having to include a readme that explains you need to search and replace the files to remove hardcoded paths, install some old library because my machine wasn't up to date and it doesn't compile with the latest version as I was lazy and hardcoded specific version numbers in places for things as something else didn't work and I didn't want to spend half an hour trying to find some old Windows 2000 DLL, etc. I am guessing based on my own experience here but developing plugins for Visual C++ 6 on Windows 2000 is a bit of a pain in the ass in 2021. It was a pain in the ass back in the early 2000s when I had access to everything on MSDN. Sure you could make the point that this tool is designed for people using VC++6 so they must have a copy of that but they may not have any other ancient libraries this tool is built with which is often the biggest obstacle when working with old proprietary software like this. I support the authors decision to keep things to themselves until they have been able to tidy it up then release something that is easier to build so they're not overwhelmed with "the build isn't working as it says I need x.y.z" issues.
xg15 5y ago
> Sometimes when I have just hacked something together it is full of hardcoded paths for my local system as I never planned for it to be anything more. Apart from everything else you said, publishing local path could also pose a security risk.

dTal 5y ago

They're releasing binaries, so presumably it does work.

mattowen_uk 5y ago
I have plenty of utilities that I've written over the years that work perfectly on my machine, but I know they'll probably fail on some else's due to hardcoded file paths and assumptions as to what libraries are installed. The thing is, there's a big difference between writing something for your use case, and writing something for others.
- dTal 5y ago
  Uh huh, and did you release binaries of those utilities for public consumption?
  - mattowen_uk 5y ago
    Nope. Because as I said, they wouldn't work, due to the hardcoded file paths etc. Expanding on this further - I have a few apps I've written out there in the wild, and for one (which also found it's way onto a magazine cover CD-ROM back in the day) I had immense pressure to open source it, so against my better judgement I did. I then had to endure lots of negative feedback about the quality of my code. The whole experience put me off going open-source ever again[1]. I am a hobbyist coder, and my code quality will never be 'up there' with the professionals, but the moment you release something (even for free) people expect it to be perfect, which is unrealistic. --- [1] Not quite true, I do have a GitHub with a few tiny repos, but nothing important.
satysin 5y ago
The compilation works on their system to produce a binary sure but that doesn't mean he can just upload the source tree and it will work for anyone else out of the box. When I talk about releasing something that "actually works" (as I put it) I mean a simple git clone, make, make install (or equivalent). Not having to include a readme that explains you need to search and replace the files to remove hardcoded paths, install some old library because my machine wasn't up to date and it doesn't compile with the latest version as I was lazy and hardcoded specific version numbers in places for things as something else didn't work and I didn't want to spend half an hour trying to find some old Windows 2000 DLL, etc. I am guessing based on my own experience here but developing plugins for Visual C++ 6 on Windows 2000 is a bit of a pain in the ass in 2021. It was a pain in the ass back in the early 2000s when I had access to everything on MSDN. Sure you could make the point that this tool is designed for people using VC++6 so they must have a copy of that but they may not have any other ancient libraries this tool is built with which is often the biggest obstacle when working with old proprietary software like this. I support the authors decision to keep things to themselves until they have been able to tidy it up then release something that is easier to build so they're not overwhelmed with "the build isn't working as it says I need x.y.z" issues.

xg15 5y ago

> Sometimes when I have just hacked something together it is full of hardcoded paths for my local system as I never planned for it to be anything more. Apart from everything else you said, publishing local path could also pose a security risk.