[PDF]
[PDF]
[PDF]
[PDF]
[PDF]
[PDF]
[PDF]
[PDF]
[PDF]
Wikipedia is the encyclopedia that anyone can edit, but there are all sorts of edits that you aren't allowed to make. Free software projects let you copy, fork, change directions, and create entirely new software. It wouldn't be free software otherwise.
"Open Source stresses that the project isn't really “open” until there is an entire social pathway for making the contributions allowed by the license."Open source has a slightly different focus-- a lot of it is about the organizational culture of development. This is an obvious “in” for people with experience in organizations and the corporate world.
Free software was formerly allowed to focus on software development-- creating organizational overhead only if and when necessary (the majority of free software projects have only a single active developer, or a small handful of contributors.) Open Source stresses that the project isn't really “open” until there is an entire social pathway for making the contributions allowed by the license.
| Free software development | Open Source development | |
| License | FOSS | FOSS |
| Developers | 1 or more | 1 or more |
| Website | Optional | Basically required |
| Source Repo | Ideal | Required |
| Way to Join / Contribute | Not always-- just fork or send a patch | Basically Required |
| Organizational Management | Optional / As needed / To be co-opted | Basically Required / Corporate / Strict |
"Being closer to corporations, Open Source has more corporate culture in its processes."While the “Open source way” may look better for letting everyone be a contributor, it carries with it extra requirements and additional reasons to exclude projects from consideration or people from projects.
There is a difference between implicit exclusion and explicit exclusion. While free software may implicitly exclude contributors, it (like Open Source) allows anyone to fork. Open Source does more to fight implicit exclusion, but adds more vague rules for explicitly forcing people out of the opportunity to contribute based on organizational priorities, even if that person requires (and has) little or no contact with other developers.
"If someone had a contribution, they could typically contact the lead (or sole) developer and offer a patch or offer to join the project."Just as an example, free software used to have more focus on the needs of a single developer writing their own project. If someone had a contribution, they could typically contact the lead (or sole) developer and offer a patch or offer to join the project. They would always be free to create their own version of the software without permission (as permission is already granted by the free software license) but this is usually more effort than simply offering to help.
The lead developer is free to do basically whatever they want-- keeping a project true to its roots. If their personality is not to the liking of other developers, it doesn't necessarily matter-- they don't have to join and the lead developer doesn't have to invite anybody. This works for many projects of small to medium size.
Open Source brings organizational overhead and corporate culture into every project-- you can be the leader of your own project and do what you want to with it, but now you shouldn't-- every project should have a community, a code of conduct (which will be applied unevenly between contributors and leaders, though it may ultimately threaten the structure of the leadership in the distant future) and a dedicated website. With free software, these “requirements” only draw resources when they are justified and considered necessary.
"The lead developer is free to do basically whatever they want-- keeping a project true to its roots."Open Source kind of hates on lone developers.
Fortunately, Open Source brings all this overhead to a project in a way that makes it easier to steer or influence (or purchase) the direction of a project. And since for 20 years, companies like Microsoft have sought to buy, charge royalties for, influence or eliminate the work done by competitors, Open Source gives us (and even fights for) the foot in the door that we need to do so.
George Bernard Shaw once said: “I learned long ago, never to wrestle with a pig. You get dirty, and besides, the pig likes it.” With the very corporate culture of Open Source, big companies are the pig. Open Source is always wrestling with monopolies like Microsoft, and it is of decreasing concern how dirty everyone gets, or how much the pig likes it-- in fact, Microsoft has come out to say they don't merely enjoy wrestling with “Linux”-- they love it.
"They love being able to purchase entire networks of developers, from Linked-In to Github-- which probably contain more valuable data about free/open Source developers than Facebook has access to."And why not? They love royalties from Android devices. They love royalties from USB drives. They love being able to purchase entire networks of developers, from Linked-In to Github-- which probably contain more valuable data about free/open source developers than Facebook has access to.
The amount of influence Microsoft has over all projects on Github, all projects that use .NET or Azure Cloud, many projects that use Python, and all software distributions that run on Intel-based hardware is only increasing. And Open Source continues to pave the way forward for monopolies to own and direct free software-- which was originally created to be independent of control by monopolies.
Free software developers seem to care very little about this, because they have their stripped free software versions of everything open source. So what if we make things less modular, more brittle, more bloated, and more poorly designed? They only use projects with a license allows them to clean up after us, so they're content no matter what we sabotage. We can overwhelm them and send them to clean up mess after mess, with the remaining effect of steering key projects to work more the way we want, and them accepting our changes.
"We can overwhelm them and send them to clean up mess after mess, with the remaining effect of steering key projects to work more the way we want, and them accepting our changes."Free software and Open Source used to have smaller differences between them, and yet for two decades our sponsorships and initiatives (and purchases) have put us directly in the middle of Open Source development.
Since this is fine according to the culture of Open Source, they can't really point to a reason why we shouldn't-- they adopt our rules, we play by our rules, they can't complain. It's too late to change to the rules to exclude us, and we aren't doing anything they didn't welcome in the past.
In exchange for software with more churn, more bloat, less choice and less user control and reliability-- they get “cooler” software tools, larger sponsorships, bigger marketing and events that feature their software-- everything they would enjoy if we took over their world and did things our way. And we still get royalties and the chance to steer development away from things that help our competitors more than they help us.
The plan has never actually changed, but our way of framing it has changed entirely. We de-commoditize protocols. We add features we want and deprecate ones that people rely on, and we tell them to get with the program. We create the same kind of lock-in (in practice) by decreasing the compatibility with trusted development tools and utilities, so we can move more quickly (and drag users along) from one industry fad to another.
"And just as the icing on the cake, we make more money from the development of these projects than the developers sometimes do-- it's as if we hired them ourselves, but all we did was participate and influence."We say this leads to more compatibility-- but it's more compatibility with the things we care about, and less compatibility among the free software ecosystem they created for themselves. Essentially we drag them out of their world, and back into ours. It's a reunion we have already monetized, already seized projects with, already used to purchase things that supposedly belong to everyone.
The shift in these projects demonstrate that they belong a little more to us, than they do to anybody else. And just as the icing on the cake, we make more money from the development of these projects than the developers sometimes do-- it's as if we hired them ourselves, but all we did was participate and influence. Recently, a company used Wikipedia servers as a blank canvas for their own corporate advertising and message. They were called “bastards” and “vandals” and their changes were reverted.
"It takes all the professionalism in the world not to quote what Mark Zuckerberg said when he realized how many people trusted him with their personal lives and information."It's quite different in the world of Free and Open Source software. We can behave exactly like The North Face, do just as much to vandalize and be bastardly, we can even stake claim to their work (and have them agree it is our own!) and become wealthier and gain a heroic reputation in the process.
It takes all the professionalism in the world not to quote what Mark Zuckerberg said when he realized how many people trusted him with their personal lives and information.
Instead, we will just sum up the majority response to our infiltration and increasing control of free software development, no matter how aggressively we buy up and steer projects the way we did before free software entered the mainstream:
“Suckers.”
Relevant quotes from the Halloween documents:
“it provides us with a very valuable look past Microsoft's dismissive marketing spin about Open Source at what the company is actually thinking”
“If publication of this document does nothing else, I hope it will alert everyone to the stifling of competition, the erosion of consumer choice, the higher costs, and the monopoly lock-in that this tactic implies.”
“The parallel with Microsoft's attempted hijacking of Java, and its attempts to spoil the 'write once, run anywhere' potential of this technology, should be obvious.”
“'De-commoditizing' protocols means reducing choice, raising prices, and suppressing competition.”
“for Microsoft to win, the customer must lose.”
“other OSS process weaknesses provide an avenue for Microsoft to garner advantage in key feature areas such as architectural improvements (e.g. storage+), integration (e.g. schemas), ease-of-use, and organizational support.”
“To us, open-source licensing and the rights it grants to users and third parties are primary, and specific development practice varies ad-hoc in a way not especially coupled to our license variations. In this Microsoft taxonomy, on the other hand, the central distinction is who has write access”
“Open source software has roots in the hobbyist and the scientific community and was typified by ad hoc exchange of source code by developers/users.”
“to understand how to compete against OSS, we must target a process rather than a company.”
“Coordination of an OSS team is extremely dependent on Internet-native forms of collaboration. Typical methods employed run the full gamut of the Internet's collaborative technologies”
“OSS projects the size of Linux and Apache are only viable if a large enough community of highly skilled developers can be amassed to attack a problem.”
“This summarizes one of the core motivations of developers in the OSS process -- solving an immediate problem at hand faced by an individual developer -- this has allowed OSS to evolve complex projects without constant feedback from a marketing / support organization.”
“Because the developers are typically hobbyists, the ability to `fund' multiple, competing efforts is not an issue and the OSS process benefits from the ability to pick the best potential implementation out of the many produced.”
“Note, that this is very dependent on:
● A large group of individuals willing to submit code
● A strong, implicit componentization framework (which, in the case of Linux was inherited from UNIX architecture).”
“although debugging requires debuggers to communicate with some coordinating developer, it doesn't require significant coordination between debuggers. Thus it doesn't fall prey to the same quadratic complexity and management costs that make adding developers problematic.”
“Some very large projects discard the `benevolent dictator' model entirely. One way to do this is turn the co-developers into a voting committee (as with Apache).”
“The GPL and its aversion to code forking reassures customers that they aren't riding an evolutionary `dead-end' by subscribing to a particular commercial version of Linux.”
“In particular, larger, more savvy, organizations who rely on OSS for business operations (e.g. ISPs) are comforted by the fact that they can potentially fix a work-stopping bug independent of a commercial provider's schedule”
“Strongly componentized OSS projects are able to release subcomponents as soon as the developer has finished his code.”
“Up till now, Linux has greatly benefited from the integration / componentization model pushed by previous UNIX's. Additionally, the organization of Apache was simplified by the relatively simple, fault tolerant specifications of the HTTP protocol and UNIX server application design.”
“One of the exponential qualities of OSS -- successful OSS projects swallow less successful ones in their space -- implies a pre-emption business model where by investing directly in OSS today, they can pre-empt / eliminate competitive projects later -- especially if the project requires API evangelization.”
“Linux can win as long as services / protocols are commodities”
“The `folding extended functionality' here is a euphemism for introducing nonstandard extensions (or entire alternative protocols) which are then saturation-marketed as standards, even though they're closed, undocumented or just specified enough to create an illusion of openness. The objective is to make the new protocols a checklist item for gullible corporate buyers, while simultaneously making the writing of third-party symbiotes for Microsoft programs next to impossible. (And anyone who succeeds gets bought out.)”
“(This standards-pollution strategy is perfectly in line with Microsoft's efforts to corrupt Java and break the Java brand.)”
“Monitor OSS news groups. Learn new ideas and hire the best/brightest individuals.”
“Linux and other OSS projects make it easy for developers to experiment with small components in the system without introducing regressions in other components”
“OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market.”
“DAV is complex and the protocol spec provides an infinite level of implementation complexity for various applications (e.g. the design for Exchange over DAV is good but certainly not the single obvious design). Apache will be hard pressed to pick and choose the correct first areas of DAV to implement.”
“Systems management functionality potentially touches all aspects of a product / platform. Consequently, it is not something which is easily grafted onto an existing codebase in a componentized manner. It must be designed from the start or be the result of a conscious re-evaluation of all components in a given project.”
“Ease of Use. Like management, this often must be designed from the ground up and consequently incurs large development management cost. OSS projects will consistently have problems matching this feature area”
“How can we leverage the client base to provide similar integration requirements on our servers? For example, MSMQ, as a piece of middleware, requires closely synchronized client and server codebases.”
From https://antitrust.slated.org/halloween/halloween1.html
From https://antitrust.slated.org/halloween/halloween2.html
From https://antitrust.slated.org/halloween/halloween3.html
From https://antitrust.slated.org/halloween/halloween10.html