The Generation Gap
The people who write open-source software are the hackers—the community that had its origins at the MIT AI Lab.
It began in 1959, when a group of people in the Signals and Power group of the Tech Model Railway Club got access to a small computer—the TX-0. This was different from the big IBM mainframe, where one submitted a deck of punched cards, then waited around for their own job to run. With the TX-0, one could actually sit at a console and deal with the machine directly. The club loved it. They loved the challenge of trying to make it do what they wanted, and the feeling of power when it finally did. They started with practically nothing in the way of an operating system. They wrote their own system functions and simple tools and used them to build better tools.
These were the original hackers—a group of people who thought programming was the most important thing in the world. They were explorers. They were a community. They shared information and ideas, and they shared the belief that if information and ideas move freely, everyone benefits. They shared the product of their work—tools, utilities, experiments, games and jokes. A person's standing in the hacker community was based on almost nothing except that work.
People moved in and out of the community at MIT. Some hackers moved to other institutions and kept in touch via the ARPA-Net (a precursor to the modern Internet). The community became a network community and stopped having a specific geographic location. As Internet access became available to anyone in college, this community grew. The Internet became the focus for many hackers; its infrastructure was developed largely by hackers. Now the focus has shifted to Linux, and the software that runs under it.
As Eric Raymond describes in his paper “Homesteading the Noosphere”, the hacker culture is a gift culture—status within the community is based on what a person creates and gives away. Open-source software is the product of people programming (testing and debugging) and giving away the results. Most of this work is done in the spare time by people who also hold paying jobs.
People contribute to open-source projects for a variety of reasons: fascination with the problem, desire for a meaningful programming project, wanting to participate in the community, an opportunity to prove themselves, or a desire to use the new software personally. They continue to contribute to the community and culture because it works. People who have never physically met, each doing whatever they feel like doing, can in their spare time create great software.
The General Public License is seen as strongly supporting the hacker culture. It can be difficult to attract contributors to a project for software that is not licensed under the GPL. It can be particularly difficult for projects involving components licensed under the MIT license.
In the past, people in the Open Source community were the primary users of open-source software, but this has changed. Many new Linux users are not programmers and many of them will never contribute to open-source projects. Open-source developers don't feel cheated by this; they feel vindicated. To a hacker, the ultimate measure of software's worth is whether people find it useful.
Linux has been very good for the Open Source movement. Huge numbers of people are trying it. Many more are hearing about it. People are pushing for its use where they work. More and more people are learning about the Open Source movement and its values, and becoming involved in open-source projects and a part of the Open Source community. The community benefits from increasing use of open-source software, whether that use directly supports open-source development or not. The community benefits when dentists, for instance, use Linux.
Suppose, however, that a dentist and I want to get together and write an application that implements his top-secret super-duper billing technique. The technique is a trade secret, so the application must be closed source. Now, suppose that as I'm writing it, I want to use an open-source library to do statistics. If this makes my billing application a “derived work” and I'm going to get a bunch of licensing hassles, I'll do something else. I'm not trying to derive a new statistics library—I just want to use it. If it's a good thing for a dentist to run his billing application on Linux, why wouldn't it be a good thing for the application to use open-source parts?
The more people who use open-source components, the more people will decide some component needs a wee change and they should do a little work for the open-source project. If open-source components are used in business applications, businesses will, from time to time, find it in their interest to pay someone to work on the components. This is good for the Open Source movement.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Introduction to MapReduce with Hadoop on Linux
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?