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 / ar…
I see no indication that the devs aren't using version control. All we know from that statement is that they are not making it available to the public.
I've never bothered. Hotmail or Yahoo email addresses were embarrassing back in the day, but I guess the hype around Gmail changed that 10 years ago. I've never felt awkward putting a gmail address on a business card.
You don't find that a gmail address on a business card conveys that it's a 1-2 person operation or very loosely organized? Given the low barrier to entry for setting up hosted email (google apps being $5/mo/user) I personally get the impression the person doesn't take their business seriously, on par with business cards with perforated edges from home printing. I know my gut reaction when I get a (semi-)professional…
When I was a 1 person operation, and worked as a consultant doing dev work and consulting, I had no problem using my Gmail account. Of course when I started a small company we used a hosted domain.
But before the Gmail days it was weird and unprofessional for even a 1 person operation to have a Webmail address.
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…
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.
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.
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 th…
> 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.
Wow, -3 for this horrible comment. HN is full of idiots.
Now go on, make it another -10; it will be the only thing in your day that makes you feel that you have any influence.
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…
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 n…
You politely and clearly explained why you're unconvinced a repo would benefit you. You got a couple replies pointing out some advantages, which maybe you hadn't considered or at least some other people might not have known about.
Result? Nice discussion. Opportunity for folks to learn something new.
And yet, your comment is gray from down votes. Since it would look bad for you to complain about that, I will: That sucks.
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…
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 wa…
The LGPL requires that end users are able to replace LGPL libraries with new builds. The App Store creates a bit of an issue, but it's possible to update app libraries if your phone is jailbroken. You might also be able to modify and re-sign, but I'm not sure. The LGPL doesn't require the developer to use a new version or provide updates at anyone's request.
Well, what they say: > 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). That's a very strained reading of t…
Theoretically, could you just say "the newest version of this software is licensed under the LGPL; for any other version, I retain copyright and grant no rights to it, and revoke any rights previously granted."? So it becomes an infringement of their copyright to not be running the newest version, whatever the LGPL says.
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.
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.