Slashdot Mirror

So the suits have invaded your favourite OS, do you care, should you care ?

The answer is probably yes. A large number of people are about to collide with a community they don't understand which has a long history of its own independence, and its own shared cultural references. Think AOL meets the internet.

The very first line proves this. I can talk about "a suit" and most of the readership know exactly what I mean. The "suit" is a shared stereotype of many of the outsiders of the community. If you are what we class as a suit and are reading this by the way welcome, do come in , you don't need to hang around the door. We don't even have suits in general as the first people against the wall, although we do have places reserved for a couple of them.

Similarly things like "See figure 1"[0] , "What was your user name again ?" and suggestions for using dead chickens are something that has a common meaning. Userfriendly isn't terribly funny to some people because they lack the frame of reference to understand ISP's really really do work like that. I feel sorry for them because now that I've finally discovered it, I've found it is a great cartoon.

It is important that when the suits do things that don't fit the community that people gently remind them. It takes time and it has to be done right but it does work. The average AOL user has become materially more internet-friendly over time. The continual polite chiding for using HTML email on mailing lists has had its desired effect. Also sometimes you need to step back and try and see how they are thinking and why as well as their background. Don't just criticise but try and explain in their terms why things matter. "See figure 1" is not the productive answer especially if they've learned what figure 1 is.

In the Linux frame of reference most suits are going to be coming to Linux partly because everyone else is and partly because of its excellent price/performance, and to give them their own buzzwords back - Total cost of ownership. I imagine most of the people cheering happily at all the proprietary software and value added (or as Richard Stallman likes to term it 'freedom deducted') software are in this category.

If you want to teach them the reasons why Linux is better, faster and more stable do it gently. In time they will come to wonder why they are pricing a commercial email system for Linux when the one on the CD-ROM works perfectly well anyway. They will wonder why they are buying high price network management tools when they seem to get free ones. Eventually they will get the message. The barrier has partly gone, no longer is it "but thats free software", its "thats free software, excellent - will that package work for our needs".

We need to gently teach them that technical shows they should be paying for speakers, they need to show us that for marketing shows the talks are really advertising so they don't expect to pay for them. We need to teach IDG that registering Linuxexpo.com and causing confusing with the real Linux Expo in May is not the way we do things here.

There is going to be real turbulence ahead if history repeats (as always [1]). Certainly my own memories of the UK mainstream arrival of the show sold home computer, and even more the events way prior to that in the USA that Stephen Levy documents in 'Hackers' mirror the current happenings remarkably well.

Some vendors will probably vanish over the next two years while others disappear into big name companies and numerous new vendors spring up to take on new niches and angles of the Linux business. The whole business model is still in flux - do Linux companies sell Linux, do they use Linux as a tool to bundle software to the retail channel, do they sell custom systems built on Linux, do they associate with some vendors or do they stay application vendor neutral and thus avoid competing with application people ? All of these are unknowns.

Money too is beginning to influence Linux kernel development far more than before. Not at the moment in a bad way I'm glad to say. Free software reflects the needs of the userbase and their talents. This has always therefore focused on the hardware people really possess. You'll notice Linux 1.2 for example doesn't reflect 2Gig machines with multiple RAID controllers. The typical home hacker doesn't generally possess these. Instead we have the coffee-machine interfacing mini-HOWTO. The people who need these high end facilities aren't writing them however, they are using their own currency for contributing to the kernel. They are paying people or using their own staff to write the high end support and place it under the GPL.

There is always a risk that money will start to talk too much. "I know this feature is stupid but if we pay you $$$$ will you do it". Thankfully Linus is rather good at saying "no" to anything that isn't a good idea. That is bound to be an area where there is some friction. These people will also bring non Unix ideas with them too. Linux will probably gain from this because Unix doesn't have a monopoly on good ideas, it just owns most of them.

Do look after our visiting suits, they come from a strange land and have strange rituals like "Trade Shows". Be assured they find our rituals of talking about technical material in detail just as strange. They have been living under an oppressive binary-only single OS regime, and as refugees need sympathy and education. It's very hard to teach someone the value of freedom but please do try. And I'm told we do share some common rituals. Our "flame war" is apparently held in person in their land and called "project meeting".

Please be friendly and give useful directions any lost suits.

[0] http://spiffy.cso.uiuc.edu/~kline/Stuff/see-figure -1.html
[1] I am a great fan of the "History repeats itself, it has to nobody ever listens" quote.

License: OpenContent

So the suits have invaded your favourite OS, do you care, should you care ?

The answer is probably yes. A large number of people are about to collide with a community they don't understand which has a long history of its own independence, and its own shared cultural references. Think AOL meets the internet.

