12 ms·

Why do you not make the code available under a 'source code repository'?

104 points by jordigh 11y ago

kazinator 11y ago
A source code repository lets me see what bugs you have fixed, and lets me do things like "git bisect" to discover the identity of the commit where you broke something six months ago that wasn't discovered because it's not covered by tests. Helping others find your bugs helps you. Anyone who is serious about any open source project today has a repository. Your bogus rationalizations sound like you haven't held a software job working with other developers in twenty-five years, if ever. Hey, putting tarballs on the sunsite.unc.edu FTP site worked in 1990---why change a process that works? Exposing a version history doesn't imply that you're supporting old baselines. What is or is not supported is declared separately from version control. You cannot stop people from merging their local changes to your upstream by not having a repository. Linux didn't have a repository for years, yet people maintained and shared complex patches outside of the official tree anyway. (And with tools like Quilt, refined that to an art form.) People will take your snapshots, import them on into an upstream branch and do their own ad-hoc version control on your code.
- jordigh 11y ago
  > Your bogus rationalizations sound like you haven't held a software job working with other developers in twenty-five years, if ever. Video codec people are kind of weird as developers. Consider ffmpeg and libav. They're certainly competent, just weird.
  - kazinator 11y ago
    Interesting point, and I happen to have worked with the internals of ffmpeg on the job, so I understand. (I gave it a plugin architecture, supporting dynamically loaded AVParser and AVCodec objects, supporting hardware acceleration.)
  - s73v3r 11y ago
    I dunno. Statements like in the link make me question if someone is actually competent.
    - kbar13 11y ago
      someone's grasp of best practices in vcs is in no way an indicator of their programming or cs abilities
      - czardoz 11y ago
        But it could still be an indicator of competence.
        dvanduzer 11y ago
        To reason about software, it's a useful cognitive tool to be able to simplify gigantic systems down to interfaces and black boxes. Carrying that notion of isolating components too far, such that you don't consider human cooperation as part of the system? It happens often, but we also often distinguish this with statements about EQ versus IQ rather than summing it all up as competence. (Yes, you used the word indicator. I'm speaking to the community more than you specifically.)
- madaxe_again 11y ago
  Think you're correct - this has been his gig for 20 years, before that apple and sun for ~5 years, before that, academia. Either that or he's using VSS and is mortally embarrassed.
  - deleted 11y ago
    [deleted]
- tomjen3 11y ago
  Git bisect is only available for git and (at least) subversion has no comparable command, so unless you are willing to force everybody to use git (and that may not be bad) you aren't guaranteed to get anything useful out of it. Heck git allows you to edit the history pretty widely, right (I have only limited experience with git myself)? So in this case he could maintain a separate upstream repository which only contains the releases, with all the intermediate commits sanitized.
  - nqzero 11y ago
    git bisect automates the process, but the underlying technique should work with any VCS. and i've scripted it up in SVN several times to good effect
    - MaulingMonkey 11y ago
      I've been in situations where I was desperate enough to do it by hand. 20+ builds and manual tests later, I found a really nasty bug in some 3rd party code that manifested with the most bizarre repro that had no obvious connection even in hindsight, and symptoms involving cleanly exit(3)ing out of the program from a totally unrelated bit of code.
    - kazinator 11y ago
      Git has bisect because Torvalds and co. did the same thing outside of version control using kernel tarballs. "Hmm, it still worked in 2.2.13, but not in 2.2.37. Let's try 2.2.25."
  - emeraldd 11y ago
    I know it's svn is just an example but: http://git-scm.com/docs/git-svn http://git-scm.com/docs/git-svn The svn plugin to git let's have a git repo that is a clone /client of an svn repo. Very handy if you have an svn upstream but need to work offline.
  - jeltz 11y ago
    Git, Mercurial, Darcs, Monotone, and Baazar all have a built-in bisect and for svn there are well used external scripts (like svn-bisect).
- schoen 11y ago
  I remember the infrequent releases and not-very-collaborative development from the GNU Project once upon a time -- you get a new release with an announcement on an announce list and availability on the FTP site, a couple of times a year or sometimes less often. And that's about it, because it's the maintainer's responsibility to maintain the code. (Of course, you can contribute patches which the maintainer can accept or reject, and you can fork the program if you want. And some of the projects did have public discussion lists, but not all of them, and not at first.) This is still the way that NetHack development works. :-) It feels like something of an anachronism now, but it highlights the existence of a distinction between free and open source code (you can exercise certain freedoms with respect to any release) and collaborative development (you can potentially help create the release without having a formal relationship with the developers). I know Google has also been criticized around AOSP for being less transparent and collaborative than the present-day norm. Maybe they should defend themselves by comparing themselves to the NetHack Dev Team!
- PopsiclePete 11y ago
  Just look at the website itself... It's straight out of 1995, is it any wonder his views on source control are from 1990?
- un_ 11y ago
  I have a source code repository for the code I write on my computer to track changes, and then I upload tar.xz's of the project for each "release". I can't see much benefit in opening a source code repository; if someone finds a bug, he can e-mail me a patch or even notify me about it. Having a repository where many people can come and open issues puts a burden on my shoulders - I'll look at the page and see that I need to fix <some number> of issues, otherwise I'll look bad, or people will stop using my code. Releasing my code in releases (so that everyone is on one release, or not on any release at all) means that I don't have to deal with people who've cloned the code half-way through the implementation of something large and complained that it won't run, or that it's full of bugs. Releasing releases has been a solid model for me, especially as I work alone, or with a maximum of two or three other people at once. If I was going to use a public repository, I think I'd end up using CVS.
  - shiro 11y ago
    If it's a personal project, it's largely a matter of taste, I think. I did tarball-upload style myself before. I just like to comment that having public repo doesn't necessarily mean you suddenly have to deal with issues piled up by others, although in recent trend repo providers do encourage that kind of open communication (On github, I can turn off issue tracker but I don't know how to turn off pull requests). Even using private repo, you still get bug reports, feature requests and patches via email, or (worse) stumble upon a blog or tweet complaining something isn't working for somebody. The reason I moved to public repo for my projects was that I got tired of dealing with patches manually - sometimes people sent patches against the release which was already fixed in my repo or had conflict with HEAD; sometimes I couldn't reproduce the problem so I had to send provisional patches to the user reported a bug to check out if that would address the issue. With public repo, I could just say "give me a patch against HEAD" or "I push a potential fix on a branch so check it out". It's so much easier. But again, this all depends on what kind of feedback you're getting, or how often your releases are, etc.
  - kazinator 11y ago
    > if someone finds a bug, he can e-mail me a patch or even notify me about it. A source code repository can help someone find a bug more easily, and "preprocess" the bug report with more info for you, like "Hey, you broke such back on December 3, 2014---all you have to do is revert that commit's change to foo.c, and keep the other changes." Users can run "blame" to find out which commit touched what line of any file. Of course, you can debug a flat tarball, but it's sometimes better with the history. Particularly in cases when something previously used to work (users are running into a regression). If all they have is the previous release tarball and the new one, there are too many changes which could be responsible for the breakage. > then I upload tar.xz's of the project for each "release". All I do is push the release's git tag to my public repo, and the CGIT web front end automatically creates .tar.gz, .tar.bz2 and .zip download links for that tag: $ git tag frumly-widgets-2.3 $ git push --tags Done! Users can now download frumly-widgets-2.3.tar.gz straight out of the web front end. > If I was going to use a public repository, I think I'd end up using CVS. Thus, exposing a public version control repo is too uncool for old school, but if you use some unfashionably crappy old version control system, then it's acceptable.
