Once the current influential figures fade away, few people will emerge as leaders. Linus was able to make significant contributions to what is now Linux because it gradually grew over 20 years or so. In other words, the expectations and requirements were low. Operating systems were far more simple back then. In fact, all software was more simple.

Today, software is far more complex and far more involved. It is likely that modern operating systems such as Windows have tens of millions of lines of code. It would be an insurmountable task for one or even a handful of engineers to complete such a project. Only a large corporation would be able to afford the significant investment needed. The corporation would probably make the software proprietary in order to profit, which it would need to make the risky investment worthwhile.

Since software is becoming more complex and harder for a single person to achieve something great, fewer projects will be started. With fewer projects started there is a lower likelihood of there being useful software for people to adopt and use. Over time, proprietary software will out compete open source alternatives and open source adoption rates will dwindle.

With lower demand and fewer users, developers will be less likely to make contributions. With fewer developers, there will be even less quality software to compete with proprietary counterparts. The open source community will be discouraged with the lack of adoption and the movement will have less of an impact than it has today.

Instead, several key players will contribute a significant amount to open source packages. LinkedIn, for example, has begun deploying node.js on its servers, which is not only open source, but has significantly increased its efficiency. Useful open source packages that can not only cut costs, but deliver value will be a major area of investment for large companies.

Furthermore, open source software will continue to rely on commercial software, but will be more innovative and original. Node.js is a great example of innovation within the open source community. It has completely changed the architecture of servers, something that has not been rethought in several years.

The high quality and utility of open source software will lead to an increase in its adoption by enterprise users. Businesses want to cut costs and increase efficiency. High quality open source software will mean fewer bugs. More useful software will mean better, faster, and cheaper software, all of which will contribute to more profit.

Developers will also contribute more to open source software. Since enterprise users will incorporate more open source software into their own work, they will see open source involvement as a key characteristic when hiring software engineers. As a result, more and more engineers will delve into the open source community to not only learn more, but also to be more hirable.

A larger number of developers will mean higher quality products, as long as open source standards are maintained. As mentioned above, higher quality products will lead to greater enterprise adoption. Therefore, the rate of adoption will probably increase exponentially. Open source will not merely be a community or a subculture, but will be an integral part to the software industry.

Some of these claims have gotten a little absurd. Apple, for example, has patented rectangular electronic devices with rounded corners in Design Patent 504,889. Fortunately, the August 24, 2012 verdict did rule the rectangular electronic device patent as being infringed, but several of the aforementioned patents were infringed. These included the iPhone’s “Bounce-Back-Effect”, “On-screen Navigation”, “Tap To Zoom”,”home button, rounded corners and tapered edges”, and “On-Screen Icons”.

Apple won approximately $1 billion from Samsung in the verdict. Since then Apple has filed another lawsuit, although its injunction request to block Samsung smartphones was denied. In addition to legal fees, penalties costs companies billions of dollars each year. According to a New York Times article “spending by Apple and Google on patent lawsuits and unusually big-dollar patent purchases exceeded spending on research and development of new products.” This money would be better spent on innovation, which would not only helps these companies, but help society by producing stronger products.

People question the competency of lay juries to determine the outcomes of these cases. How were they able to determine who should win a complex patent case with little prior experience? The jury made the decision quickly, which has raised doubts about the case being discussed thoroughly

Furthermore, many have questioned the validity of these patents. Do they satisfy the patent requirements of novelty and non-obviousness? Should they have been granted in the first place? If the patents should not have been granted in the first place, would any of this have happened? Perhaps the issue isn’t with patent litigation, but instead lies at the patent approval process. The USPTO suffers a tremendous backlog of patents and competes with top companies for engineering talent.

In order to save innovation something needs to change.

Many people wonder whether selling open source components would be a viable business. For example, selling an iOS Networking Library or a UI Component for a few bucks, depending on the complexity of the component. The quality of the component would be guaranteed by testing and peer reviews/verification. Many companies offer similar services, but in a compiled package. This does not allow developers to modify the software to add functionality. However, this “marketplace” would provide source code once you’ve paid for it, so you can modify functionality endlessly.

One drawback to a marketplace like this is once people pay, they might distribute it on the Internet for free. However, with prices starting as low as a dollar and the average being $4, I have a feeling that the costs will be trivial enough that developers would be willing to pay for it. A counter argument is that developers will end up using several components in a single program, which could cost $20 for example. Do you think people would illegally distribute the source code?

Another drawback is whether engineers would use this in the first place. Would anyone pay for something they can build themselves? Not only would this same them lots of time to work on more interesting projects, but companies could also pay for it. Companies would have an incentive to buy it because engineers could work on integration and adding features instead of writing already-available code.

Personally, I am unsure whether or not I would pay for this. It would make my life a lot easier, but I also would feel like I could easily do it myself. Yeah, I pay to eat at restaurants instead of cooking the food myself, but you are buying an experience there. I guess in this scenario I am buying time, which as far as I know is pretty valuable.

Would you pay for open source components? Why or why not? Comment below!

