The Generation Gap
Use of open-source software is mushrooming with the use of Linux. The benefits of open source are becoming more widely known—software quality is improved from peer-review, and future risk is reduced if the source is available.
Open-source projects depend on contributions by motivated, talented developers. Big, important projects like Linux attract many contributors; a project for a software development tool may interest a variety of software developers; UNIX systems gurus contribute to projects for Internet tools. However, a project for software that identifies butterflies may not attract much interest, and the only people who are going to contribute to a project for a company's accounts receivable system are those who are paid to do so. Not all software benefits equally from being open source.
The development of closed-source software will continue. As Eric Raymond observes in “The Magic Cauldron”, some applications (as opposed to operating systems and utilities) can be good candidates for being closed-source. The owner of an application may find more benefit in the software being secret and/or rentable than being open source, at least for a while.
It may be undesirable for the source of a homegrown business system to be open, because it reveals so much about the business's procedures and capabilities. A company may want to keep the source of its business systems confidential.
The owner of an application may want to keep the source closed so that the software can be rented (i.e., licensed for money). Many applications are developed only when someone believes they can make money renting them.
While the benefits of open source are becoming more widely appreciated, closed-source software will continue to be developed.
Closed-source applications can benefit from using open-source components.
Applications generally make use of pre-existing software components. Almost all programs use general-purpose function libraries that come with compilers. Many applications provide a front end using a GUI framework that comes with the compiler or a third party. Some software uses special-purpose libraries to do things like statistical analysis or mapping projections. Many applications include, or know where to find, a self-contained “component” that provides sophisticated functionality, such as a database engine or a map-drawing system.
There is less risk in using a third-party component if it is open source. This is particularly true of components developed by small companies and individual developers. It's very difficult to develop software components and make money renting them. People think, “I don't know these guys. Who knows what they've done in there? My application depends on this functionality.” They also think, “What if these guys disappear? Or find something else to do? Or change the component so I can no longer use it? Or not fix what I need fixed?” They may also think, “This component does what I need to do now. What about next year? What if I want some enhancements? Are these guys going to care what I want?” Being open source addresses these concerns. Developers can see what an open-source component does and how it does it. They always have the option of making improvements themselves (or paying someone to do it).
If a component is open source, its owner cannot rent it. However, money can be made in support services, and the people best poised to do so are developers. A tiny outfit without the credibility to rent a component may find that the best way to make money is to make it open source.
It might be easier to attract contributors to an open-source project for a component than to a project for a narrow application. The users of a component are programmers, and they make up a natural pool of potential contributors whereas the users of a narrow application might be, for example, dentists.
Developers may be motivated to improve the component if an improvement is all that is necessary for the component to be used. Companies using the component may be motivated to spend money to improve it.
Concerns arise over using open-source components in closed-source applications. The most commonly used open-source license is the General Public License (GPL). It grants users the freedom to modify the software and distribute this derived work only if, among other restrictions, the derived work is also licensed under the terms of the GPL. This license ensures that all users of a piece of software, even users of modified versions, have the freedom to see and modify the source code. The Free Software Foundation promotes the use of the GPL.
A component licensed under the terms of the GPL cannot be used in a closed-source application, but some developers of open-source components would like to see them used in any application, open-source or not. The Library General Public License (LGPL, also known as the Lesser General Public License) was developed for this situation. A component licensed under the LGPL may be included in a closed-source application as long as users can get the source for the component, modify it and rebuild the application.
In many cases, however, developers of closed-source applications cannot (or will not) make use of components licensed under the LGPL. Developers of commercial products and companies writing software for their own use frequently don't want any given component badly enough to submit to the restrictions of this license.
There are less restrictive open-source licenses. A component licensed under the terms of the MIT License can be used by anybody for anything. Such licensing makes a component practical to use in closed-source development. Many people in the Open Source community find this license to be subversive, precisely because it makes it practical to bring open-source software into closed-source applications.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- LiveCode Ltd.'s LiveCode
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide