musings:tech:software:fossdevs
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
musings:tech:software:fossdevs [2022/09/18 21:07] claire created |
musings:tech:software:fossdevs [2022/09/21 16:13] (current) claire |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Mozilla’s latest debacle – and why it hurts open source projects ====== | ====== Mozilla’s latest debacle – and why it hurts open source projects ====== | ||
| - | <adm abstract Old blog post> | + | {{template>util:oldblog|date=February 6, 2014}} |
| - | This article was originally published on February 6, 2014. | + | |
| - | </adm> | + | {{page>util:warning:firefox}} |
| Quite a few years ago now, a large open-source project called Pidgin fell prey to one of the bigger pitfalls of OSS – developer-user relations. With commercial software development, a company has resources available to do things like usability testing, analysis of interface design, and most importantly – interact with customers through company representatives whose primary role is to address customer concerns and issues. Software developers are famously stubborn and, for lack of a better word, assholes about their work. Customer liaisons protect users from the rough-around-edges aspects of the developers’ personalities and tendencies, and the end result is that the customers are happy, the software satisfies the customers’ needs, and the developers don’t end up in really sticky situations. | Quite a few years ago now, a large open-source project called Pidgin fell prey to one of the bigger pitfalls of OSS – developer-user relations. With commercial software development, a company has resources available to do things like usability testing, analysis of interface design, and most importantly – interact with customers through company representatives whose primary role is to address customer concerns and issues. Software developers are famously stubborn and, for lack of a better word, assholes about their work. Customer liaisons protect users from the rough-around-edges aspects of the developers’ personalities and tendencies, and the end result is that the customers are happy, the software satisfies the customers’ needs, and the developers don’t end up in really sticky situations. | ||
| Line 13: | Line 13: | ||
| <blockquote> | <blockquote> | ||
| The key here is that you don’t manage us, a fact you are keenly aware of and even reference farther down. //**Another fact is that we have no requirements for any of this beyond what we feel like creating, which is a freedom your managed developers do not have.**// Both of these factors are central to our claim that it is more work than we care to put in and why we ask for people who do want it to write it (at which point we will happily accept it). | The key here is that you don’t manage us, a fact you are keenly aware of and even reference farther down. //**Another fact is that we have no requirements for any of this beyond what we feel like creating, which is a freedom your managed developers do not have.**// Both of these factors are central to our claim that it is more work than we care to put in and why we ask for people who do want it to write it (at which point we will happily accept it). | ||
| - | <blockquote> | + | </blockquote> |
| Unfortunately for the folks at the Pidgin project, when your open-source software creates a large enough user base, your requirements must extend past what you "feel like creating". Your project has evolved past a tiny for-fun application that you hope people will consider using into something much larger, and an inability to accept that is one of the biggest reasons why businesses still reject OSS as an option. The end result of the Pidgin fiasco was twofold – a fork was created to put back the feature (the developers claimed it was “too much work to fix”, even though the feature had previously been there and was deliberately removed), and Pidgin lost quite a longtime users, including myself. While the dent in the user base wasn’t big enough for the developers to fix the bug, the fact remains that this attitude is what prevents OSS from gaining legitimacy in the larger world of technology and end-user applications. | Unfortunately for the folks at the Pidgin project, when your open-source software creates a large enough user base, your requirements must extend past what you "feel like creating". Your project has evolved past a tiny for-fun application that you hope people will consider using into something much larger, and an inability to accept that is one of the biggest reasons why businesses still reject OSS as an option. The end result of the Pidgin fiasco was twofold – a fork was created to put back the feature (the developers claimed it was “too much work to fix”, even though the feature had previously been there and was deliberately removed), and Pidgin lost quite a longtime users, including myself. While the dent in the user base wasn’t big enough for the developers to fix the bug, the fact remains that this attitude is what prevents OSS from gaining legitimacy in the larger world of technology and end-user applications. | ||