The very first line proves this. I can talk about "a suit" and most of the readership know exactly what I mean. The "suit" is a shared stereotype of many of the outsiders of the community. If you are what we class as a suit and are reading this by the way welcome, do come in , you don't need to hang around the door. We don't even have suits in general as the first people against the wall, although we do have places reserved for a couple of them.

Similarly things like "See figure 1"[0] , "What was your user name again ?" and suggestions for using dead chickens are something that has a common meaning. Userfriendly isn't terribly funny to some people because they lack the frame of reference to understand ISP's really really do work like that. I feel sorry for them because now that I've finally discovered it, I've found it is a great cartoon.

It is important that when the suits do things that don't fit the community that people gently remind them. It takes time and it has to be done right but it does work. The average AOL user has become materially more internet-friendly over time. The continual polite chiding for using HTML email on mailing lists has had its desired effect. Also sometimes you need to step back and try and see how they are thinking and why as well as their background. Don't just criticise but try and explain in their terms why things matter. "See figure 1" is not the productive answer especially if they've learned what figure 1 is.

In the Linux frame of reference most suits are going to be coming to Linux partly because everyone else is and partly because of its excellent price/performance, and to give them their own buzzwords back - Total cost of ownership. I imagine most of the people cheering happily at all the proprietary software and value added (or as Richard Stallman likes to term it 'freedom deducted') software are in this category.

If you want to teach them the reasons why Linux is better, faster and more stable do it gently. In time they will come to wonder why they are pricing a commercial email system for Linux when the one on the CD-ROM works perfectly well anyway. They will wonder why they are buying high price network management tools when they seem to get free ones. Eventually they will get the message. The barrier has partly gone, no longer is it "but thats free software", its "thats free software, excellent - will that package work for our needs".

We need to gently teach them that technical shows they should be paying for speakers, they need to show us that for marketing shows the talks are really advertising so they don't expect to pay for them. We need to teach IDG that registering Linuxexpo.com and causing confusing with the real Linux Expo in May is not the way we do things here.

There is going to be real turbulence ahead if history repeats (as always [1]). Certainly my own memories of the UK mainstream arrival of the show sold home computer, and even more the events way prior to that in the USA that Stephen Levy documents in 'Hackers' mirror the current happenings remarkably well.

Some vendors will probably vanish over the next two years while others disappear into big name companies and numerous new vendors spring up to take on new niches and angles of the Linux business. The whole business model is still in flux - do Linux companies sell Linux, do they use Linux as a tool to bundle software to the retail channel, do they sell custom systems built on Linux, do they associate with some vendors or do they stay application vendor neutral and thus avoid competing with application people ? All of these are unknowns.

Money too is beginning to influence Linux kernel development far more than before. Not at the moment in a bad way I'm glad to say. Free software reflects the needs of the userbase and their talents. This has always therefore focused on the hardware people really possess. You'll notice Linux 1.2 for example doesn't reflect 2Gig machines with multiple RAID controllers. The typical home hacker doesn't generally possess these. Instead we have the coffee-machine interfacing mini-HOWTO. The people who need these high end facilities aren't writing them however, they are using their own currency for contributing to the kernel. They are paying people or using their own staff to write the high end support and place it under the GPL.

There is always a risk that money will start to talk too much. "I know this feature is stupid but if we pay you $$$$ will you do it". Thankfully Linus is rather good at saying "no" to anything that isn't a good idea. That is bound to be an area where there is some friction. These people will also bring non Unix ideas with them too. Linux will probably gain from this because Unix doesn't have a monopoly on good ideas, it just owns most of them.

Do look after our visiting suits, they come from a strange land and have strange rituals like "Trade Shows". Be assured they find our rituals of talking about technical material in detail just as strange. They have been living under an oppressive binary-only single OS regime, and as refugees need sympathy and education. It's very hard to teach someone the value of freedom but please do try. And I'm told we do share some common rituals. Our "flame war" is apparently held in person in their land and called "project meeting".

Please be friendly and give useful directions any lost suits.

[0] http://spiffy.cso.uiuc.edu/~kline/Stuff/see-figure -1.html
[1] I am a great fan of the "History repeats itself, it has to nobody ever listens" quote.

License: OpenContent

These are some of my thoughts on the Bazaar model that I figure are worth sharing. Its also a guide to how to completely screw up a free software project. I've picked a classic example of what I think is best dubbed the "Town Council" effect (although town councillors may think otherwise).

There are certain things you have to understand about software developers. The first thing to understand is that really good programmers are relatively unusual. Not only that but the difference between a true "real programmer" and the masses is significantly greater than that between "great" and "average" in many other professions. Studies have quoted 30 to 1 differences in productivity between the best and the rest.

