All of the projects you mentioned are fairly mature, with stable core teams. My post was more concerned with taking a project from seed to sapling. As a counter example, the Gnome project has had AnonCVS since a very early stage. The growth rate of Gnome is very impressive.
CVS is of almost paramount importance when launching a Free Software project. It's sort of an ad-hoc-release system for unstable code. Setting up a CVS tree takes a couple of hours for some one who knows how to do it. Set it up for anonymous read only at first. Within a few weeks or months the people who should have write access will make themselves known by their commitment. In this way, a core team of developers will emerge naturally.
Every time the project builds and runs reasonably, ship it. Major releases can be done when a bunch of new features build and run. When the project gets larger it can have branch releases like the AC kernel patches. These are not forks since they get merged back in to the main line fairly quickly.
Setting up a project for frequent releases should be done early. The longer you wait between releases the more difficult it becomes to get it out. Frequent releases of minor changes impart an evolutionary nature to the project, a definite win. Waiting a year between releases makes for a ton of work getting the configuration and build setup alone to work.
In short, you can't be afraid to hang out your underwear. The advantage is that the holes in your drawers may magically get fixed before you have to wear them next.
The current legal climate motivates the need for FSF to hold rights to GNU software. GNU was founded to respond to a growing movement toward undisclosed source code. At that time, and still today, some people saw an opportinity to enhance public source code by improving it. That's OK, but witholding the source to the improvements is not OK. It violates the spirit of releasing software as source. The GPL is a direct response to this situation.
Assigning copyright to FSF means that the GNU system is legally defensible as a unit. It's the GNU system, copyright (c) Free Software Foundation. It gives cohesion to the entire system. And it provides a legal framework to protect the system under the terms of its release
I'm sure that all of us would welcome the situation that existed when software was shared as source without much thought, but that situation does not exist at the moment. Right now, writing software is subject to many laws. FSF should and does operate in the current legal context, as unpleasent as that may be.
[disclaimer] I work for GNU, I do not necessarily speak for GNU.
We don't do this to take away anybody's rights. We don't do this to be draconian. We're just trying to make sure that the software we distribute as source code stays source code.
Assigning code to the FSF ensures that your software becomes part of the GNU system a modest but very capable suite of programs for running your computer.
No one is required to write for GNU, indeed people are encouraged to use software written for GNU on non-GNU systems.
I will not be using this technology. It's primary purpose, as I see it, is to buttress information hoarding schemes such as CSS. It's well known that content scrambling methods such as CSS will fall to a well written program that reads the decrypted information out of the video framebuffer. I see this as an attempt to close that "loophole".
Since I am morally opposed to information hoarding, I tend to boycott systems that facilitate it. I expect to structure my life in such a way that communications between my video card and my monitor will not need encryption. If this means that some information will not be available to me, so be it.
This may be somewhat moot since, if they're really using 56 bit DES, the information will not be scrambled for long.
What you're talking about is abstraction and it's been going on since the first macro-assembler in the early fiftys. Programs that write programs have been around for decades. I use Perl to write C code, does that count? The developmant of FORTRAN did not decrease the need for good programmers, it simply enabled them to write better programs in less time. Who will write the "programming programs"? More important, who will debug them? Who will port them to quantum processors when they become available?
As for optimization, no matter how fast computers become, someone will be able to conceive of a problem that will take a thousand years to solve on the best hardware available. The future of optimization is secure.
Since programming is a branch of mathematics, there will always be an opportunity to build on the work of your predecessors.
Having experienced my house burning down, I find it suprising to read the remarkable calousness of some of these replies. I can say, confidently, that it altered the course of my life. In some ways, it was good, in others, simply tragic. By the age of 27 I'd built a library of some thousand books. Two thirds of them were lost, including a hand written journal covering about 5 years. My filing cabinet containing many, many documents that were, to me, priceless, gone. Keepsakes from my dead Grandfather. Furnature that I'd build by hand. Photo albums and personal drawings, all gone. I suspect that most of the people replying here have not experienced a house fire, if they had, the tone of the responses would likely be very different. Perhaps it wouldn't be too much to ask that people posting to this news take a minute to think over what their feelings would be if they lost their most cherished, most irreplacable keepsakes. Take it from some one who's been there, fires build character, they steel you for the rest of your life.
Slashdot Mirror
All of the projects you mentioned are fairly mature, with stable core teams. My post was more concerned with taking a project from seed to sapling. As a counter example, the Gnome project has had AnonCVS since a very early stage. The growth rate of Gnome is very impressive.
CVS is of almost paramount importance when launching a Free Software project. It's sort of an ad-hoc-release system for unstable code. Setting up a CVS tree takes a couple of hours for some one who knows how to do it. Set it up for anonymous read only at first. Within a few weeks or months the people who should have write access will make themselves known by their commitment. In this way, a core team of developers will emerge naturally.
Every time the project builds and runs reasonably, ship it. Major releases can be done when a bunch of new features build and run. When the project gets larger it can have branch releases like the AC kernel patches. These are not forks since they get merged back in to the main line fairly quickly.
Setting up a project for frequent releases should be done early. The longer you wait between releases the more difficult it becomes to get it out. Frequent releases of minor changes impart an evolutionary nature to the project, a definite win. Waiting a year between releases makes for a ton of work getting the configuration and build setup alone to work.
In short, you can't be afraid to hang out your underwear. The advantage is that the holes in your drawers may magically get fixed before you have to wear them next.
The current legal climate motivates the need for FSF to hold rights to GNU software. GNU was founded to respond to a growing movement toward undisclosed source code. At that time, and still today, some people saw an opportinity to enhance public source code by improving it. That's OK, but witholding the source to the improvements is not OK. It violates the spirit of releasing software as source. The GPL is a direct response to this situation.
Assigning copyright to FSF means that the GNU system is legally defensible as a unit. It's the GNU system, copyright (c) Free Software Foundation. It gives cohesion to the entire system. And it provides a legal framework to protect the system under the terms of its release
I'm sure that all of us would welcome the situation that existed when software was shared as source without much thought, but that situation does not exist at the moment. Right now, writing software is subject to many laws. FSF should and does operate in the current legal context, as unpleasent as that may be.
[disclaimer] I work for GNU, I do not necessarily speak for GNU.
We don't do this to take away anybody's rights. We don't do this to be draconian. We're just trying to make sure that the software we distribute as source code stays source code.
Assigning code to the FSF ensures that your software becomes part of the GNU system a modest but very capable suite of programs for running your computer.
No one is required to write for GNU, indeed people are encouraged to use software written for GNU on non-GNU systems.
I will not be using this technology. It's primary purpose, as I see it, is to buttress information hoarding schemes such as CSS. It's well known that content scrambling methods such as CSS will fall to a well written program that reads the decrypted information out of the video framebuffer. I see this as an attempt to close that "loophole".
Since I am morally opposed to information hoarding, I tend to boycott systems that facilitate it. I expect to structure my life in such a way that communications between my video card and my monitor will not need encryption. If this means that some information will not be available to me, so be it.
This may be somewhat moot since, if they're really using 56 bit DES, the information will not be scrambled for long.
Personally, I look forward to being able to fork() my cognition, maybe a few hundred copies of me would actually be able to do my job :^)
What you're talking about is abstraction and it's been going on since the first macro-assembler in the early fiftys. Programs that write programs have been around for decades. I use Perl to write C code, does that count? The developmant of FORTRAN did not decrease the need for good programmers, it simply enabled them to write better programs in less time. Who will write the "programming programs"? More important, who will debug them? Who will port them to quantum processors when they become available?
As for optimization, no matter how fast computers become, someone will be able to conceive of a problem that will take a thousand years to solve on the best hardware available. The future of optimization is secure.
Since programming is a branch of mathematics, there will always be an opportunity to build on the work of your predecessors.
Having experienced my house burning down, I find it suprising to read the remarkable calousness of some of these replies. I can say, confidently, that it altered the course of my life. In some ways, it was good, in others, simply tragic. By the age of 27 I'd built a library of some thousand books. Two thirds of them were lost, including a hand written journal covering about 5 years. My filing cabinet containing many, many documents that were, to me, priceless, gone. Keepsakes from my dead Grandfather. Furnature that I'd build by hand. Photo albums and personal drawings, all gone.
I suspect that most of the people replying here have not experienced a house fire, if they had, the tone of the responses would likely be very different.
Perhaps it wouldn't be too much to ask that people posting to this news take a minute to think over what their feelings would be if they lost their most cherished, most irreplacable keepsakes.
Take it from some one who's been there, fires build character, they steel you for the rest of your life.
pjr