| |
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: 629 |
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? |
| |
Raistlin
Registered: Mar 2007
Posts: 575 |
I've dropped sourcecode for Delirious 11 (really damn awful code!), X Marks the Spot (urgh!), The Dive (meh) and Memento Mori (not bad ;p) onto Github, https://github.com/RobertTroughton/C64Demo-PublicReleases , and I've added ZIPs to each of the releases.
Flame on, coders, flame on ;p |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Quoting Cruzer6) What do they need it for? If you release a tool, obviously you expect people to use it, no?
And if you refer to the source, well, see my point about preventing bit-rot. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
@Krill: Agree. I was just trying to guesstimate why some tool coders don't want to release their source.
@Raistlin: Great job! I should do the same. |
| |
spider-j
Registered: Oct 2004
Posts: 449 |
Yep, it's always a pity when things get lost on the way, because people think source release is not necessary. Warpcopy comes to mind: Warpcopy II V0.1 alpha 3
But I feel in the last years things have been changing to the better with many tools being released including source or even public repositories.
That said @Burglar if you're reading this: please switch your png2prg repository to public or add source code snapshots to your releases. I really don't want this great tool to be lost. |
| |
Slator
Registered: Jan 2002
Posts: 273 |
Quote: Yep, it's always a pity when things get lost on the way, because people think source release is not necessary. Warpcopy comes to mind: Warpcopy II V0.1 alpha 3
But I feel in the last years things have been changing to the better with many tools being released including source or even public repositories.
That said @Burglar if you're reading this: please switch your png2prg repository to public or add source code snapshots to your releases. I really don't want this great tool to be lost.
well speaking about warpcopy, Graham lost his harddrive due to a crash back ages ago and only had old sources saved.
A pity, but I would rather have graham back than this source... |
| |
Street Tuff
Registered: Feb 2002
Posts: 88 |
When it comes to Demos you probably need some KRAWALL!!!
https://bitbucket.org/streetuff/workspace/repositories/
(Links are in the comments for those 2 demos since release)
Misery 3 (DTV) Source Misery 3 (source linked to the release)
Tunnelscheisse Tunnelscheisse (source linked to the release)
Kind regards
Tuff |
| |
Boogaloo
Registered: Aug 2019
Posts: 21 |
Quote: 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?
I would rather say that 1.1 is one of the really good reasons to publish the source. Then you can reply "do it yourself, the source is public". |
| |
mankeli
Registered: Oct 2010
Posts: 110 |
Aren't all programs open source if you know machine language? ;) |
| |
Six
Registered: Apr 2002
Posts: 287 |
I get why people are hesitant. You put the time and effort into creating something, release the thing source and all, then come back a few months later to find someone's lifted it, reworked it a little bit, promoted the hell out of themselves, and is now applauded as the genius "inventor" of the thing. Years later your original version of the thing is routinely dismissed as somehow a derivative of theirs. I'd imagine the "everyone's a celebrity" era is probably producting *more*, not *less* of these experiences.
But... it's important to set those individual frustrations aside and consider what's best for the community as a whole - and that's open source everything. |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Quoting SixI get why people are hesitant. You put the time and effort into creating something, release the thing source and all, then come back a few months later to find someone's lifted it, reworked it a little bit, promoted the hell out of themselves, and is now applauded as the genius "inventor" of the thing. Years later your original version of the thing is routinely dismissed as somehow a derivative of theirs. I'd imagine the "everyone's a celebrity" era is probably producting *more*, not *less* of these experiences. Do you speak out of personal experience?
Because really, once you properly put out source publically etc., you have prior art and attribution and all, which you can point to.
Some fuckwits may ignore your licence, but that should be an exception and not the norm. |
| |
mankeli
Registered: Oct 2010
Posts: 110 |
I think what six is referring to, is somewhat orthogonal to the copyleft licenses.
Copyleft licenses are designed to force companies to give back something to the open source community, in case they would like to sell/spread your software in binary form.
What six is mentioning, feels to me more primal. It's the feeling when you see someone getting praise from the audience, even if they are just rehashing work by others. Probably the same that makes the demoscene somewhat allergic on using commercial game engines. Copyleft licenses can't help with that.
It's kinda interesting (historically) how the copyleft licenses were originally an American invention, building on the long-established Unix world. (Remember that companies like Microsoft actually INVENTED the fact that you can even ask money for a software!) But the demoscene was more about just cracking and spreading commercial software, and the hobbyist utilities got spread similarly. As with the commercial wares, hobbyist tools got disassembled, hacked and improved and spread as well. There's a kind of "unwritten law" in the demoscene about this, like how SID music can be just used in whatever productions, as long as they are "within the scene". Maybe. :)
(unrelated note: grr, had to wrote this post the second time, because I forgot to copy it to clipboard before clicking submit, as csdb tends to sometime just go into this weird state where it just discards the post, and if you click back button, the text input field is empty) |
| |
trident
Registered: May 2002
Posts: 76 |
Quote: I get why people are hesitant. You put the time and effort into creating something, release the thing source and all, then come back a few months later to find someone's lifted it, reworked it a little bit, promoted the hell out of themselves, and is now applauded as the genius "inventor" of the thing. Years later your original version of the thing is routinely dismissed as somehow a derivative of theirs. I'd imagine the "everyone's a celebrity" era is probably producting *more*, not *less* of these experiences.
But... it's important to set those individual frustrations aside and consider what's best for the community as a whole - and that's open source everything.
in my experience, it is completely the other way around: the original author tends to get way more credit than anyone that continue working on the software.
this happens both when someone takes over as maintainer or developer of an existing project or if someone tries to actively "steal" the limelight. the original author usually keeps getting credit for the software, year after year.
so i'm not refuting your comment (i agree that this fear may cause people to avoid releasing software as open source), i'm just providing additional support for your conclusion. |
| |
Burglar
Registered: Dec 2004
Posts: 1047 |
Quoting spider-jThat said @Burglar if you're reading this: please switch your png2prg repository to public or add source code snapshots to your releases. I really don't want this great tool to be lost. thanks :) and no worries spider, will publish sources in the mid term, it is planned.
for me, keeping source closed is primarily a pride thing. I want people to see my sources and say, "oh nice, I totally understand what's going on and I can totally use this in my own projects".
since my c64 related tools tend to grow organically and I learn the language as I go, lots of bad decisions are made.
refactor time vs new features vs available time vs pride.
my published sources can be found here btw: https://github.com/staD020/ |
| |
Fungus
Registered: Sep 2002
Posts: 629 |
I appreciate things like demo and intro sources as I just don't know how a lot of stuff is done and it's easier to understand than trying to reverse engineer it. Especially stuff with math that I'm admittedly not very good at.
I can identify with what Six said... I've had people accuse me of stealing their "ideas" for fixing bugs in games, when the bugs are publicly known, or even have fixed them years before they were even around before and updated the fix to use more modern code or functions. It's a very off putting thing.
Burglar, that reminds me of the vertical sprite bar intro you made you wanted me to fix, and even with the source code I couldn't figure out what you were doing! Hah. |
| |
spider-j
Registered: Oct 2004
Posts: 449 |
Quoting Burglarfor me, keeping source closed is primarily a pride thing. I want people to see my sources and say, "oh nice, I totally understand what's going on and I can totally use this in my own projects".
I can understand that. I also usually start my projects repositories on a private git on my local server and only switch to a public github repository once I find my code somewhat "readable" for others.
But I think readability is not only about how "clean" the code is, but also how similar your own coding style is to the one you're looking at. I.e. I have no doubt that the loader code by Krill is presented in a good, clean coding style, but I do understand almost nothing when I look at it. On the other hand I have zero problems to understand any code written by Bitbreaker.
In those cases it might even start with the choice of assembler beeing used: ca65, which I don't use vs. acme, which I do use.
Even in my day to day job where I usually have to write extensions to Open Source software there are packages where it's super easy for me to work with and understand their internal workflow and in which case to use which API and other packages where everything seems a confusing mess to me but may be completely transparent for someone else.
So I guess you can't really expect your own code beeing perfectly readable for "everyone". |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Quoting spider-jI.e. I have no doubt that the loader code by Krill is presented in a good, clean coding style, but I do understand almost nothing when I look at it. On the other hand I have zero problems to understand any code written by Bitbreaker. Please, i do and did not only write loaders (and release the sources). :)
Anyways, do you also directly understand Bitfire's source code when looking at it?
Ultimately, the main point is not that anyone looking into released sources can understand them, but that the tools can be built from them and the code be changed and enhanced by anyone (understanding it).
And i was mostly referring to tools for modern platforms in the OP. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11146 |
And then someone invents toggleplexing and you guys don't appreciate his work :( |
| |
Stone
Registered: Oct 2006
Posts: 170 |
Quoting chatGPZAnd then someone invents toggleplexing and you guys don't appreciate his work :(
"If you take the life-lie from an average man, you take away his happiness as well" - Henrik Ibsen / The Wild Duck |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1381 |
If only the toggleplexer had released source :'( |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Please stay on topic, and that's sources to neither demos nor games nor anything 6502, actually. =) |
| |
spider-j
Registered: Oct 2004
Posts: 449 |
Quoting KrillPlease, i do and did not only write loaders (and release the sources). :)
I know, but I can only talk about things I have actually looked at :-)
Quoting KrillAnyways, do you also directly understand Bitfire's source code when looking at it?
No of course not. But still his general "style" is closer to what I'm used to what makes it way easier to work through.
Quoting KrillUltimately, the main point is not that anyone looking into released sources can understand them, but that the tools can be built from them and the code be changed and enhanced by anyone (understanding it).
Yes, but one of Burglars argument for keeping his sources closed (at least for some time) was the own set standard that you want your code to be somewhat "good", "readable" etc. before you release it to the public.
And I just wanted to say, that this is difficult to decide. Because what's easy readable and adaptable for one must not be for the other (doesn't really matter which kind of software or language). So these thoughts maybe shouldn't hinder you to release your sources.
Oh, and I thought the focus of the topic was more on the "why keep stuff closed source?" side in general (extending your initial 4 points) than on the specifically "speaking about C64 crossdev PC tools" side :-) |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Quoting spider-j
Quoting KrillAnyways, do you also directly understand Bitfire's source code when looking at it?
No of course not. But still his general "style" is closer to what I'm used to what makes it way easier to work through.
I see. But what makes my loader code somewhat less readable is perhaps the fact that it is a multi-platform project (C-64, C-128, Plus/4, might add PET at some point) and highly configurable.
This makes for a lot of pseudo-code-like macro action. =)
It's not representative of my style of C-64 only coding. (The respective drive-side portions are, though, but they also have some config-induced macro shit.)
Quoting spider-jSo these thoughts maybe shouldn't hinder you to release your sources. Indeed they shouldn't. Most people never really look at the source, until they must for some reason or other. Most important is that it works, precious snowflake developer egos be damned. :D
Quoting spider-jOh, and I thought the focus of the topic was more on the "why keep stuff closed source?" side in general (extending your initial 4 points) than on the specifically "speaking about C64 crossdev PC tools" side :-) Have you not noticed "tools" right in the thread title, and "often for a specific OS" in the OP body? ;) |
| |
spider-j
Registered: Oct 2004
Posts: 449 |
Quoting Krilland "often for a specific OS" in the OP body? ;)
Okay, I see that probably refers to the OS linux users don't dare to speak / write out in public ;-P
User send me his some of his C# / .NET sources [EDIT: of his *tools*!] once and I must admit I could not make much sense of it, beeing completely driven by events attached to Windows forms. After I saw that I could understand why he didn't put the sourcecode out. Although from what I understood you can actually achieve a similar "form driven" style when using Mono.
So his argument was like: nobody would want to port that anyway and the project is kind of "finished" – nothing to add. |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Quoting spider-jQuoting Krilland "often for a specific OS" in the OP body? ;)
Okay, I see that probably refers to the OS linux users don't dare to speak / write out in public ;-P Sure, in practice it's Windows, but the main point is "some other OS". =)
(I do have the big 3 here, but Linux is the daily driver.)
Quoting spider-jSo his argument was like: nobody would want to port that anyway and the project is kind of "finished" – nothing to add. No program but the most trivial is bug-free. :)
And at some point it will be much easier to port it to whatever Microsoft will come up with next rather than setting up some virtual machine or whatnot just for that tool. =) |
| |
tlr
Registered: Sep 2003
Posts: 1724 |
Quoting KrillAnd at some point it will be much easier to port it to whatever Microsoft will come up with next rather than setting up some virtual machine or whatnot just for that tool. =)
There is always the Python support in Excel. :)
Maybe they've run out of NIH? |
| |
TheRyk
Registered: Mar 2009
Posts: 2084 |
Quoting Krill...
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. =)
To begin with, my humble native C64 stuff (I don't do other platform stuff) ain't "excellent" at all, but there are a few things people would like me to publish the source of, along with some comprehensible comments.
Otherwise, guilty as charged...
... in 1) especially some years ago I was often well aware that in spite of all optimizing, some stuff remained spaghetti and still was full of redundant stuff. And apart from that, even I sometimes don't understand my own comments if stuff is old or was coded and (not) commented after +10 drinks.
... combined with 3) Actually this is stupid, as sharing is caring. However, in the few cases I was asked for sources, I sometimes denied for the reason I still had vague plans to optimize stuff myself before, not just to feel less embarrassed (1) but also some stupid emotional connection, seeing the code as my baby. As I said, stupid, for often, the plans of working on it again myself didn't work out for years, and meanwhile someone else could have used and improved the stuff so I could take it from my to-do-pile :) |
| |
Fungus
Registered: Sep 2002
Posts: 629 |
For once I stayed on topic mostly, yes I was speaking of tools for PC that are on github, not for C64 at all though.
But my feelings also extend to whatever platform I'm working on. I don't see any difference. |
| |
Raistlin
Registered: Mar 2007
Posts: 575 |
Quote: For once I stayed on topic mostly, yes I was speaking of tools for PC that are on github, not for C64 at all though.
But my feelings also extend to whatever platform I'm working on. I don't see any difference.
This. Open source everything IMO. Not just about the platforms. |
| |
spider-j
Registered: Oct 2004
Posts: 449 |
Quoting KrillNo program but the most trivial is bug-free. :)
And at some point it will be much easier to port it to whatever Microsoft will come up with next rather than setting up some virtual machine or whatnot just for that tool. =)
I guess it goes like this (from the coders perspective): I want a quick solution to problem X. I code a little tool with the least effort. If it is important to others it will be superseeded anyway soon, if not and it turns out to be important to me only then there is no use of sharing the source.
Back again to I = spider I (eieiei) assume it also has to do with how "big" your tool is. At least from what I can tell it seems the bigger the project the more likely it is that it will be
1.) ported to more platforms by the coder itself
2.) released as source code.
Looking the other way around: I did release some "mini" tools as source and even tried* to provide at least a win binary. Mac is a completely different story because I don't even know if you can compile anything for Mac without having an dev account (?) *shrug*
*often times I really don't know for sure if my win binaries do run on a real windows, because I just test then in WINE.
Taking https://github.com/jansalleine/diffscgen as an example I guess noone other than me has ever used it – and of course even less likely looked at the source. So I feel I could have released it as linux binary only and nobody would care. The decision to release source instead of binary only is more because it's the "natural" linux way. If I were using Windows I may think different.
Of course I could be totally wrong with my assumptions. But I do think that those assumptions play a big role in why people decide not to bother about other platforms or releasing the source. Because they feel what they are doing has very little value to others anyway. |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Quoting spider-jBecause they feel what they are doing has very little value to others anyway. Then again, if you deem your tool release-worthy, then why not simply release the source along with it.
(Oh, and you can compile stuff on MacOS perfectly fine without a dev account. At least i could last time i tried.) |
| |
spider-j
Registered: Oct 2004
Posts: 449 |
Quoting KrillThen again, if you deem your tool release-worthy, then why not simply release the source along with it.
Depends on what "release-worthy" means to you personally. If it's a case like I described it's probably "I don't think many will use it, but it maybe of use for $someone so I'll just upload". And then you just release in the way what your OS' "standard" way is. Meaning: when you're using Windows you will most likely just release a binary and when you're using Linux you will most likely just release the source.
(OT: good to know about Mac. I'm so far away from those proprietary OSes that I just don't know what to do if I can't just gcc in the terminal. I half assed tried to read into Mac stuff and very soon stumbled into this: you need dev-kit-xyz from apple and register to compile stuff. My motivation for sure was not big enough*.)
and back on topic with refering to *: I think it will be the same if you're used to just put binaries out – you're just not motivated to release as source, because you feel then you'd eventually have to provide solutions how to build. Even on linux I sometimes think: when it's more complicated than just gcc or simple make (only utilising well supported shell commands and gcc or g++ max) then it's really tedious work to write a readme that lists all prerequisites.
So in that case as a linux user, you'll probably release it as source anyway. But if you're on Windows. Probably not. |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Quoting spider-jAnd then you just release in the way what your OS' "standard" way is. Meaning: when you're using Windows you will most likely just release a binary and when you're using Linux you will most likely just release the source. Hmm, so does this make for another point: "ignorance"? :)
Quoting spider-jyou're just not motivated to release as source, because you feel then you'd eventually have to provide solutions how to build. Even on linux I sometimes think: when it's more complicated than just gcc or simple make (only utilising well supported shell commands and gcc or g++ max) then it's really tedious work to write a readme that lists all prerequisites. I dunno, this seems like a lame excuse or rather moot to me.
You can just plainly write somewhere that support requests will be ignored, or something.
And if you're swamped with support requests, your tool seems more popular than you'd ever have imagined, after all, and may be worth the effort to clean up the code, or (the more likely case),
you're just getting some cry for help every now and then - which you can just continue to ignore. :) |
| |
ws
Registered: Apr 2012
Posts: 229 |
For some of my stuff i put out sourcecode in the past, just to see what happens. That took quite some work to make the package release-ready. I bet nobody is up for a nightmarish read, though.
Also i agree with what spider said: from my personal experience with it, i am guessing most people just don't care for doing the extra work of having a (well documented) sourcecode that could be compiled elsewhere (meaning, anywhere but my own very delicate, very bunged up system setup).
And what's a sourcecode worth that has a multitude of unexplained dependencies? Also what if i had some drunk texts to myself in there that i missed, or even features that i actually don't want anybody to know about?
So my belief is, the major reason for not releasing the sources is along the lines "watch me not care" and "binary relased, archive, forget".
(Tbh., i hadn't even spent a single thought on releasing the source to Trajed until Krill asked me to.) |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Quoting wsi am guessing most people just don't care for doing the extra work of having a (well documented) sourcecode that could be compiled elsewhere (meaning, anywhere but my own very delicate, very bunged up system setup).
And what's a sourcecode worth that has a multitude of unexplained dependencies? As long as the actual business core logic (the value-adding stuff built on top of random dependencies) is intact (complete), all the other things can be fixed. So again, this kind of dirtiness shouldn't prevent releasing source code.
Quoting wsAlso what if i had some drunk texts to myself in there that i missed, or even features that i actually don't want anybody to know about? And that kind of dirtiness, oh my... i don't even |
| |
Stone
Registered: Oct 2006
Posts: 170 |
For me I guess 1) has been the primary obstacle, but also the fear of being swamped in support requests. More often than not I'm already bored with developing the tool once it's functional and even when I have ideas of how to improve it, I know further work just won't be pleasurable for me.
Contrary to my fears, people have in most cases stepped forward and taken the project further by contributing code which makes me not feel as guilty about abandoning it. This goes especially for SIDBlaster USB driver BETA but also for SIDdecompiler V0.5 |
| |
TheRyk
Registered: Mar 2009
Posts: 2084 |
Quoting ws... some drunk texts to myself ...
made my day =D |
| |
Bitbreaker
Registered: Oct 2002
Posts: 501 |
We in Performers also decided to go public now as raistlin did as a good example. So no reasons and excuses 1-4 here :-)
All the source for Next Level can be found here from now on :-) Enjoy reading, admiring, drooling, laughing, ... :-D
https://github.com/bboxy/next-level |
| |
Raistlin
Registered: Mar 2007
Posts: 575 |
Great work, Bitbreaker!
We should split off a new thread for open-source demo stuff :-) .. so we can stop annoying Krill :-) |
| |
ΛΛdZ
Registered: Jul 2005
Posts: 153 |
HO added some of his source code to be downloaded here:
https://csdb.dk/release/?id=17637&show=notes#notes |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
What Raistlin said. |
| |
Fungus
Registered: Sep 2002
Posts: 629 |
Well here is another one for you Krill.
EA Fat Tracks File Buster 2.0 |