brixon 11y ago
1. It sounds like they do not want outside contributors. 2. They might not use one internally or using something old that does not expose to the internet well.
- bakabaka9 11y ago
  I actually managed to contribute to it once, via the mailing list. This doesn't really invalidate (1), but maybe they just don't want GitHub-style forks ("modifying the supplied code 'in place' is something that we discourage").
  - erikb 11y ago
    It's unavoidable with open source. Take any project with daily tarballs and mailing list diffs and you can probably even code a solution that will transform it to a git repo. Actually a git repo is not that different from a tarball webshare with a shell client for diffs etc.
    - nickpsecurity 11y ago
      You mean in theory it will happen. I think the real question is, "Does it work in practice?" We'd have to look at software like these to see how many got forked versus similar software with repo's and such. My guess: I bet it does work for a good many of them because of developers being too lazy to go through the trouble. If the functionality is useful enough, then it won't work because the maintenance is easier than duplicating their work. Still, I'm not sure of the value in doing this kind of thing. The licensing schemes where you can't use the projects name in derivatives made sense: poor knockoffs can hurt image and adoption. Yet, people not wanting code to be used so easily probably shouldn't be open licensing it in the first place. These people are weird lol...
      - erikb 11y ago
        Of course for small projects it won't happen. But for big ones it happens for sure. And then it doesn't matter if that (or these) repos are by the original author or not. If you can rely on regular updates to that repo then people will use it just as if it would be the original source and will spread just as far as any other repo based FOSS project. So I think for major projects the limitation you can achieve that way is minimal.
