When I first started working on free software, in 1979, I was part of a community in which that was the accepted norm. This was at MIT's AI lab at the end of the so-called "golden age" of the lab, just before most of the hackers left to form Symbolics. Giving away software was the norm in that environment for several reasons. The first was that everyone was getting paid to develop these systems, and that no one profited from them. There was no particular incentive to hide information (at this time there was virtually no commercial software market).
The second reason is that this was a small community of people who were in the habit of working and developing ideas together. This community idea was very important, because it bound together a bunch of people who were, by and large, social outcasts in most other contexts. In this community, they were the mainstream. And in this community, code sharing was the norm. Code was one of the languages in which these people conversed. In this context, hoarding would have been seen as a withdrawal from the community -- a deliberate refusal to communicate.
Subsequently, the community was broken over precisely this issue. Most of the lab's hackers left to form Symbolics. Some people got left behind, including virtually all of the faculty, but most notably Richard Stallman and Richard Greenblatt -- each was brilliant, but was less socially adept than the average in that community.
The third reason that software sharing was seen to be important is one that everyone still understands today: it led to the development of better software. Those genius hackers understood, very clearly, that the most important factor in producing good code was the feedback from their users. And that feedback was most effective when the users had the code in their hands. The systems developed at the AI lab were powerful primarily because of this feedback loop, and because the users were themselves gifted programmers. Thus it wasn't surprising that Symbolics continued to give away the source code for their system, even when it was their most important product. They understood the need for the source.
But just giving the source wasn't enough, because now there were additional structures involved in the software-creation process. There were marketing and profit issues, of course. But the extent of the feedback between the programmers and users was reduced, because the programmers were no longer present, no longer part of the community at the lab. (Or, from another point of view, the users were no longer part of the programmer's community.) There were still strong ties, of course, but these were now on the level of individuals rather than a structural feature of the community. For example, new graduate students weren't automatically inducted into the programming community, but instead became isolated users depending on Symbolics as a vendor. This kind of arms-length relationship is the antithesis of community.
All of these motivations for sharing programs are still in use today, even though the context is a little different. Of the three, only the third is widely understood, thanks largely to the efforts of Eric Raymond and others of the open-source movement, who have promoted the practical aspects of free software while marginalizing freedom and community issues. Thus the idea that the community itself can be a motivator isn't always understood.
People join together to help one another because it feels good, and because it builds community. Church groups, pro bono work, and volunteer work are examples hinting at the pervasiveness of this drive; I am sure there are many more. Talk to young people who give freely of their time and energy for social causes, and you will hear that they want to make the world better, to make a difference. People want to give.
I believe that any vibrant community has an altruistic component, in which people give to the community without asking for a direct repayment. Altruism of this sort is a social mechanism that has survival value. Giving freely to the community strengthens the community, and strong communities translate directly to individual security. This is true even when the community doesn't provide physical security -- in our society, where physical security often isn't a major issue, emotional security is essential.
Eric Raymond talks about this as a "gift culture", but from his point of view a gift culture is unusual, even rare. The reason that Raymond can say this is that our society isn't very community-oriented. The mainstream, at least today, is very individualistic. Raymond is a libertarian, and in some sense libertarians are the mainstream -- they believe in the rights of the individual without having any clear theory of the role of the community.
But I think that Raymond is wrong about gift communities being unusual. What's unusual is not the gift community, but community itself, which has been steadily eroded over many years. Strong communities themselves rely upon the gifts of their members to bind them together. If the members don't give of themselves, or if they give sparingly, the community won't thrive. So the gift community isn't unusual, it's in fact the norm for a strong community.
The flip side of this is that selfish behavior weakens the community. This is obvious. Why should others in the community trust you if you take their gifts and give nothing in return? People fear selfishness because it weakens community and trust.
One thing that I think is undervalued is the role played by the GPL in combating selfishness. A recent study showed that the GPL is the single most popular free-software license. Why should that be? What motivates people to prefer the GPL to any of the other free-software licenses? Especially when all the free software licenses give the end user approximately the same results.
Look for a moment at the perennial license wars that go on within the community. There's really one primary war going on, between advocates of the GPL and advocates of the BSD license. (All the other licenses are essentially variants of the BSD license.) The difference between these licenses is that the GPL is intended to maximize the community's interest, and places some restrictions on code developers to accomplish this. The BSD license maximizes the rights of developers, but makes no effort to protect the community.
What's interesting here is that most free software developers choose the GPL, even though the BSD license is better from a selfish point of view! I think the GPL is popular precisely because it protects the community against selfish behavior. Developers who use the GPL are saying, in the clearest possible way, that their motives are not selfish, that they can be trusted to participate in the community without holding something back for themselves.
Another major motivator is the creative act itself. Creation is unbelievably addictive. And programming, at least for skilled programmers, is highly creative. So good programmers are compelled to program to feed the addiction. (Just ask my wife!) This compulsion is mostly independent of reward, but as Stallman has previously commented, given the choice between programming with and without rewards, most programmers will choose the former.
However, proprietary programming is highly constrained by deadlines, customer and marketing demands, and many arbitrary factors that have little to do with creating a program that is a work of art. In fact, it's widely recognized that industry pressures have resulted in a sweatshop atmosphere in which programmers must practice "slash and burn" techniques to get something out the door as quickly as possible. This leaves little room for building art, and if it is to be considered creative at all, it is a very meager meal.
Creative programming takes time, and careful attention to the details. Programming is all about expressing intent, and in any large program there are many areas in which the programmer's intent is unclear. Clarification requires insight, and acquiring insight is the primary creative act in programming. But insight takes time and often requires extensive conversation with one's peers. In industry, time is unavailable, one has to work with only a small set of peers, and no one can afford to spend time thinking about what something means. It's necessary to make something that works, more or less, and move on to the next thing. But the fact that the programmer didn't fully understand the problem at hand means that there is a portion of the program that works by accident rather than by design. And those places are where the bugs live.
In contrast, free-software programmers are relatively unconstrained by time. Community standards encourage deep understanding, because programmers know that understanding is essential to proper function. Free-software programmers are programming for themselves, and naturally they want the resulting programs to be as good as they can be. And for many, this is the only context in which they can write a program that expresses their own vision, rather than implementing someone else's design, or hacking together something that the marketing department insists on. No wonder programmers are willing to do this in their spare time. This is a place where creativity thrives.
Creativity plays another role in the programming community: programming, like architecture, has both an expressive and a functional component. Unlike architecture, though, the expressive component of a program is inaccessible to non-programmers. A close analogy is to appreciate the artistic expression of a novel when you don't know the language in which it is written, or even if you know the language but are not fluent.
This means that creative programmers want to associate with one another: only their peers are able to truly appreciate their art. Part of this is that programmers want to earn respect by showing others their talents. But it's also important that people want to share the beauty of what they have found. This sharing is another act that helps build community and friendship.