Live data from Hacker News

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

live555.com

31–40 of 99 posts

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

#31
post #26

Earlier quoted context omitted.

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").

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.

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...

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

#32
post #30

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 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-…

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.

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

#33
post #28
post #3

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…

> I don't see an issue with this (am I supposed to? Do we demand everyone use git or similar now?). That depends on your job. If you are a software developer, -engineer or similar, I would argue that you should. There are good arguments for version control. - divide & conquer for bugfinding - reconstruction of history - being able to revert back to an older version if/while operations require it - it allows tracking…

Obviously source control has its benefits, but ironically often tarball-only developers produce very high quality software (the most prominent example is djb at cr.yp.to).

Conversely, GitHub is full of low quality software.

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

#34
post #30

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 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-…

> 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!

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

#35
post #33
post #28

Earlier quoted context omitted.

> I don't see an issue with this (am I supposed to? Do we demand everyone use git or similar now?). That depends on your job. If you are a software developer, -engineer or similar, I would argue that you should. There are good arguments for version control. - divide & conquer for bugfinding - reconstruction of history - being able to revert back to an older version if/while operations require it - it allows tracking…

Obviously source control has its benefits, but ironically often tarball-only developers produce very high quality software (the most prominent example is djb at cr.yp.to). Conversely, GitHub is full of low quality software.

You're cherry picking a few example of tarball only developers and then comparing it to the entirety of github? How is that a fair comparison at all?

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

#36
post #27

"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.

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.

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

#37

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 soft…

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.

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

#38
post #28
post #3

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…

> I don't see an issue with this (am I supposed to? Do we demand everyone use git or similar now?). That depends on your job. If you are a software developer, -engineer or similar, I would argue that you should. There are good arguments for version control. - divide & conquer for bugfinding - reconstruction of history - being able to revert back to an older version if/while operations require it - it allows tracking…

It's usual to just put stuff like this in your own version control. Each time you get an update, delete old version, copy new version on top, then sort it out. Perforce has a "Reconcile Offline Work" for exactly this sort of situation; with git or svn, a simple commit will probably do exactly the right thing. This doesn't give you full history, but you get enough to revisit and bisect old versions.

(With a touch more work, you can also maintain your own changes, and have them 3-way merged in automatically.)

As for not using source control - if they don't use it internally, that's a bit weird, but maybe there's just one person working on the code, and they take a backup every hour, and they're happy. (It's their time, not mine.) But not exposing their source control to the outside world is absolutely standard. I worked as a programmer for software companies for ten years and never once saw 3rd-party code distributed any way other than zipped up source drops. (And this includes times where we were working with the 3rd party on the same project! - we just did the thing I mentioned at the start when they sent us updates, and they did the same thing at their end. It's much less of a bother than you'd think, though the first couple of merges can be a bit painful.)

If you want to claim they're being unhelpful, the insistence that you upgrade at a moment's notice is much worse. Upgrading 3rd party libraries is one thing you never, ever want to do, unless your hands are absolutely tied!

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

#39
post #3

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…

The LGPL says no such thing about forcing you to distribute updates but the FAQ implies it does. I wonder how this squares with the part of the GPL that says:

>If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.

Post reply on HN