howeyc 11y ago
I don't see an issue with this (am I supposed to? Do we demand everyone use git or similar now?). They can give you the source however they want. On another topic, did anyone see the license section? --- If you distribute a product (whether software or hardware; whether free or for pay) that uses the LIVE555 library code, then you must - when requested by either a customer, or Live Networks, Inc. - upgrade it as soon as possible to use the latest version of the LIVE555 library code (or else provide a way for your customers to perform this upgrade themselves). Similarly, you must allow any of your customers to - at their discretion - replace the LIVE555 libraries used by your product with their own version (that uses the same API). (Note that in particular, because Apple restricts which iOS apps are made available on their 'App Store', you cannot use the LIVE555 library code in an iOS app that's distributed through Apple's 'App Store'.) --- Does the LGPL enforce this, or is this some extra requirement?
- 0x0 11y ago
  The user-replaceable part is standard fare, but I've never heard about the forced upgrading part. That sounds pretty crazy. I guess if you follow the LGPL and allow a user to swap out the library you're covered, since they say "or". Maybe it's "LPGL or release updates until you die"?
- earlz 11y ago
  It seems to me that they don't actually WANT anyone to use it, and definitely not modifying the code... Really makes you wonder why they bothered to make it open source and LGPL licensed
  - astrodust 11y ago
    I'd like to think the first part is talking about making extensions to the code, that you should be writing subclasses to add new functionality for your own use, not maintaining a series of patches. That is, dependency injection for your extensions, not alterations to the core. The whole project reeks of anachronistic development practices, though.
  - pc86 11y ago
Roboprog 11y ago
Subclassing for versioning, eh? I remember talking to a friend in the early 90s who was doing that at the company he worked at. I was reading about SCCS at the time, and wanted to convince my management to use that, but couldn't get them away from the "directory tree per release version" method. My next job in the mid 90s used RCS, and I've never worked at a job since that didn't use some kind of version control / archive software. Hard to fathom that some organizations still avoid version/revision control. How do you "undo" to yesterday when you change your mind about something???
- learnstats2 11y ago
  > How do you "undo" to yesterday when you change your mind about something??? One might argue that developer time is valuable enough to ensure that it's spent on things that won't be "undone".
  - deleted 11y ago
    [deleted]
  - faceplanter 11y ago
    That's totally unrealistic. Often it's not the dev. that changes his mind, but the client. And since they have the $$$ you will be "undoing" previous work.
    - nickpsecurity 11y ago
      Exactly. Any good development process and software architecture must be responsive to change without enduring huge problems trying.
  - mgold 11y ago
    What happens when you introduce a bug that isn't discovered for 6 months? What happens if you think of a better way to do something? What happens if you're working on something and the power goes out, leaving you with partially-completed and saved work with no editor history? And so on...