Secondly you need to understand that a lot of the wannabe real programmers are very good at having opinions. Many of them also catch buzzword disease or have some speciality they consider the "one true path". On the Internet talk is cheap.

The third part of any software project is what we shall call "the masses". They range between people who don't program but contribute massively in other areas - documentation, helping users and artwork to the sort of people that are often used to argue that you should require a license to connect to the Internet.

The project I'm going to take as an example of how to screw up completely is the Linux 8086 project. Porting a subset of Linux to the 8086 is one of the worlds more pointless exercises on the whole, and something that started as a joke and got out of hand.

There are a very small number of real programmers with the time and the right (or is that wrong) kind of mental state to contribute to a project whose sole real worth is "Hack Value". As a result of this at any given time the project has two or three core contributing people.

Unfortunately there are a lot of people who think it would be neat to run Linux on an 8086 who feel obliged to "take part". Most of them in this case are in the "wannabe programmer" category as the masses spotted the "silly" factor of the project from a safe distance.

The problem that started to arise was the arrival of a lot of (mostly well meaning) and dangerously half clued people with opinions - not code, opinions. They knew enough to know how it should be written but most of them couldn't write "hello world" in C. So they argue for weeks about it and they vote about what compiler to use and whether to write one - a year after the project started using a perfectly adequate compiler. They were busy debating how to generate large model binaries while ignoring the kernel swapper design.

Linux 8086 went on, the real developers have many of the other list members in their kill files so they can communicate via the list and there are simply too many half clued people milling around. It ceased to be a bazaar model and turns into a core team, which to a lot of people is a polite word for a clique. It is an inevitable defensive position in the circumstances.

In the Linux case the user/programmer base grew slowly and it grew from a background group of people who did contribute code and either had a basis in the original Minix hacking community or learned a few things the hard way reboot by reboot. As the project grew people who would have turned into "The committee for the administration of the structural planning of the Linux kernel" instead got dropped in an environment where they were expected to deliver and where failure wasn't seen as a problem. To quote Linus "show me the source".

If someone got stuck they posted questions and there was and is a sufficiently large base that someone normally has both the time and the knowledge to reply. In the Linux8086 case the developers had long since walled themselves off. Given a better ratio of active programmers to potentially useful wannabe programmers would have rapidly turned some of the noise into productivity. The project would have gained more useful programmers and they in turn would have taught others. As with any learning exercise you are better off having only a few trainees.

There is an assumption some people make that you can't turn the "lesser programmers" into real programmers. From personal experience in the Linux project there are plenty of people who given a little help and a bit of confidence boosting will become one with the best. There are many who won't but enough that will. [1]

The Linux 8086 project has mostly recovered from its 'infestation' and is now a small quiet project, using CVS trees and led by Alastair Riddoch who has been doing a sterling job. With the town councillors De-camped its now possible to ask questions, join in and help the project.

The lessons from this project, and others that went the same way (and sometimes died - remember the earlier Linux word processor projects) are fairly clear:

• Release code right from the start. It doesn't matter if its not very useful. The best way to sort a town council is to simply do the job then tell them it has been done. Linux, KDE and GNOME have all taken this attitude and all done well from it. You can argue about the right way to program for a lifetime. Once there is code out there people (whatever their skill) can play with it.
• Appreciate there are people who with a bit of help will contribute very much to a project. If their first patches are buggy don't put them down, explain why there is a problem and suggest solutions or places to look for examples of solutions. Every minute spent answering real questions helping someone work on a project will be paid back ten-fold to the project, and incalculably to society.
• Don't forget non programmers. I find it sad that many people when asked "name the most important five Linux kernel people" rarely name some of the most important folk of all - the all to forgotten people who maintain web sites, change logs, mailing lists and documentation are as important.

  Linus says "Show me the code". That is a narrow view of a real project. When you hear "I'd love to help but I can't program", you hear a documenter. When they say "But English is not my first language" you have a documenter and translator for another language.

• Try and separate useful people from the noise. It is hard to separate people trying to help from a mass of pointless discussion and in the Linux 8086 case I definitely did the wrong thing by giving up on that goal. How to remove just those who talk and do not do anything is a research topic 8).

So next time someone wants to vote on a project, or discuss issues for a month and then implement it - be warned. They may end up with the right solution. The odds are however in your favour for carrying on regardless. Just ask them to send you a patch when it works.

Beware "We should", extend a hand to "How do I"...

Alan

