These early programmers were insatiably curious tinkerers and inventors eager to dissect every function of their machines, and to learn every clever workaround or deft coding maneuver that would help them get their job done. The advent of proprietary code that could not be tinkered with, could not be taken apart and reconfigured like a bunch of Lego blocks, was extraordinarily annoying. When they started to hack, whether as teenagers wiring together solenoids, or as defense contractors responsible for fending off the Russkis, hardware and software were both just means to an end. Often, in order to change the programming in one of the early computers or tabulating machines, you had to rewire the darn thing yourself. Typically, this was done by means of a "plug board" -- a panel much like the telephone operator's switchboard with which Lily Tomlin once wrought havoc. If you wanted to change the sequence of operations, you pulled out a plug connecting a wire to another point and plugged it in somewhere else.

It was only later, as software became increasingly less physical, that it was even possible to obstruct programmers from handy access to digital innards. And for the first decade or so after the introduction of the commercially sold computer, few people even realized why that would be advantageous.

"There was no economic value in software," notes Bernstein. "No one recognized software as an economic entity at the time."

IBM's domination of the computer market partially explained the failure to see software as a revenue generator. IBM was opposed to selling anything. Its business model was based on leasing hardware. Leasing made it easier to plan for the future and calculate ongoing revenues. Hardware, software, support personnel -- it was all leased, all bundled together in one monthly package. The inclusion of the software was a carefully thought-out strategic measure that locked customers into IBM. If you used IBM hardware, then you used the software that came with it. And if you spent thousands of hours mastering that software, then when it came time to renew your lease, you stayed with IBM -- why on earth would you want to invest thousands more hours getting up to speed on someone else's software, even if new hardware from another vendor might be technically superior?

Bundled software didn't automatically mean bundled source code -- which was one reason that a group like SHARE was necessary. In addition to providing a means for IBM users to share the code that they wrote individually, SHARE was also an important lobbying tool for getting IBM to make changes, add features and otherwise respond to customer concerns. Especially during the early years, SHARE's membership represented a majority of IBM's most important customers. When it complained, IBM listened. It was a user's "club," explains Frank Wagner -- in the sense of the "club" being a large stick useful for beating IBM about the head with.

During their reunion, the SHARE programmers talked about IBM in precisely the same way that hackers today rail against Microsoft. IBM was the eight-gazillion-pound gorilla. IBM pioneered FUD and the practice of "vaporware," forced bad technology down customer's throats and got away with it all because it owned the market. Even the SHARE members who at one time worked for IBM -- such as Gordon, who put in 25 years at Big Blue, and Bernstein, who did a consulting stint there -- joined the IBM derision. IBM got in the hackers' way.

But in one of the great unpredictable ironies embedded in the history of software, IBM's decision to stop bundling its software with its hardware turned out to be the catalyst that really launched the commercial software industry -- and made proprietary control of source code start making sense to the corporate computing world. In 1969, says Mort Bernstein, as the Department of Justice began to prepare its epochal antitrust suit against IBM, IBM decided to engage in some proactive defensive maneuvers. By unbundling IBM's software offerings, and charging for them separately, IBM hoped to avoid the accusation that it was unfairly leveraging its monopoly control of the market for mainframes.

And in a flash, the commercial software industry was born.

"There was no software industry to speak of until that moment, and then it began to burgeon," says Bernstein.

IBM's act of unbundling presents an intriguing contradiction. Opening up competition undoubtedly contributed to faster growth and greater opportunity for companies looking to make a profit in the world of computing, with a consequent increase in the number of jobs for programmers. But individual programmers ended up becoming further divorced from the hands-on finagling with bits and bytes that made their jobs fun. Not only were they denied access to the source code of commercial programs, but their own responsibilities were steadily being curtailed.

Fun, for programmers, was on the run. As programming tasks became larger, employing thousands of programmers at a time, programming duties became more and more tightly segmented and regimented.

"Programming went from an individual craft to a 'professional' activity that had to be managed," says Bernstein. "As computing became a fundamental necessity in every aspect of commerce and industry, more needs arose. Programmers were asked to provide reasonably precise estimates of the time and resources that would be needed for each development. Based on this, budgets and schedules were produced. Management expected the result to match the estimates within reason. This is a real sea change, from a freewheeling craft performed by 'artistes' to a tightly managed activity supposedly performed by 'professionals.'"

To some observers, the changes in the industry could be placed in the broader, and more suspicious, context of the move to "scientifically manage" office work of all kinds. Following principles established by Frederick Winslow Taylor, an inventor who influenced the creation of assembly-line manufacturing, management began treating programmers as if they were the plugs to be moved around the plug boards, rather than creative visionaries with minds of their own. As Joan Greenbaum, a former IBM programmer, writes in "Windows on the Workplace":

"The first step that management took to gain control over the programming workforce was to divide the conceptual work of programming from the more physical tasks of computer operations. Although this division was put into effect in the aerospace industry in the mid-1950s and subsequently used by companies that had defense contracts, it wasn't until the mid-1960s that it spread elsewhere. By 1965, when IBM began installing the general-purpose System 360, both the more expensive hardware (a large mainframe computer) and the easier to use software (an operating system that could be controlled through commands rather than operators working switches), gave upper and middle managers room to begin enforcing the separation of programming from operations. Operators were to stay in the 'machine room' tending the computer, while programmers were to sit upstairs and write the instructions. Those of us in the field at the time remember feeling that a firm division of labor had been introduced almost overnight."

Proprietary code. Tight divisions of labor. An end to the freedom and fun of the golden age. By the late '70s, things had become pretty bleak for the corporate programmer.

But help was on the way.

"Then the PC came along and the ball game changed again," says Bernstein. "Who has to account for the time they use on their PC? No one! It's an appliance on my desk that is of the same nature as my telephone. And the world of the programmer had come full circle. The PC is what makes the open-source community as freewheeling as it is. Linux and open source could never exist in the world of tightly controlled corporate computing."

The Free Software Project
Read Andrew Leonard's book-in-progress on Linux and open source -- and post your comments.