Patents: These are intended to promote technological innovation and new inventions. The idea is to provide a 20 year monopoly – exclusive rights to produce the idea – in exchange for public disclosure. This allows the patent holder to prevent anyone from making, using, selling, or importing whatever the patent grants. Violating a patent is known as patent infringement.

A patent has three basic requirements to be granted: usefulness, novelty, and non-obviousness. However, this does not mean that all patents have these requirements, which among other things has lead to patents being a highly controversial topic. The United States Patent and Trademark Office is responsible for granting patents and trademarks. Many people are opposed to the way patents are granted. In fact, The Economist has compared the current patent system to a “time-consuming lottery,” based on its seemingly arbitrary grants.

Some common patents in software are MP3 encoding format, LZW compression, and even GIF. In fact, the PNG (Portable Network Graphics) image format was created in order to serve as an alternative to GIF with no patent licensing required.

Patent Licensing: If you have a patent you can license your patent rights. This allows others to use the innovations granted in the patent. Typically this is done in exchange for some asset, often money, for a specified duration of time.

Copyrights: While patents provide protection over an idea, copyrights provide protection over the expression of an idea. As a programming analogy, patents would protect an algorithm, while copyrights would protect an implementation of that algorithm. Copyrights are granted to anything that is created and last from about 90 to 150 years. This does not protect against others who coincidentally and independently produce an identical body of work. It is important to note that copyright protection is granted automatically.

Software License: The idea of a software license is different from patent licensing, but shares the same idea. A software license grants and governs the usage of software. Since all software is copyright protected just by being written, without a software license using software is copyright infringement, otherwise known as piracy.

Trademarks: Trademarks have to do with associations or names surrounding a product. For example, Apple recently bought the rights to the “Lightning” trademark from Harley Davidson in order to use that name for its new connector. These have little to do with actual software and more with advertising.

1. GNU General Public License – Originally written by Richard Stallman, the GPL license is the most commonly used license and has several different versions. Under the GPL license it is generally required to release source regardless of whether or not the source was modified. This is known as copyleft or the “virality” clause because derived works must use the same license. This is known to be a restrictive license.
2. Apache License – First written by the Apache Software Foundation in 2004, the Apache License requires the provision of copyright, patent, trademark, and attribution notices from the original file. There is no requirement to release source code. The Apache License is commonly referred to as a permissive license.
3. Berkeley Software Distribution Licenses – The original BSD license was named after the Berkeley Software Distribution, a Unix-like operating system. These licenses are a family of permissive free software licenses, meaning that they have few restrictions. The New BSD License allows limitless redistribution only if it has both its copyright notices and its original warranty disclaimers. The New BSD License also restricts the use of the names of contributors to advertise a derivative work without explicit permission. The Simplified BSD License omits this clause.
4. MIT License – The MIT License is the most succinct and probably the most permissive license. The MIT License merely requires that derivative works be accompanied by the license. It has no distribution or usage restrictions. Below is the full text of the MIT License:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Open source software often uses ideas from commercial software

Many people believe that the open source community and commercial software cannot peacefully coexist. This is far from the truth. In fact, open source software relies heavily upon closed, commercial software for money, talent, and ideas.

Money

I was surprised to find out that Google is paying Mozilla about $300 million in royalties each year. Google pays to be the default search engine in Firefox. Mozilla uses this money for operating, equipment, and marketing costs. These marketing costs are used to sponsor conferences. In 2011, Mozilla sponsored PyCon, the python programming language conference. These sponsorships help developers become more aware of and impressed by open source foundations. They then are more likely to make contributions to the codebase and sustain open source projects.

Talent

About 50% of open source contributions are made by professional software engineers. It’s no secret that commercial software companies pay engineers very well. More and more students are choosing software engineering as a career path because they enjoy it and to make money. If software engineering wasn’t paid well, perhaps fewer and fewer engineers would choose to do it. With fewer developers, less open source code would get written.

Also, commercial software companies provide software engineers with relevant experience. At work, engineers can learn best practices and code for a couple of thousand hours per year. Best practices emerge and engineers quickly learn the most effective ways to write software. When contributing to open source software, engineers can use the skills they hone at work and make those code repositories better.

Ideas

From Linux copying UNIX to GIMP imitating Photoshop, a lot of open source software copies innovative ideas from proprietary software. Open source software does not have the same economic incentives or the resources to do so. First, it is uncertain whether highly original ideas will have a user base. Open source developers do not want to begin a huge undertaking if few people are interested. It just results in wasted time. For commercial software developers it can lead to discovering a new market and lots of profit.

It is also difficult to get certain things like polishing user interface, fixing hard to find bugs, and implementing boring features because open source developers choose what they work on; this is what makes open source successful. No one wants to work on something they don’t want to in their free time. Commercial software companies pay its engineers to work on tasks they don’t want to, which guarantees they get done (if you want to keep your job).

The open source software community depends heavily on the commercial software companies both in terms of resources and ideas. Many commercial companies are beginning to embrace the open source movement and utilize some its additional developing power. Younger developers are attracted to companies that open source their modules and some companies use this as a marketing tool to attract new talent as well. Though some believe that the open source methodology will overtake traditional proprietary software, I don’t think that’ll happen for a while.

More Engineer Hours