- 11y ago
TerryADavis 11y ago
My operating system has no networking. Moving files in and out is tricky. My files are stored compressed. Every time I update my ISO download file, I generate a syntax highlighted HTML version of all my files and upload. Moving files in-and-out of my operating system is a pain, so I do it all at once whenever I update my ISO. My files can only be compiled my my compiler, so they are of no use outside my operating system. You must boot the ISO to compile. All source files: http://www.templeos.org/Wb/Home/Wb2/LineRep.html#l587 http://www.templeos.org/Wb/Home/Wb2/LineRep.html#l587 All symbols alphabetically: http://www.templeos.org/Wb/Home/Wb2/SymsAlpha.html http://www.templeos.org/Wb/Home/Wb2/SymsAlpha.html All symbols by address: http://www.templeos.org/Wb/Home/Wb2/SymsAddress.html http://www.templeos.org/Wb/Home/Wb2/SymsAddress.html ---- I have a routine that captures a screen shot as a BMP file frame 8 times a second. I can use FFMPEG to convert my hundreds of BMP files into a video. I only support PC Speaker and it will log each freq so you can generate a SND file and FFMPEG can mix the SND into the video. I have a hand-held voice recorder and I can mix that track into it as well. Now, I just use OBR for screencasts. SND quality is not as good, but far more convenient and there is no sync challenge.
Rygu 11y ago
Ugh, what people will do for job security.
erikb 11y ago
Of course there are still people who don't understand what repositories are and how they work. That's really a pity with such a big, well known project, because then others have to do that work for them. (And this kind of project usually has many repos because people don't talk to each other) Example: https://github.com/hackeron/live555 https://github.com/hackeron/live555
hayd 11y ago
"As the software is open source, however, hobbyists are also free to use it, but to post to this mailing list, they are expected to demonstrate at least a minimal level of 'cluefulness' by using an email address with their own domain name - not just a generic "@gmail", "@yahoo", etc.-type email address." Makes sense.
- ksenzee 11y ago
  This assumption, like just about everything on that site, is about 15 years out of date. A whole lot of "clueful" people have given up on running their own mail servers for their personal email accounts. They either use Google Apps, if they want their own domain, or they just use Gmail. The spam problem is too great otherwise.
- tomjen3 11y ago
  Apparently I am no longer a 'clueful' user then. Makes me chokle. Nobody with a clue waste hours setting up their own email server when gmail can do it for you in a few minutes.
  - admax88q 11y ago
    I set up my own email server, and I consider myself to have a clue.
  - hga 11y ago
    I pay Fastmail what's currently going for $40/year for an "Enhanced" personal account that includes using my own personal domain. Having my own domain avoids problems like, oh, Google going mad about true names with Google+ and shutting down my Gmail account.
  - astrodust 11y ago
    I have a Gmail hosted address at a personal domain. Took ten minutes to set up.
  - SoMuchToGrok 11y ago
    Mailgun + Cloudflare + Gmail
efaref 11y ago
The quality of their code looks pretty terrible too. For starters, just look at their genMakefiles script (something of a WTF itself - y u no configure?): https://github.com/hackeron/live555/blob/master/genMakefiles https://github.com/hackeron/live555/blob/master/genMakefiles It should be more like: os=$1 modules="liveMedia groupsock ..." for module in $modules do /bin/rm -f $module/Makefile cat $module/Makefile.head config.$os $module/Makefile.tail > $module/Makefile chmod a-w $module/Makefile done
- chippy 11y ago
  I'm sure they would welcome contributors! I wonder if the classic excuse for not open sourcing software applies here - that the developer is ashamed of their source, that they think it is messy and no one will like it, applies here? Either way, one shouldn't really overtly negatively criticize - it probably wouldn't encourage such a developer if they do have that thought.
  - ossreality 11y ago
    Are you being serious? They intentionally don't host a source repo. What could be more hostile to a potential new developer.
- jff 11y ago
  > y u no configure? Because autoconf is a huge disgusting mess and if you can generate your Makefiles as simply as that, for the love of God DO IT!
- admax88q 11y ago
  That's a pretty weak example to argue that their code quality is poor. They didn't bother to set up a for loop, for only 8 iterations. Their version is still perfectly legible, and you don't have to worry as much about shell argument expansion, which nobody really understands fully.
deleted 11y ago
[deleted]
graycat 11y ago
My experience is that for a software development project of just a few people, for a code repository fairly obvious use of the hierarchical file system on a shared server is just fine.
- s73v3r 11y ago
  No, it isn't. Especially since it's so damn easy to setup a git or mercurial server.
  - VLM 11y ago
    Whats worse is most of the labor saving benefits like rollbacks, bisection, branch/merge all work just fine if you never type git push. Even just "what have I changed so far, oh git status". The client alone has many benefits. Time for old guy rant that in the bad old days I just had a box I could ssh into and that was enough, or should I say, that was better than subversion. Don't forget to init the remote repo before pushing into it, as I forgot seemingly every single time. There was life before gitolite, gitlab, and github.
- plorkyeran 11y ago
  I certainly thought that for a long time. Then I learned how to use version control.
thrillgore 11y ago
Dude's old ass 1994 website and coding practices gave me enough of a cross-section as to who he really is. Lazy.
brillenfux 11y ago
I suddenly don't want to know how the source looks like.
Blackthorn 11y ago
Not really sure I understand the problem here? I'm willing to bet that most people ready to excoriate the developer over their lack of version control will probably never even directly use the library. They are still offering the library as open source in an easily-downloadable form. It is a gift. You can take a gift or you can leave a gift, but you don't whine about how the gift isn't the one you wanted.
- derefr 11y ago
  A "gift" that comes with conditions that obligate you to do work (e.g. upgrading your own code to the newest release of their library whenever they make one) is not usually considered a gift.
vmorgulis 11y ago
AFL "fuzz" is also delivered like that (http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/). It's a smart tool to do fuzzing with a genetic algorithm.
mayoff 11y ago
You are, of course, free to set up your own public source code repository. Many have done so: https://github.com/search?utf8=%E2%9C%93&q=live555 https://github.com/search?utf8=%E2%9C%93&q=live555

104 points by jordigh 11y ago

A source code repository lets me see what bugs you have fixed, and lets me do things like "git bisect" to discover the identity of the commit where you broke something six months ago that wasn't discovered because it's not covered by tests. Helping others find your bugs helps you. Anyone who is serious about any open source project today has a repository. Your bogus rationalizations sound like you haven't held a software job working with other developers in twenty-five years, if ever. Hey, putting tarballs on the sunsite.unc.edu FTP site worked in 1990---why change a process that works? Exposing a version history doesn't imply that you're supporting old baselines. What is or is not supported is declared separately from version control. You cannot stop people from merging their local changes to your upstream by not having a repository. Linux didn't have a repository for years, yet people maintained and shared complex patches outside of the official tree anyway. (And with tools like Quilt, refined that to an art form.) People will take your snapshots, import them on into an upstream branch and do their own ad-hoc version control on your code.

jordigh 11y ago
> Your bogus rationalizations sound like you haven't held a software job working with other developers in twenty-five years, if ever. Video codec people are kind of weird as developers. Consider ffmpeg and libav. They're certainly competent, just weird.
- kazinator 11y ago
  Interesting point, and I happen to have worked with the internals of ffmpeg on the job, so I understand. (I gave it a plugin architecture, supporting dynamically loaded AVParser and AVCodec objects, supporting hardware acceleration.)
- s73v3r 11y ago
  I dunno. Statements like in the link make me question if someone is actually competent.
  - kbar13 11y ago
    someone's grasp of best practices in vcs is in no way an indicator of their programming or cs abilities
    - czardoz 11y ago
      But it could still be an indicator of competence.
      - dvanduzer 11y ago
        To reason about software, it's a useful cognitive tool to be able to simplify gigantic systems down to interfaces and black boxes. Carrying that notion of isolating components too far, such that you don't consider human cooperation as part of the system? It happens often, but we also often distinguish this with statements about EQ versus IQ rather than summing it all up as competence. (Yes, you used the word indicator. I'm speaking to the community more than you specifically.)
madaxe_again 11y ago
Think you're correct - this has been his gig for 20 years, before that apple and sun for ~5 years, before that, academia. Either that or he's using VSS and is mortally embarrassed.
- deleted 11y ago
  [deleted]
tomjen3 11y ago
Git bisect is only available for git and (at least) subversion has no comparable command, so unless you are willing to force everybody to use git (and that may not be bad) you aren't guaranteed to get anything useful out of it. Heck git allows you to edit the history pretty widely, right (I have only limited experience with git myself)? So in this case he could maintain a separate upstream repository which only contains the releases, with all the intermediate commits sanitized.
- nqzero 11y ago
  git bisect automates the process, but the underlying technique should work with any VCS. and i've scripted it up in SVN several times to good effect
  - MaulingMonkey 11y ago
    I've been in situations where I was desperate enough to do it by hand. 20+ builds and manual tests later, I found a really nasty bug in some 3rd party code that manifested with the most bizarre repro that had no obvious connection even in hindsight, and symptoms involving cleanly exit(3)ing out of the program from a totally unrelated bit of code.
  - kazinator 11y ago
    Git has bisect because Torvalds and co. did the same thing outside of version control using kernel tarballs. "Hmm, it still worked in 2.2.13, but not in 2.2.37. Let's try 2.2.25."
- emeraldd 11y ago
  I know it's svn is just an example but: http://git-scm.com/docs/git-svn http://git-scm.com/docs/git-svn The svn plugin to git let's have a git repo that is a clone /client of an svn repo. Very handy if you have an svn upstream but need to work offline.
- jeltz 11y ago
  Git, Mercurial, Darcs, Monotone, and Baazar all have a built-in bisect and for svn there are well used external scripts (like svn-bisect).
schoen 11y ago
I remember the infrequent releases and not-very-collaborative development from the GNU Project once upon a time -- you get a new release with an announcement on an announce list and availability on the FTP site, a couple of times a year or sometimes less often. And that's about it, because it's the maintainer's responsibility to maintain the code. (Of course, you can contribute patches which the maintainer can accept or reject, and you can fork the program if you want. And some of the projects did have public discussion lists, but not all of them, and not at first.) This is still the way that NetHack development works. :-) It feels like something of an anachronism now, but it highlights the existence of a distinction between free and open source code (you can exercise certain freedoms with respect to any release) and collaborative development (you can potentially help create the release without having a formal relationship with the developers). I know Google has also been criticized around AOSP for being less transparent and collaborative than the present-day norm. Maybe they should defend themselves by comparing themselves to the NetHack Dev Team!
PopsiclePete 11y ago
Just look at the website itself... It's straight out of 1995, is it any wonder his views on source control are from 1990?
un_ 11y ago
I have a source code repository for the code I write on my computer to track changes, and then I upload tar.xz's of the project for each "release". I can't see much benefit in opening a source code repository; if someone finds a bug, he can e-mail me a patch or even notify me about it. Having a repository where many people can come and open issues puts a burden on my shoulders - I'll look at the page and see that I need to fix <some number> of issues, otherwise I'll look bad, or people will stop using my code. Releasing my code in releases (so that everyone is on one release, or not on any release at all) means that I don't have to deal with people who've cloned the code half-way through the implementation of something large and complained that it won't run, or that it's full of bugs. Releasing releases has been a solid model for me, especially as I work alone, or with a maximum of two or three other people at once. If I was going to use a public repository, I think I'd end up using CVS.
- shiro 11y ago
  If it's a personal project, it's largely a matter of taste, I think. I did tarball-upload style myself before. I just like to comment that having public repo doesn't necessarily mean you suddenly have to deal with issues piled up by others, although in recent trend repo providers do encourage that kind of open communication (On github, I can turn off issue tracker but I don't know how to turn off pull requests). Even using private repo, you still get bug reports, feature requests and patches via email, or (worse) stumble upon a blog or tweet complaining something isn't working for somebody. The reason I moved to public repo for my projects was that I got tired of dealing with patches manually - sometimes people sent patches against the release which was already fixed in my repo or had conflict with HEAD; sometimes I couldn't reproduce the problem so I had to send provisional patches to the user reported a bug to check out if that would address the issue. With public repo, I could just say "give me a patch against HEAD" or "I push a potential fix on a branch so check it out". It's so much easier. But again, this all depends on what kind of feedback you're getting, or how often your releases are, etc.
- kazinator 11y ago
  > if someone finds a bug, he can e-mail me a patch or even notify me about it. A source code repository can help someone find a bug more easily, and "preprocess" the bug report with more info for you, like "Hey, you broke such back on December 3, 2014---all you have to do is revert that commit's change to foo.c, and keep the other changes." Users can run "blame" to find out which commit touched what line of any file. Of course, you can debug a flat tarball, but it's sometimes better with the history. Particularly in cases when something previously used to work (users are running into a regression). If all they have is the previous release tarball and the new one, there are too many changes which could be responsible for the breakage. > then I upload tar.xz's of the project for each "release". All I do is push the release's git tag to my public repo, and the CGIT web front end automatically creates .tar.gz, .tar.bz2 and .zip download links for that tag: $ git tag frumly-widgets-2.3 $ git push --tags Done! Users can now download frumly-widgets-2.3.tar.gz straight out of the web front end. > If I was going to use a public repository, I think I'd end up using CVS. Thus, exposing a public version control repo is too uncool for old school, but if you use some unfashionably crappy old version control system, then it's acceptable.

brixon 11y ago

1. It sounds like they do not want outside contributors. 2. They might not use one internally or using something old that does not expose to the internet well.

bakabaka9 11y ago
I actually managed to contribute to it once, via the mailing list. This doesn't really invalidate (1), but maybe they just don't want GitHub-style forks ("modifying the supplied code 'in place' is something that we discourage").
- erikb 11y ago
  It's unavoidable with open source. Take any project with daily tarballs and mailing list diffs and you can probably even code a solution that will transform it to a git repo. Actually a git repo is not that different from a tarball webshare with a shell client for diffs etc.
  - nickpsecurity 11y ago
    You mean in theory it will happen. I think the real question is, "Does it work in practice?" We'd have to look at software like these to see how many got forked versus similar software with repo's and such. My guess: I bet it does work for a good many of them because of developers being too lazy to go through the trouble. If the functionality is useful enough, then it won't work because the maintenance is easier than duplicating their work. Still, I'm not sure of the value in doing this kind of thing. The licensing schemes where you can't use the projects name in derivatives made sense: poor knockoffs can hurt image and adoption. Yet, people not wanting code to be used so easily probably shouldn't be open licensing it in the first place. These people are weird lol...
    - erikb 11y ago
      Of course for small projects it won't happen. But for big ones it happens for sure. And then it doesn't matter if that (or these) repos are by the original author or not. If you can rely on regular updates to that repo then people will use it just as if it would be the original source and will spread just as far as any other repo based FOSS project. So I think for major projects the limitation you can achieve that way is minimal.

howeyc 11y ago

I don't see an issue with this (am I supposed to? Do we demand everyone use git or similar now?). They can give you the source however they want. On another topic, did anyone see the license section? --- If you distribute a product (whether software or hardware; whether free or for pay) that uses the LIVE555 library code, then you must - when requested by either a customer, or Live Networks, Inc. - upgrade it as soon as possible to use the latest version of the LIVE555 library code (or else provide a way for your customers to perform this upgrade themselves). Similarly, you must allow any of your customers to - at their discretion - replace the LIVE555 libraries used by your product with their own version (that uses the same API). (Note that in particular, because Apple restricts which iOS apps are made available on their 'App Store', you cannot use the LIVE555 library code in an iOS app that's distributed through Apple's 'App Store'.) --- Does the LGPL enforce this, or is this some extra requirement?

0x0 11y ago
The user-replaceable part is standard fare, but I've never heard about the forced upgrading part. That sounds pretty crazy. I guess if you follow the LGPL and allow a user to swap out the library you're covered, since they say "or". Maybe it's "LPGL or release updates until you die"?
earlz 11y ago
It seems to me that they don't actually WANT anyone to use it, and definitely not modifying the code... Really makes you wonder why they bothered to make it open source and LGPL licensed
- astrodust 11y ago
  I'd like to think the first part is talking about making extensions to the code, that you should be writing subclasses to add new functionality for your own use, not maintaining a series of patches. That is, dependency injection for your extensions, not alterations to the core. The whole project reeks of anachronistic development practices, though.
- pc86 11y ago

Roboprog 11y ago

Subclassing for versioning, eh? I remember talking to a friend in the early 90s who was doing that at the company he worked at. I was reading about SCCS at the time, and wanted to convince my management to use that, but couldn't get them away from the "directory tree per release version" method. My next job in the mid 90s used RCS, and I've never worked at a job since that didn't use some kind of version control / archive software. Hard to fathom that some organizations still avoid version/revision control. How do you "undo" to yesterday when you change your mind about something???

learnstats2 11y ago
> How do you "undo" to yesterday when you change your mind about something??? One might argue that developer time is valuable enough to ensure that it's spent on things that won't be "undone".
- deleted 11y ago
  [deleted]
- faceplanter 11y ago
  That's totally unrealistic. Often it's not the dev. that changes his mind, but the client. And since they have the $$$ you will be "undoing" previous work.
  - nickpsecurity 11y ago
    Exactly. Any good development process and software architecture must be responsive to change without enduring huge problems trying.
- mgold 11y ago
  What happens when you introduce a bug that isn't discovered for 6 months? What happens if you think of a better way to do something? What happens if you're working on something and the power goes out, leaving you with partially-completed and saved work with no editor history? And so on...
11y ago

TerryADavis 11y ago

My operating system has no networking. Moving files in and out is tricky. My files are stored compressed. Every time I update my ISO download file, I generate a syntax highlighted HTML version of all my files and upload. Moving files in-and-out of my operating system is a pain, so I do it all at once whenever I update my ISO. My files can only be compiled my my compiler, so they are of no use outside my operating system. You must boot the ISO to compile. All source files: http://www.templeos.org/Wb/Home/Wb2/LineRep.html#l587 http://www.templeos.org/Wb/Home/Wb2/LineRep.html#l587 All symbols alphabetically: http://www.templeos.org/Wb/Home/Wb2/SymsAlpha.html http://www.templeos.org/Wb/Home/Wb2/SymsAlpha.html All symbols by address: http://www.templeos.org/Wb/Home/Wb2/SymsAddress.html http://www.templeos.org/Wb/Home/Wb2/SymsAddress.html ---- I have a routine that captures a screen shot as a BMP file frame 8 times a second. I can use FFMPEG to convert my hundreds of BMP files into a video. I only support PC Speaker and it will log each freq so you can generate a SND file and FFMPEG can mix the SND into the video. I have a hand-held voice recorder and I can mix that track into it as well. Now, I just use OBR for screencasts. SND quality is not as good, but far more convenient and there is no sync challenge.

Rygu 11y ago

Ugh, what people will do for job security.

erikb 11y ago

Of course there are still people who don't understand what repositories are and how they work. That's really a pity with such a big, well known project, because then others have to do that work for them. (And this kind of project usually has many repos because people don't talk to each other) Example: https://github.com/hackeron/live555 https://github.com/hackeron/live555

hayd 11y ago

"As the software is open source, however, hobbyists are also free to use it, but to post to this mailing list, they are expected to demonstrate at least a minimal level of 'cluefulness' by using an email address with their own domain name - not just a generic "@gmail", "@yahoo", etc.-type email address." Makes sense.

ksenzee 11y ago
This assumption, like just about everything on that site, is about 15 years out of date. A whole lot of "clueful" people have given up on running their own mail servers for their personal email accounts. They either use Google Apps, if they want their own domain, or they just use Gmail. The spam problem is too great otherwise.
tomjen3 11y ago
Apparently I am no longer a 'clueful' user then. Makes me chokle. Nobody with a clue waste hours setting up their own email server when gmail can do it for you in a few minutes.
- admax88q 11y ago
  I set up my own email server, and I consider myself to have a clue.
- hga 11y ago
  I pay Fastmail what's currently going for $40/year for an "Enhanced" personal account that includes using my own personal domain. Having my own domain avoids problems like, oh, Google going mad about true names with Google+ and shutting down my Gmail account.
- astrodust 11y ago
  I have a Gmail hosted address at a personal domain. Took ten minutes to set up.
- SoMuchToGrok 11y ago
  Mailgun + Cloudflare + Gmail

efaref 11y ago

The quality of their code looks pretty terrible too. For starters, just look at their genMakefiles script (something of a WTF itself - y u no configure?): https://github.com/hackeron/live555/blob/master/genMakefiles https://github.com/hackeron/live555/blob/master/genMakefiles It should be more like: os=$1 modules="liveMedia groupsock ..." for module in $modules do /bin/rm -f $module/Makefile cat $module/Makefile.head config.$os $module/Makefile.tail > $module/Makefile chmod a-w $module/Makefile done

chippy 11y ago
I'm sure they would welcome contributors! I wonder if the classic excuse for not open sourcing software applies here - that the developer is ashamed of their source, that they think it is messy and no one will like it, applies here? Either way, one shouldn't really overtly negatively criticize - it probably wouldn't encourage such a developer if they do have that thought.
- ossreality 11y ago
  Are you being serious? They intentionally don't host a source repo. What could be more hostile to a potential new developer.
jff 11y ago
> y u no configure? Because autoconf is a huge disgusting mess and if you can generate your Makefiles as simply as that, for the love of God DO IT!
admax88q 11y ago
That's a pretty weak example to argue that their code quality is poor. They didn't bother to set up a for loop, for only 8 iterations. Their version is still perfectly legible, and you don't have to worry as much about shell argument expansion, which nobody really understands fully.

deleted 11y ago

[deleted]

graycat 11y ago

My experience is that for a software development project of just a few people, for a code repository fairly obvious use of the hierarchical file system on a shared server is just fine.

s73v3r 11y ago
No, it isn't. Especially since it's so damn easy to setup a git or mercurial server.
- VLM 11y ago
  Whats worse is most of the labor saving benefits like rollbacks, bisection, branch/merge all work just fine if you never type git push. Even just "what have I changed so far, oh git status". The client alone has many benefits. Time for old guy rant that in the bad old days I just had a box I could ssh into and that was enough, or should I say, that was better than subversion. Don't forget to init the remote repo before pushing into it, as I forgot seemingly every single time. There was life before gitolite, gitlab, and github.
plorkyeran 11y ago
I certainly thought that for a long time. Then I learned how to use version control.

thrillgore 11y ago

Dude's old ass 1994 website and coding practices gave me enough of a cross-section as to who he really is. Lazy.

brillenfux 11y ago

I suddenly don't want to know how the source looks like.

Blackthorn 11y ago

Not really sure I understand the problem here? I'm willing to bet that most people ready to excoriate the developer over their lack of version control will probably never even directly use the library. They are still offering the library as open source in an easily-downloadable form. It is a gift. You can take a gift or you can leave a gift, but you don't whine about how the gift isn't the one you wanted.

derefr 11y ago
A "gift" that comes with conditions that obligate you to do work (e.g. upgrading your own code to the newest release of their library whenever they make one) is not usually considered a gift.

vmorgulis 11y ago

AFL "fuzz" is also delivered like that (http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/). It's a smart tool to do fuzzing with a genetic algorithm.

mayoff 11y ago

You are, of course, free to set up your own public source code repository. Many have done so: https://github.com/search?utf8=%E2%9C%93&q=live555 https://github.com/search?utf8=%E2%9C%93&q=live555