I was one of the hacker employees of the FSF back in the early days of the HURD project. They pay was modest by industry standards but fair (every employee, hacker or not, got the same pay -- later the formation of a union was encouraged).
Some very good and lasting work got done back then, in spite of our rather unconventional work habits. I'm thinking especially of all the work done laying down the foundation of GNU libc. Roland McGrath got a lot of code rolling and, perhaps more importantly, established a pretty good standard of coding conventions and quality expectations.
I did not myself work directly on the HURD but in our small office I did have chats with McGrath and Bushnell about it. The sentiment around the design was, I think it fair to say, somewhat giddy. The free software movement was (and is) all about freeing users from subjugation to those who provide software. The HURD's microkernel architecture and the structure of the daemons would securely free users from subjugation to system administrators - each user could securely invoke a set of daemons to create the operating environment he or she wished, no special permissions required.
It was well understood back then, and even a point of discussion in academia, that a microkernel architecture posed some difficult problems for performance (related mostly to a greater number of context switches as messages pass between daemons rather than syscalls being handled by a monolithic kernel). Rashid's work had suggested that this problem was not so terribly significant after all. And so, at least to me, it felt like the GNU project was not only doing this shoestring-budget freedom-fighting hacking, but also leading near the bleeding edge of CS research made practical. Well, that was the theory, anyway, and we were mighty proud of ourselves and generally excited to be there.
Not much but some of the hacking of the core staff took place "from home". You must remember that this before any kind of data over voice or particularly high bandwidth connection was commonplace - so that hacking was over modem connected to text terminal. Mostly we hacked in a shared office which, if you saw it, you'd think "Wow, that's a slightly large closet." We were, at that time, guests of MIT.
With all due respect for RMS, and I don't think he'd especially disagree with this (though I could be wrong): he was an absolutely terrible project leader for the hacking part. As history has shown, his popularity among some notwithstanding, he's extraordinarily good at the political part of his works. Leading the technical project? Not so much.
It wasn't so much that he dictated bad technical choices. Even the choice to use Mach might have worked out. On the contrary, he was relatively "hands off" in most technical matters, only micromanaging if you really dragged his attention to some detail. It was more that he lacked any coherent overall strategy for completing GNU and his broad directives involved underestimations of the amount of work involved and were sometimes scattered, even bordering on inconsistent. It just wasn't his strength.
The original vision for the GNU system, at least as I understood it, was to - sure - grow a unix clone, but then to build a user space that much more closely resembled that of lisp machines. Emacs (with its lisp extensibility) was taken to be a paradigm for how interactive programs might work. Originally, it was even envisioned that the window system would be lisp based.
One early change to the original GNU vision occurred when it became clear that X11 worked pretty well and was here to stay and would be free software. As a practical matter: just use that.
Later, as mentioned in other comments here, the ECGS fork of GCC caused issues - ultimately leading to the displacement of an FSF appointed project leader. There is some back story to that. The company Cygnus (later acquired by Red Hat, founded by M. Tiemann et al.) had been advertising to customers that not only could they develop customized extensions to GCC, but that they could shepherd those extensions into the "official releases". There was frustration at Cygnus and some other firms that the FSF branch was not merging these changes quickly enough or was arguably being too prickly about the nature of the changes. As nearly as I can tell those sentiments led to the ECGS fork and RMS was ultimately put in the position of having to choose between "blessing" that fork or simply losing any claim at all to the future of GCC.
Around this time, I am told but can not myself verify, RMS was also under pressure from some key FSF advisors or supporters to exit the software development business and focus on the politics. Whatever the motivation, the FSF shed most of its in-house development efforts.
The pattern of losing the original GNU vision continued in the controversy over Gnome vs. KDE. Originally, KDE had licensing issues and did not pass muster with the FSF as being free software. Those problems have since been fixed but at the time it led to RMS' proclamation that Gnome would be the desktop for GNU -- a radical departure from what was originally conceived. Later, as you may have read, RMS came to describe Miguel as a traitor to the free software movement.
Somewhere in there - I'd have to look things up to get the timelines exactly right - Debian took off, in part to try to fill a void in the FSF's leadership at assembling a complete GNU system. Bruce Perens penned the now famous "Debian Guidelines".
A small group of relatively wealthy influencers, including Tiemann, met with Eric Raymond and conjured up the allegedly business-friendly "open source" notion. The main differentiation they sought from the FSF is that they would not condemn proprietary software or describe themselves as a freedom movement - they sought to emphasize the economic advantages of having volunteers do work for no pay. In my view, their main purpose upon founding was to attempt to politically marginalize RMS (a project in which they've had some success).
Bushnell moved on to a different stage of his life and, I guess it's fair to say, a higher calling. McGrath moved on to what I gather is a sweet job for Red Hat. The GNU project was gutted. Its institutional memory and such momentum as it may have had was gone. This was in part because RMS was not so great as a project leader but also, in large part, because the project was under significant attack.
In my humble opinion, there would be plenty good to come of a resurrection of the GNU project. I don't necessarily mean a resurrection of the HURD although I suspect we can do better than the Linux kernel. I do mean a return to a concentrated effort to build the kind of user space originally envisioned. While such a project could have enormous social benefit, I don't see any way to institute it and find support enough to carry it out.
Programmable applications is indeed the way things should go. And the programmability has to be immediate. Compare the slippery slope of customizing emacs to the burden of writing an Eclipse plugin. Most of the things that go by the name "plugin architecture" have a large barrier to entry because of the complex, heavyweight relationship of a plugin to its host environment.
Programmable applications is indeed the way things should go. And the programmability has to be immediate.
Then you should look at Smalltalk. Just deploy with the compiler and dev tools in the image. You can quickly visually inspect every object in the image and write a script against it, and run it instantly.
Can you describe more about what you see as this originally-envisioned user space?
Briefly, yes.
Two aspects were of particular interest to me, although if you ask the HURD developers from back then they could likely point out others:
1. Interactive programs should be uniformly customizable, extensible, and self-documenting - roughly in the manner of Emacs. That sounds like a trite thing. After all, the programs we wound up with have all three traits. For example, Gimp can be customized, new commands can be written in extension languages, and it has a great deal of on-line documentation. I mean something more specific but hard to convey concisely. Most of Gimp is not written as extension packages, which betrays an architectural weakness in contrast to emacs. Gimp's interaction model and customization model is awkward and ad hoc, compared to emacs. The on-line documentation of Gimp is not designed in a way such that its enhancement is a natural part of writing extensions. I don't mean that Emacs is perfect in these regards - it certainly isn't. I do mean that the architectural approach it takes is vastly more sane than what the interactive programs we wound up with use. (Don't mean to pick on Gimp. The observations apply as well to the Open Office suite, to Gnome, to Firefox, and more. We have a big, barely maintainable heap of discordant and vaguely conceived functionality.)
2. On a more mundane level, even the command line got horked. You know how (nearly) all GNU command line programs have --version and --help options and so forth? At least when I was working at FSF the notion was that that coding standard was a stepping stone to a shell much more like the much-loved shell on the Tops-20 operating system. The standard was supposed to be gradually refined so that those standard "--help" messages could be automagically used by the shell to intelligently prompt for arguments to a program.
I guess I should add that a lisp - most of us that I knew assumed Scheme - would figure prominently as the main extension language (rather than Emacs lisp). Why a lisp? Well, it had a proven track record and that was our aesthetic -- I'll leave it at that.
Could you be a little more specific about this? E.g. perhaps who, or at least how and who it effected how.
And, yep, a good user space of the sort you've described would be great (and is in fact something I'm trying to get myself jump started working on, in a FoNC style: http://vpri.org/html/work/ifnct.htm)
Could you be a little more specific about this? E.g. perhaps who, or at least how and who it effected how.
Briefly:
The ECGS schism was, in my view, purely and simply a successful effort to wrestle control over GCC away from the FSF. The FSF sought to develop GCC <i>for the aims of the GNU system</i> but a few firms, and their employees, sought to develop GCC for the aims of those proprietary software firms or the aims of proprietary software firms which were their customers.
The invention of "open source" was, in my view, purely an attempt to disassociate the resource of GNU source code and free software practices from the FSF's freedom mission. To put it crudely, and you can see this even in Raymond's original essays - they sought to recast the movement to give users software freedom into a movement to give business free labor.
After the Linux kernel started to take off there was, additionally, the non-trivial task of assembling complete and supported distributions. Although there was a community process underway that showed some promise (Debian), the firms that took the lead and grew quite large turned their back on that process, kept their system integration work internal and proprietary, and meanwhile solicited volunteers to work on other matters. That is to say that while the community might have been far further along by now than it is at distributing a decent GNU system, those firms fought (and won) to prevent that from happening.
Those are some examples. There are more but I did say I'd be brief.
I think it's quite disingenuous to describe the development model of Cygnus and RedHat as being more proprietary than how the FSF was doing things at the time. ESR is an epic douchebag, but he nailed y'all in his description of the FSF's development model in The Cathedral and the Bazaar.
At least Cygnus took input from contributors and even actually bothered to work on the project themselves. The audacity!
It's not disingenuous. When I was speaking "proprietary" I wasn't referring to Cygnus but rather to RedHat and other complete system distribution firms. Internally, they maintain a great deal of infrastructure to smooth the assembly of complete distributions. They maintain that proprietary infrastructure to have a competitive advantage. They decline to assist public projects with that assembly of a complete system.
That is there right, under law and free software licensing terms. Nevertheless, it is a wrong in the sense that they are refusing to help the community who has so benefited them, and actively attempting to keep the larger community from self-organizing to eliminate the need for that closely held infrastructure. These firms sing a song about the benefits of community cooperation but they do not practice what they preach. They take free labor from others. They give back labor in areas that are strategic to them. But they withhold labor that would actually advance software freedom in substantial ways.
Canonical did the same thing with Launchpad for five years before finally releasing the whole thing, including the build system (which was expected to be kept proprietary).
Heh. Yes, in the very early days of Canonical I chatted with Mark about the possibility of working there and that intention to closely hold some of the software I'd be working on was one of the red flags for me. In my view, it was partly because Canonical went down that path that GNU Arch got forked and horked (mainly by Canonical employees).
Some very good and lasting work got done back then, in spite of our rather unconventional work habits. I'm thinking especially of all the work done laying down the foundation of GNU libc. Roland McGrath got a lot of code rolling and, perhaps more importantly, established a pretty good standard of coding conventions and quality expectations.
I did not myself work directly on the HURD but in our small office I did have chats with McGrath and Bushnell about it. The sentiment around the design was, I think it fair to say, somewhat giddy. The free software movement was (and is) all about freeing users from subjugation to those who provide software. The HURD's microkernel architecture and the structure of the daemons would securely free users from subjugation to system administrators - each user could securely invoke a set of daemons to create the operating environment he or she wished, no special permissions required.
It was well understood back then, and even a point of discussion in academia, that a microkernel architecture posed some difficult problems for performance (related mostly to a greater number of context switches as messages pass between daemons rather than syscalls being handled by a monolithic kernel). Rashid's work had suggested that this problem was not so terribly significant after all. And so, at least to me, it felt like the GNU project was not only doing this shoestring-budget freedom-fighting hacking, but also leading near the bleeding edge of CS research made practical. Well, that was the theory, anyway, and we were mighty proud of ourselves and generally excited to be there.
Not much but some of the hacking of the core staff took place "from home". You must remember that this before any kind of data over voice or particularly high bandwidth connection was commonplace - so that hacking was over modem connected to text terminal. Mostly we hacked in a shared office which, if you saw it, you'd think "Wow, that's a slightly large closet." We were, at that time, guests of MIT.
With all due respect for RMS, and I don't think he'd especially disagree with this (though I could be wrong): he was an absolutely terrible project leader for the hacking part. As history has shown, his popularity among some notwithstanding, he's extraordinarily good at the political part of his works. Leading the technical project? Not so much.
It wasn't so much that he dictated bad technical choices. Even the choice to use Mach might have worked out. On the contrary, he was relatively "hands off" in most technical matters, only micromanaging if you really dragged his attention to some detail. It was more that he lacked any coherent overall strategy for completing GNU and his broad directives involved underestimations of the amount of work involved and were sometimes scattered, even bordering on inconsistent. It just wasn't his strength.
The original vision for the GNU system, at least as I understood it, was to - sure - grow a unix clone, but then to build a user space that much more closely resembled that of lisp machines. Emacs (with its lisp extensibility) was taken to be a paradigm for how interactive programs might work. Originally, it was even envisioned that the window system would be lisp based.
One early change to the original GNU vision occurred when it became clear that X11 worked pretty well and was here to stay and would be free software. As a practical matter: just use that.
Later, as mentioned in other comments here, the ECGS fork of GCC caused issues - ultimately leading to the displacement of an FSF appointed project leader. There is some back story to that. The company Cygnus (later acquired by Red Hat, founded by M. Tiemann et al.) had been advertising to customers that not only could they develop customized extensions to GCC, but that they could shepherd those extensions into the "official releases". There was frustration at Cygnus and some other firms that the FSF branch was not merging these changes quickly enough or was arguably being too prickly about the nature of the changes. As nearly as I can tell those sentiments led to the ECGS fork and RMS was ultimately put in the position of having to choose between "blessing" that fork or simply losing any claim at all to the future of GCC.
Around this time, I am told but can not myself verify, RMS was also under pressure from some key FSF advisors or supporters to exit the software development business and focus on the politics. Whatever the motivation, the FSF shed most of its in-house development efforts.
The pattern of losing the original GNU vision continued in the controversy over Gnome vs. KDE. Originally, KDE had licensing issues and did not pass muster with the FSF as being free software. Those problems have since been fixed but at the time it led to RMS' proclamation that Gnome would be the desktop for GNU -- a radical departure from what was originally conceived. Later, as you may have read, RMS came to describe Miguel as a traitor to the free software movement.
Somewhere in there - I'd have to look things up to get the timelines exactly right - Debian took off, in part to try to fill a void in the FSF's leadership at assembling a complete GNU system. Bruce Perens penned the now famous "Debian Guidelines".
A small group of relatively wealthy influencers, including Tiemann, met with Eric Raymond and conjured up the allegedly business-friendly "open source" notion. The main differentiation they sought from the FSF is that they would not condemn proprietary software or describe themselves as a freedom movement - they sought to emphasize the economic advantages of having volunteers do work for no pay. In my view, their main purpose upon founding was to attempt to politically marginalize RMS (a project in which they've had some success).
Bushnell moved on to a different stage of his life and, I guess it's fair to say, a higher calling. McGrath moved on to what I gather is a sweet job for Red Hat. The GNU project was gutted. Its institutional memory and such momentum as it may have had was gone. This was in part because RMS was not so great as a project leader but also, in large part, because the project was under significant attack.
In my humble opinion, there would be plenty good to come of a resurrection of the GNU project. I don't necessarily mean a resurrection of the HURD although I suspect we can do better than the Linux kernel. I do mean a return to a concentrated effort to build the kind of user space originally envisioned. While such a project could have enormous social benefit, I don't see any way to institute it and find support enough to carry it out.