
Why do you not make the code available under a 'source code repository'? - jordigh
http://www.live555.com/liveMedia/faq.html#no-source-code-repository
======
kazinator
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.

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

------
howeyc
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?

~~~
zeeed
> 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 of changes over time \- it is the best way of understanding what
changed since the last version (for people actually using the library) \-
finding complex faults \- branching and merging (but the author is opposed to
this)

So, well, what concerns live555, IMHO it's a huge red flag for people
considering to actually use the library. When it comes to "not seeing an issue
with not using source control", I believe that one can state without a doubt
that it is a good and proven practice.

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

~~~
geofft
djb's software is pretty low-quality for very many metrics of "quality". Lots
of it is not elegantly interoperable with existing UNIX systems, because he
has his own idea of how UNIX systems should work. There's the entire qmail
backscatter thing. There are pieces of crypto code written in a _custom_
assembler. Curve25519 has its own reimplementation from Chrome's Adam Langley,
and all of NaCl its own repackaging in the form of the libsodium project,
because the official distributions are difficult to use. NaCl has been
promising certain features in the "next release" for years (notably Ed25519
signatures), but no release has been seen. All the downloads are over
plaintext HTTP with no cryptographic signatures: I've always interpreted this
as implying that if you're not qualified to audit the entire tarball you
downloaded, the software isn't for you.

None of this is to claim that he's a bad _cryptographer_ , or even a bad
_software engineer_. But pure code output is far from the only important
metric for software. GitHub makes it easy to do _release engineering_ well, or
to let other people help you with that if it's not your forte. (libsodium, for
instance, is on GitHub.)

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

~~~
faceplanter
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
Exactly. Any good development process and software architecture must be
responsive to change without enduring huge problems trying.

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

------
erikb
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)

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

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

~~~
nickpsecurity
I agree.

------
vmorgulis
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
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)

------
graycat
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
No, it isn't. Especially since it's so damn easy to setup a git or mercurial
server.

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

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

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

------
Rygu
Ugh, what people will do for job security.

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

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

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

