ブラックボックス
技術体系の変化に伴って、旧来の技術がブラックボックス化することもある。最も顕著な例としては、日本の電卓(電子式卓上計算機)が挙げられる。
電卓という装置は、ボタンを叩いて計算式を入力し、内部の電子回路の働きによって計算結果を画面に表示する。この装置は1960年代から急速に小型化と低価格化が進んで普及した。このようなコモディティ化が進んだ結果、電卓は利益の少ないありふれた商品となった。そのため、日本の電卓メーカーは1990年代後半からは生産拠点を海外へ移し、さらには開発技術者までも現地で採用するようになり、海外で設計製造することが一般的になった。その結果、電卓よりもはるかに複雑で高機能な電子回路を設計できる技術者は国内にいるのに、電卓のように単純な電子回路を低消費電力や信頼性・低生産コストといった求められる性能・条件を満たして適切に設計できる技術者が、日本国内にいなくなってしまったという話さえ出ている。こうなると日本国内では、電卓はブラックボックス化してしまったと言える。
失われた技術によって作られた機械装置は、ブラックボックスの中でも、特に解析が困難なものである。
結局、商用・非商用を問わず、上位のソフトウェアの開発者は、下位のソフトウェアをブラックボックスとして扱っていることに違いはない。
このようなAPI群は、公開された仕様通りに機能する限りは、優れたブラックボックスであると言える。下位のソフトウェアがAPIを介してブラックボックス化されることによって、上位のソフトウェアの開発者は下位のソフトウェアやハードウェアの詳細を理解し、それらを自らの設計に折り込む労苦から解放されるのである。ソフトウェアの発展の歴史とは、このような抽象化の積み重ねの歴史である、と言うこともできる。
逆にそのようなOSやライブラリのAPIが仕様と異なる動作をすると、利用しているソフトウェアにとって非常に根の深いバグの原因になりうる。このようなケースは稀なものではなく、また市場で広く利用されているOSやライブラリのバグを修正することは困難であるから、アプリケーションソフトウェアの開発者はバグを回避してAPIを利用する必要に迫られることもある。
一方でオープンソースのソフトウェアの場合は、アプリケーションソフトウェアの開発者がソースコードを読んで内部構造を理解してバグを修正するという最終手段を取ることは不可能ではない。もっとも現実には、それができるスキルを持つ技術者や、それに必要な時間を割くことのできる開発組織は限られている。