[1] As an example of this claim the original author of the Linux IPv6 code used to sit on irc from Portugal playing with a few basic ideas and asking questions. After we helped him figure some of the kernel internals he wrote probably 75% of the Linux IPv6 stack and was last seen working in the USA for cisco.

These are some of my thoughts on the Bazaar model that I figure are worth sharing. Its also a guide to how to completely screw up a free software project. I've picked a classic example of what I think is best dubbed the "Town Council" effect (although town councillors may think otherwise).

There are certain things you have to understand about software developers. The first thing to understand is that really good programmers are relatively unusual. Not only that but the difference between a true "real programmer" and the masses is significantly greater than that between "great" and "average" in many other professions. Studies have quoted 30 to 1 differences in productivity between the best and the rest.

Secondly you need to understand that a lot of the wannabe real programmers are very good at having opinions. Many of them also catch buzzword disease or have some speciality they consider the "one true path". On the Internet talk is cheap.

The third part of any software project is what we shall call "the masses". They range between people who don't program but contribute massively in other areas - documentation, helping users and artwork to the sort of people that are often used to argue that you should require a license to connect to the Internet.

The project I'm going to take as an example of how to screw up completely is the Linux 8086 project. Porting a subset of Linux to the 8086 is one of the worlds more pointless exercises on the whole, and something that started as a joke and got out of hand.

There are a very small number of real programmers with the time and the right (or is that wrong) kind of mental state to contribute to a project whose sole real worth is "Hack Value". As a result of this at any given time the project has two or three core contributing people.

Unfortunately there are a lot of people who think it would be neat to run Linux on an 8086 who feel obliged to "take part". Most of them in this case are in the "wannabe programmer" category as the masses spotted the "silly" factor of the project from a safe distance.

The problem that started to arise was the arrival of a lot of (mostly well meaning) and dangerously half clued people with opinions - not code, opinions. They knew enough to know how it should be written but most of them couldn't write "hello world" in C. So they argue for weeks about it and they vote about what compiler to use and whether to write one - a year after the project started using a perfectly adequate compiler. They were busy debating how to generate large model binaries while ignoring the kernel swapper design.

Linux 8086 went on, the real developers have many of the other list members in their kill files so they can communicate via the list and there are simply too many half clued people milling around. It ceased to be a bazaar model and turns into a core team, which to a lot of people is a polite word for a clique. It is an inevitable defensive position in the circumstances.

In the Linux case the user/programmer base grew slowly and it grew from a background group of people who did contribute code and either had a basis in the original Minix hacking community or learned a few things the hard way reboot by reboot. As the project grew people who would have turned into "The committee for the administration of the structural planning of the Linux kernel" instead got dropped in an environment where they were expected to deliver and where failure wasn't seen as a problem. To quote Linus "show me the source".

If someone got stuck they posted questions and there was and is a sufficiently large base that someone normally has both the time and the knowledge to reply. In the Linux8086 case the developers had long since walled themselves off. Given a better ratio of active programmers to potentially useful wannabe programmers would have rapidly turned some of the noise into productivity. The project would have gained more useful programmers and they in turn would have taught others. As with any learning exercise you are better off having only a few trainees.

There is an assumption some people make that you can't turn the "lesser programmers" into real programmers. From personal experience in the Linux project there are plenty of people who given a little help and a bit of confidence boosting will become one with the best. There are many who won't but enough that will. [1]

The Linux 8086 project has mostly recovered from its 'infestation' and is now a small quiet project, using CVS trees and led by Alastair Riddoch who has been doing a sterling job. With the town councillors De-camped its now possible to ask questions, join in and help the project.

The lessons from this project, and others that went the same way (and sometimes died - remember the earlier Linux word processor projects) are fairly clear:

• Release code right from the start. It doesn't matter if its not very useful. The best way to sort a town council is to simply do the job then tell them it has been done. Linux, KDE and GNOME have all taken this attitude and all done well from it. You can argue about the right way to program for a lifetime. Once there is code out there people (whatever their skill) can play with it.
• Appreciate there are people who with a bit of help will contribute very much to a project. If their first patches are buggy don't put them down, explain why there is a problem and suggest solutions or places to look for examples of solutions. Every minute spent answering real questions helping someone work on a project will be paid back ten-fold to the project, and incalculably to society.
• Don't forget non programmers. I find it sad that many people when asked "name the most important five Linux kernel people" rarely name some of the most important folk of all - the all to forgotten people who maintain web sites, change logs, mailing lists and documentation are as important.

  Linus says "Show me the code". That is a narrow view of a real project. When you hear "I'd love to help but I can't program", you hear a documenter. When they say "But English is not my first language" you have a documenter and translator for another language.

