https://www.imperialviolet.org/2015/10/17/boringssl.html
Seems like it's been a useful concept.
http://projects.cerias.purdue.edu/poly2/
Especially see Section 3.6 of the main paper:
https://www.acsa-admin.org/2003/papers/72.pdf
It's an old technique of mine, too. Just edit out all that shit so it returns with an error message telling me what the hackers were trying to use with whatever access they got and from where. :)
This is prevalent in the embedded OS market with vendors that sell commercial Linux licenses. Many will take a stable Yocto distribution and strip out unnecessary pieces to reduce its weight to suit customer specifications.
Often times the OS vendor will then have to go in and add code to meet standard/certification requirements set by the customer. They'll also generally have to add certain libraries and snippets of code for hardware/middleware-specific integration.
I'm not an embedded engineer, but from my convos with engineers/execs I have to believe its exceedingly rare that a company could simply strip out pieces from an open source distribution, not add anything proprietary, and sell the resulting code to a customer.
Less code = less complexity, less side effects, less maintenance, and less bugs.
Sure, you have to do it without loosing any useful functionality. As a software ages, it becomes bloated, there is a lot of copy'n paste, features aren't useful anymore because the business changed.
OpenBSD project seem to be doing the right thing (as they always did, imho) by deleting a lot of code from the base and not letting it to rot.
Using frameworks/libraries often can reduce the amount of code one has to write to perform a certain task, but it also can greatly increase the total complexity of the system. The OP is talking about reducing total complexity, which may mean increasing local complexity slightly.
Which is fine for you to do of course but it is probably inaccurate to assign no value to the code you are removing. Someone took the time to write it. People don't spend their time writing code for no reason. That code may have no value to you personally but it has value to someone.
Few people write small programs anymore. UNIX, the OS that runs the internet and on which the "cloud" depends, is a time-capsule full of small programs. What this might mean is left as an exercise for the reader.
Today, large programs are celebrated without question.
Gratuitous complexity can be disguised as "productivity" and pitched as value creation. At the very least it can be a source of fascination for futurists. Any liabilities created in the process can be easily explained away.
Among the many things that can be done with this output, one of them to is to make small programs from the larger ones. As far as I can tell, this is not being done.
For myself, I have taken large, open source programs and gutted all the needless features in order to produce the small programs I want.
My goal is less complexity. Simplicity is a loaded term. For myself, this process of incrementally reducing complexity "creates value". It is an intellectual exercise, there is a sense of productivity, and yet almost no code is written.
Software companies are full of developers who cut, paste and compile. Today many of them are working with open sourced code. The software company I aim to start is comprised of "programmers" who also work with such open sourced code, they only cut and compile.
EDIT: Whenever I see the "Who's hiring" thread I always wish I could put in an entry for this. The vision I have is a group of "early employees" with day jobs. Absent connections and name dropping no VC would ever fund this. No one will be paid to do this "negative coding" work until we secure our first government or Fortune 100 contract and they see the results. And even then I could not guarantee the results would be appropriately valued. But were this fictional company to succeed, those early employees could claim they were an integral part of a monumental paradigm shift.
EDIT 2: The fictional company does negative coding on single programs to reduce them in size or to break them up into smaller programs and is not limited to the embedded market or driven by resource constraints. Selecting parts of an open source OS distribution to create a new distribution is a different idea and of course many companies have been doing that for many years.