| |
Krill
Registered: Apr 2002
Posts: 2854 |
Closed-source scene tools
This is a bit of a pet peeve of mine, being tickled every now and then.
So, why exactly do we get excellent tools once in a while, but which happen to be closed-source (and often for a specific OS, but that's only a side-issue), subject to inevitable bit-rot once their creators invariably lose interest or worse, among other problems?
My personal head canon says it's likely a combination of
1) being embarrassed of dirty code
2) not wanting other people to take snippets of code (and possibly pass them off as their own)
3) not wanting other people to modify the program to suit their needs (and possibly distribute it)
4) "I'll take my knowledge to the grave, suckers"
List is probably incomplete, but anyways, would like to hear yours' opinions on this. =) |
|
| |
Raistlin
Registered: Mar 2007
Posts: 575 |
Why stop with tools? We should release our source for demos, too, perhaps? I've thought about this many times - and may just do that. What's the best way? Open up the Github repos? ZIP everything up and add to CSDb? Hmm.. |
| |
Fungus
Registered: Sep 2002
Posts: 628 |
Well, I release the source to my tools always. I don't care if it's messy or whatever. I hope someone can get some kind of use out of them regardless.
I think it has to do with ego sometimes, not always.
Sometimes it's lazyness, because people who use github etc often want to be able to build the source and want make files and stuff premade for them and I can see some coders not wanting to bother with that and don't want to deal with the public.
Developing other things myself for different scenes, I am well aware of how some users can be exceptionally annoying, and want their hands held. I don't really see that happening much with the C64 scene. C64 is more a bunch of gatekeepers who don't want anyone "ripping" their code or whatever because of old elitist nonsense. It's still pretty rampant, not just in the c64, but other computer scenes too.
I definitely prefer the John Carmack school of thought there. |
| |
Raistlin
Registered: Mar 2007
Posts: 575 |
https://github.com/RobertTroughton/C64Demo-PublicReleases
The start .. I've added TheDive. Being one of my early (return) demos, it's especially messy and nasty... I might update the folder structure later so that the C++ tool doesn't need to be run in order to build everything else (it spits out binary files that are later linked) - I did this much better on later demos as I got used to working with others (and learning that, actually, not every coder runs with Visual Studio Pro on a Windows PC ;p).
I'll add Delirious 11 and more later.. for group demos I need to get a few permission approvals first of course (at least, where sourcecode is present). |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Quoting RaistlinWhy stop with tools? We should release our source for demos, too, perhaps? I've thought about this many times - and may just do that. What's the best way? Open up the Github repos? ZIP everything up and add to CSDb? Hmm.. An entire repository (including commit history) would be too much to ask for, demo or tool.
Putting a source archive next to the binary release on CSDb is what i've been doing.
And i hope the mention of "Github" was just meant as a synonym for "public browsable repository" or so. =)
But generally having sources to demos is nice (to take a look at how it's done and maybe learn something), but not as important as sources to tools (which really should just work and suit the user's needs).
Released demos are pretty much final by definition, you wouldn't expect someone to fork them and fix or add things. =) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1381 |
I fight internally against (1) every time I make a tool release, but then grit my teeth and put up a source tgz beside the binaries anyway.
There's also a mild element of "ugh, people are going to ask for support about why they can't get the source release to build regardless of whether all the information they need is in the readme or not" but on the other hand at least that way I get to hear from some end users :)
<readme> requires rust 1.37 or higher
<user> it doesn't build
<me> what does rustc -V tell you?
<user> 1.25.1
argh! :D |
| |
JackAsser
Registered: Jun 2002
Posts: 1990 |
Quote: I fight internally against (1) every time I make a tool release, but then grit my teeth and put up a source tgz beside the binaries anyway.
There's also a mild element of "ugh, people are going to ask for support about why they can't get the source release to build regardless of whether all the information they need is in the readme or not" but on the other hand at least that way I get to hear from some end users :)
<readme> requires rust 1.37 or higher
<user> it doesn't build
<me> what does rustc -V tell you?
<user> 1.25.1
argh! :D
Provide a docker image with the tools needed to build. I did that for EotB and also all Booze demos: https://hub.docker.com/r/jackasser/boozify |
| |
Perplex
Registered: Feb 2009
Posts: 254 |
5) "I will release the source code once I've ticked off all points in the TODO list." |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Quoting Perplex5) "I will release the source code once I've ticked off all points in the TODO list." Either a very bad excuse for points 1-4, or a subset of point 1, no? :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1381 |
…depending on whether or not installing Docker is a bigger ask than "install or self-update one compiler" of course… |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Other possible reasons...
1.1) I don't want a flood of suggestions for "why don't you change it this and that way?"
6) What do they need it for? |
... 41 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next |