• Try and separate useful people from the noise. It is hard to separate people trying to help from a mass of pointless discussion and in the Linux 8086 case I definitely did the wrong thing by giving up on that goal. How to remove just those who talk and do not do anything is a research topic 8).

So next time someone wants to vote on a project, or discuss issues for a month and then implement it - be warned. They may end up with the right solution. The odds are however in your favour for carrying on regardless. Just ask them to send you a patch when it works.

Beware "We should", extend a hand to "How do I"...

Alan

[1] As an example of this claim the original author of the Linux IPv6 code used to sit on irc from Portugal playing with a few basic ideas and asking questions. After we helped him figure some of the kernel internals he wrote probably 75% of the Linux IPv6 stack and was last seen working in the USA for cisco.

The following was written by RMS and posted to kernel-dev today (Oct 4.)

Intel has a project called UDI: Uniform Driver Interface. The idea is to define a single interface between operating system kernels and device drivers. What should the free software movement make of this idea?

If we imagine a number of operating systems and hardware developers, all cooperating on an equal footing, UDI (if technically feasible) would be a very good idea. It would permit us to develop just one driver for any given hardware device, and then all share it. It would enable a higher level of cooperation.

When we apply the idea to the actual world, which contains both free software developers seeking cooperation, and proprietary software developers seeking domination, the consequences are very different. No way of using UDI can benefit the free software movement. If it does anything, it will divide and weaken us.

If Linux supported UDI, and if we started designing new drivers to communicate with Linux through UDI, what would the consequences be?

* People could run free GPL-covered Linux drivers with Windows systems.

This would help only Windows users; it would do nothing for us users of free operating systems. It would not directly hurt us, either; but the developers of GPL-covered free drivers could be discouraged to see them used in this way, and that would be very bad. It can also be a violation of the GNU GPL to link the drivers into a proprietary kernel. To increase the temptation to do so is asking for trouble.

* People could run non-free Windows drivers on GNU/Linux systems.

This would not directly affect the range of hardware supported by free software. But indirectly it would tend to decrease the range, by offering a temptation to the millions of GNU/Linux users who have not learned to insist on freedom for its own sake. To the extent that the community began to accept the temptation, we would move to using non-free drivers instead of writing free ones.

UDI would not in itself obstruct development of free drivers. So if enough of us rejected the temptation, we could still develop free drivers despite UDI, just as we do without UDI.

But why encourage the community to be weaker than it needs to be? Why make unnecessary difficulties for the future of free software? Since UDI does no good for us, it is better to reject UDI.

Given these consequences, it is no surprise that Intel has started to "look to the Linux community for help with UDI." How does a rich and self-seeking company approach a cooperating community? By asking for a handout, of course. They have nothing to lose by asking, and we might be caught off guard and say yes.

Cooperation with Intel is not out of the question. We should not label Intel, or anyone, as a Great Satan. But before we participate in any proposed deal, we must judge it carefully, to make sure it is advantageous for the free software community, not just for proprietary system developers. On this particular issue, that means requiring that cooperation take us a step further along a path that leads to the ultimate goal for free kernels and drivers: supporting *all* important hardware with free drivers.

One way to make a deal a good one could be by modifying the UDI project itself. Eric Raymond has proposed that UDI compliance could require that the driver be free software. That would be ideal, but other alternatives could also work. Just requiring source for the driver to be published, and not a trade secret, could do the job--because if that driver is not free, it would at least tell us what we need to know to write a free driver.

Intel could also do something else, outside of UDI, to help the free software community solve this problem. For example, there may be some sort of certification that hardware developers seek, that Intel plays a role in granting. If so, Intel could agree to make certification more difficult if the hardware specs are secret. That might not be a complete solution to the problem, but it could help quite a bit.

One difficulty with any deal involving UDI is that we would do our part for Intel at the beginning, but Intel's payback would extend over a long time. In effect, we would be extending credit to Intel. But would Intel continue to repay its loan? Probably yes, if we get it in writing and there are no loopholes; otherwise, we can't count on it. Corporations are notoriously untrustworthy; the people we are dealing with may have integrity, but they could be overruled from above, or even replaced at any time with different people. When making a deal with a corporation, always get a binding commitment in writing.

Given Intel's involvement in I2O, a broad plan to keep hardware specifications secret, it is not likely that they will accept a deal that gives us what we need. In fact, UDI seems like a plan to make it easier to keep specifications secret.

Still, there is no harm in keeping the door unlocked, as long as we are careful whether we let Intel in.

Copyright 1998 Richard Stallman
Verbatim copying and distribution is permitted in any medium provided this notice is preserved.