See, there's the problem. The sitting. Oh, and the waiting.
Now I realize, friend, that there ought to be a way for those developers to know you're sitting and waiting and, God willing, someday, someone will be able to reach out of your monitor, shake your hand, and say, "My friends, my brothers and sisters, thank you for your patient, ever-suffering faith! Here, right now, today, glory glory, is that blessed new software you've believed in for so long!" but until that golden, glorious day, we're all just bound, bound and cursed, to be sitting and waiting for those overworked and underthanked developers to get tired of their sitting and their waiting so they can release that wonderful, beautiful new code into our hands.
Or you could thank them for what they've already done and hope it's good motivation to keep working. I'm just saying. Hallelujah.
Perl has a compiler and a virtual machine just like Java does. In cases where high performance is really necessary, perhaps Nokia will cache bytecode or use a persistent interpreter.
With that said, I'd rather see them use Parrot, as it's a nicer approach in the long term.
Describing software in terms of physical goods leads to some convoluted thinking, though. Consider donating software licenses to a school. Is that really worth $x million?
Now consider developing software. Linus started writing a terminal emulator and, a decade later, that project ran on huge mainframes, embedded chips found in consumer machines, and everything in between. Sure, that took a lot of time and, yes, he rewrote a lot of code along the way, but the fact that software isn't physical makes it possible. (If you don't care for the terminal emulator as a starting point, replace it with "a simple Unix workalike for the best x86 technology 1990 had to offer". The example still works.)
He couldn't have turned a diorama into a multi-level museum that way. That's why I think the analogy is flawed. It seems to focus on the irreducible complexity that comes from a building being a physical entity. I don't think that applies very well to software.
My problem with the analogy is that the complexity involved in revising software versus revising a house is completely different. There are ways to take a simple program (say, one that's not thread safe) and make it thread-safe while retaining most of the code. You really don't have that option with buildings.
There's something fundamentally different with software, as it's mostly free of physical constraints.
Good points! If the current version has no automated tests and if you can afford to take the time away from bugfixes or adding new features to the stable version, it may be worth starting over. In my experience, though, those occasions are rare.
(I shouldn't be surprised at the optimism that says "We made a royal mess last time, but I know we'll do it perfectly this time!")
You are not going to build a business building on top of your house's foundation...it just is not scalable to the new needs.
That may not be a good analogy. You can't gradually update your house's foundation, while you can gradually improve the foundation of a piece of software.
How often have you been able to get the requirements correct before you started designing, or coding, or debugging?
If your answer is "not often", do you think the biggest reason for that is because of a failure in requirements gathering or a failure in the development process that attempts to separate the process of requirements gathering from design and coding?
I think the answer is tremendously important to the question of whether outsourcing can work effectively.
I see your point and your goal and they're quite reasonable.
I do still fail to see how the GPL is coercive. Even if you don't like the two default alternatives (don't use it, or distribute your modifications under the same terms), you still have the option of negotiating a different contract with the copyright holder. Also, the terms of the GPL are expressed reasonably straightforwardly. The FSF is not in the habit of hiding the implications.
I suppose the term "coerce" brings to mind RMS jumping out from behind a rock and yelling "Aha! Now all of your code belongs to me!" That seems rather unfair.
Remember that day RMS came to your job and duct-taped you to your chair and forced you to download, modify, and distribute a GPL'd application? I'm willing to say he was slightly out of line, though I understand his point.
I understood you to suggest that GTK would drop their reliance on Xlib, using the DirectFB instead. That would be silly, as it immediately cuts out everyone who isn't using a well-supported card on x86 Linux running one of a handful of kernel versions. Xlib, for all its warts, runs many, many places.
Providing an alternate backend for GTK could be interesting, though I suspect it'd find wider acceptance on very small devices, where the hardware's well-understood and a couple of hackers can keep the drivers running smoothly.
... and quickly drop that pesky cross-platform portability it enjoys right now, at least until someone ports the Linux framebuffer device to non-Linux systems.
Re:Let the conspiracy theories begin...
on
Make More Mistakes
·
· Score: 2, Insightful
This is a logical fallacy known as a hasty generalization. You're arguing that because one open source project failed to sustain a business model, all open source projects will fail to do so.
That may be true, but your argument fails to support it.
Slashdot Mirror
Perhaps something like a caldera?
Don't get me started on Parrot for game developers! Hey, that's a great idea for an OSCON talk....
That falls under the second rule above. The programmer asked for addition. Perl doesn't like to second guess the programmer.
(This attitude isn't limited to Perl. See "I prefer to program as if errors and exceptions cannot occur" by Ron Jeffries on the XP mailing list for a similar view.)
Predictable is subjective. I find Perl's two rules here consistent:
Parrot does JIT on at least x86 and PPC already and can emit native executables.
Alternately, Perl cares more about container types than value types.
See, there's the problem. The sitting. Oh, and the waiting.
Now I realize, friend, that there ought to be a way for those developers to know you're sitting and waiting and, God willing, someday, someone will be able to reach out of your monitor, shake your hand, and say, "My friends, my brothers and sisters, thank you for your patient, ever-suffering faith! Here, right now, today, glory glory, is that blessed new software you've believed in for so long!" but until that golden, glorious day, we're all just bound, bound and cursed, to be sitting and waiting for those overworked and underthanked developers to get tired of their sitting and their waiting so they can release that wonderful, beautiful new code into our hands.
Or you could thank them for what they've already done and hope it's good motivation to keep working. I'm just saying. Hallelujah.
Perl has a compiler and a virtual machine just like Java does. In cases where high performance is really necessary, perhaps Nokia will cache bytecode or use a persistent interpreter.
With that said, I'd rather see them use Parrot, as it's a nicer approach in the long term.
I wish I did have a better analogy, but unfortunately, I don't!
Describing software in terms of physical goods leads to some convoluted thinking, though. Consider donating software licenses to a school. Is that really worth $x million?
Now consider developing software. Linus started writing a terminal emulator and, a decade later, that project ran on huge mainframes, embedded chips found in consumer machines, and everything in between. Sure, that took a lot of time and, yes, he rewrote a lot of code along the way, but the fact that software isn't physical makes it possible. (If you don't care for the terminal emulator as a starting point, replace it with "a simple Unix workalike for the best x86 technology 1990 had to offer". The example still works.)
He couldn't have turned a diorama into a multi-level museum that way. That's why I think the analogy is flawed. It seems to focus on the irreducible complexity that comes from a building being a physical entity. I don't think that applies very well to software.
Maybe I'm being too picky, though. It happens. :)
I'm not talking about rewriting some code, I'm talking about throwing away the whole thing.
(I've explained elsewhere why I think the building analogy is flawed, so I won't address that here.)
My problem with the analogy is that the complexity involved in revising software versus revising a house is completely different. There are ways to take a simple program (say, one that's not thread safe) and make it thread-safe while retaining most of the code. You really don't have that option with buildings.
There's something fundamentally different with software, as it's mostly free of physical constraints.
Good points! If the current version has no automated tests and if you can afford to take the time away from bugfixes or adding new features to the stable version, it may be worth starting over. In my experience, though, those occasions are rare.
(I shouldn't be surprised at the optimism that says "We made a royal mess last time, but I know we'll do it perfectly this time!")
If you track mud all over your kitchen floor, do you rip it up and put down new tile?
That may not be a good analogy. You can't gradually update your house's foundation, while you can gradually improve the foundation of a piece of software.
I kinda prefer JWZ's the CADT Model.
Well, yeah, but only on Sunday and not everybody had a slice...
I remember it from the start of the demo. It may not have been in the full game.
I'll bite. Why do development methods make resounding success less likely?
How often have you been able to get the requirements correct before you started designing, or coding, or debugging?
If your answer is "not often", do you think the biggest reason for that is because of a failure in requirements gathering or a failure in the development process that attempts to separate the process of requirements gathering from design and coding?
I think the answer is tremendously important to the question of whether outsourcing can work effectively.
I see your point and your goal and they're quite reasonable.
I do still fail to see how the GPL is coercive. Even if you don't like the two default alternatives (don't use it, or distribute your modifications under the same terms), you still have the option of negotiating a different contract with the copyright holder. Also, the terms of the GPL are expressed reasonably straightforwardly. The FSF is not in the habit of hiding the implications.
I suppose the term "coerce" brings to mind RMS jumping out from behind a rock and yelling "Aha! Now all of your code belongs to me!" That seems rather unfair.
Remember that day RMS came to your job and duct-taped you to your chair and forced you to download, modify, and distribute a GPL'd application? I'm willing to say he was slightly out of line, though I understand his point.
I understood you to suggest that GTK would drop their reliance on Xlib, using the DirectFB instead. That would be silly, as it immediately cuts out everyone who isn't using a well-supported card on x86 Linux running one of a handful of kernel versions. Xlib, for all its warts, runs many, many places.
Providing an alternate backend for GTK could be interesting, though I suspect it'd find wider acceptance on very small devices, where the hardware's well-understood and a couple of hackers can keep the drivers running smoothly.
... and quickly drop that pesky cross-platform portability it enjoys right now, at least until someone ports the Linux framebuffer device to non-Linux systems.
This is a logical fallacy known as a hasty generalization. You're arguing that because one open source project failed to sustain a business model, all open source projects will fail to do so.
That may be true, but your argument fails to support it.
The box needs a shelf, a chair, the floor, or some other flat surface. That's about it.