Open source software can often find and solve many bugs rapidly

It used to be the case that computers were prohibitively expensive and developers were only a fraction of the cost. Today, however, engineers are certainly more expensive than computers. The open source community has 1000′s of skilled developers all over the world. More developers means more hours being spent coding and hopefully more results (if they are skilled). This also results in fewer bugs based on Linus’ Law, “given enough eyeballs, all bugs are shallow.”

Intrinsic Motivation

Developers that contribute to open source software are more intrinsically motivated because they get to choose something they are interested in working on. At work, software engineers are told what to do. Working on open source software allows engineers to choose problems they find interesting and challenging.

Internal Quality

The actual code itself needs to be easier to read and more modular in order for it to be successful. In small production teams, code is only seen by a handful of developers or sometimes a single developer. If this is the case, code readability and modularity doesn’t matter. However, if thousands of people are reading code, it needs to be able to be easily understood. Modularity also allows people to contribute code independently of each other that still works well together through established protocols.

No Deadlines

When trying to meet deadlines, engineers often need to make sacrifices. Whether it be a sacrifice in terms of security, external quality/usability, or internal quality/code the software usually ends up with some sort of drawback. Once the schedule outpaces the engineer once, it is easy for this pattern to continue. These flaws pile on top of each other and occasionally this can lead to big security holes, unreadable code or very buggy software, all of which are difficult to fix.

Linus Torvalds, the primary developer behind the Linux kernel

Whenever I think of open source contributors I think of the the typical image of hardcore programmer, or Linus Torvalds. After doing some more research, I discovered just who exactly contributes to open source software and why they do it:

Open source contributors are largely males in their 20s-40s, who are motivated by learning and find it fun.

Gender/Age and Education

First off, 95% of contributions are made by males; sadly, only 5% female. Most contributors are in the age range of 20-40. Roughly half have college degrees, a quarter have higher education (Masters, PhD, etc.), and a quarter have no college education.

Professional Programmers?

Salaried/Contract professionals constitute 34%. Hobbyists come in at 28%, which I was surprised by considering they don’t do it professionally. Surprisingly, 16% are paid to develop open source software (I think these are people that work at Mozilla for example). Students contribute a significant amount at 14%, and 8% is the mysterious “Other” category.

Countries

Country data was very difficult to find and what I found was largely conflicting. A large number of Linux contributions apparently came from Finland (in case you didn’t know Linus Torvalds is Finnish). Red Hat claims that France is the most active open source community and put the US at ninth, which was surprised by. Some reports state the United States has the highest absolute number of contributors, but it’s population is almost 60x Finland’s and 5x France’s. Overall, this is hard to determine from the data I could find.

Motivations

• “Human Capital”, or what I called skills and learning, is the number one motivating factor across the board. I was somewhat surprised by this, but it makes sense. Programmers need to stay on top of trends, languages, and paradigms in order to have a job. Also, engineers typically enjoy learning, and it is easy to learn a lot while working on a new problem, with smarter individuals, on a large codebase.
• “Self-Determination”, or what I interpret as fun, was the second highest motivator. This doesn’t surprise me as most programmers like programming and getting to choose the problem you work on or working with a new technology is typically perceived as being fun.
• A little more than half (51.9%) of the respondents said they wanted to build a network with peers (not on graph).

Below is a bar graph depicting the percentage of people who reported that factor as a motivator to contribute to open source software.

The data in this blog post was taken from a study published by Alexander Hars and Shaosong Ou of the IOM Department at the University of Southern California, Marshall School of Business. The paper can be found at: http://csdl2.computer.org/comp/proceedings/hicss/2001/0981/07/09817014.pdf

Some of the most used software is open source

From Rails to Python to Apache to MySQL, software we use on a daily basis is increasingly more reliant on open source development. These projects have several million line of code, a few thousand contributors, and are coherent. How do these open source projects stay organized? Modularity and established protocols.

Fred Brooks managed the development of IBM’s mainframe computer the System/360, which was one of the earliest and most influential computers in history. Later on, he wrote about the development process in his well-known book The Mythical Man-Month. The book claims that adding more developers to a software project increases its vulnerability to bugs exponentially.

So if open source projects have thousands of contributors it should be very prone to bugs and be overwhelmingly complex. Open source software avoids this by following a key principle in the Unix philosophy: the Rule of Modularity. This yields tiny parts, or modules, connected through a common interface/protocol.

Breaking the project into modules allows people to work on disparate parts without any reliance on each other. To make these disparate parts work together standards and protocols have to be established from a top-down approach.

And how do these protocols and standards stay consistent for several years?

The open source community favors technical rationality–making decisions based on efficiency and merit as opposed to politics found in closed software. Much of the discussion surrounding open source software are evaluating the technical choices.

Conway’s Law states that the technical structure of a system emulates the structure of the organization developing it. According to this law, given that the open source community favors technological rationality, its software should also follow technological rationality, which drive development.

Coordination problems easily emerge in the discussion and a agree upon interface is established allowing everything to work as planned. That is how modularity and protocols allow open source software to stay organized.

How do you think open source software stays manageable? Is it worth it to make your software more modular?