This whole situation has been very funny to watch from the sidelines, but it really feels like this is going to hurt any efforts to get old abandonware source code made public.
This whole situation has been very funny to watch from the sidelines, but it really feels like this is going to hurt any efforts to get old abandonware source code made public.
It might well do that, because the broad "look what happened with Winamp" point could easily stick regardless of the underlying nuance, but the thing that's been confusing me from the start (and...
It might well do that, because the broad "look what happened with Winamp" point could easily stick regardless of the underlying nuance, but the thing that's been confusing me from the start (and IMO led to most of the problems) is that they weren't treating it like abandonware at all. That license only even conceptually makes sense if they think of the codebase as something precious that needs guarding, rather than a long-obsolete piece of freeware...
There's a highlighted comment at the bottom of the article that's (apparently) from someone who worked on it, and the first paragraph will likely sound pretty familiar to anyone who's done corporate software work:
I worked at Winamp till this February. I was the one that suggested the we'd open-source all the player code that belonged to us (so stripping all the Dolby, Intel IPP, etc stuff that wasn't owned by Winamp), so that the community was free to do whatever it wanted with it. I envisioned something à la DOOM GPL release. Amongst ourselves we joked about seeing enthusiasts create a Winamp-for-your-smart-fridge or Linux port. That would have been pretty cool. Instead that proposal was repeatedly ignored by management which couldn't be convinced that this decades-old spaghetti code had nothing more than historical value. "Why would we give our IP away ?! We paid for that". As if VLC, Foobar2000, etc didn't exist ...
It's not really management that is the impedance or rather at least it's not development management. Code "has" to be considered an asset or at least an object that can be associated with capex...
It's not really management that is the impedance or rather at least it's not development management. Code "has" to be considered an asset or at least an object that can be associated with capex instead of opex because then it can be financialized and the effort (labor hours) can be sheltered from impacting revenue and increasing profit.
It's kind of amazing that the owners are still using the same codebase, to be honest. I seem to remember some time after Nullsoft was bought AOL that they actually did a ground-up rewrite of most...
It's kind of amazing that the owners are still using the same codebase, to be honest. I seem to remember some time after Nullsoft was bought AOL that they actually did a ground-up rewrite of most of it with a new major version.
If anything it seems like they should have just abandoned it altogether - obviously, ideally with the source opened up like the hypothetical ex-employee above mentioned. It's obvious that the PC isn't even where they're trying to go at this point because they have it marked as "legacy" on their webpage, underneath links for their phone versions. Literally the only reason I can think of why a user would want to use Winamp today is nostalgia, and I imagine with the changes through the years of different owners, it's not likely to be good at that either.
You're thinking of Winamp3, which was a complete ground-up rewrite using Nullsoft's then new Wasabi application framework. This version of Winamp was unpopular, because it was more resource...
It's kind of amazing that the owners are still using the same codebase, to be honest. I seem to remember some time after Nullsoft was bought AOL that they actually did a ground-up rewrite of most of it with a new major version.
You're thinking of Winamp3, which was a complete ground-up rewrite using Nullsoft's then new Wasabi application framework. This version of Winamp was unpopular, because it was more resource intensive than 2 while missing many popular features like compatibility with old plugins. Its hallmark feature was support for custom UI skins.
Winamp 5 (so-named because the developers believed "nobody wants to see a Winamp 4 skin") went back to the old Winamp 2 codebase, with many Winamp3 features like custom skins backported to it.
It's also worth noting that while Justin Frankel sold Nullsoft to AOL in 1998, he didn't leave the company until 2003. Winamp 5.0 would be the last version of the app he had any involvement with.
Making that source code public doesn't do the community any good when the included license prohibits people from actually distributing their modifications. Great, we can see how the app works, but...
Making that source code public doesn't do the community any good when the included license prohibits people from actually distributing their modifications.
Great, we can see how the app works, but I can only fix a bug, add a feature, or port it to a new platform if you accept my pull request, no forks allowed. I don't know how the people involved here had such a fundamental misunderstanding of how the open source community works. Do they really think there is money to be made off the code base for a 25 year old music player?
They think it's an asset (they likely even have a laughably arbitrary dollar value on it in their books), and the idea of giving away an asset is literally unthinkable to this sort of person....
Do they really think there is money to be made off the code base for a 25 year old music player?
They think it's an asset (they likely even have a laughably arbitrary dollar value on it in their books), and the idea of giving away an asset is literally unthinkable to this sort of person.
There are two obvious things wrong with this viewpoint. First, of course, it's psychopathically antisocial. Human society is essentially built on kindness and generosity. But more immediately, a big pile of code without people with expertise to operate and modify it is literally a liability, not an asset. Attempting to do anything nontrivial with it without sinking six months to a year of (extremely expensive!) software developer time into understanding it first is overwhelmingly likely to cause it to implode in bugs and brokenness.
Spending a year in developer time understanding the existing code is still much easier and cheaper than writing the same thing with all the same functionality again from scratch. The rewrite...
Spending a year in developer time understanding the existing code is still much easier and cheaper than writing the same thing with all the same functionality again from scratch. The rewrite likely takes even longer and also results in bugs and missing features.
This of course only applies if you want to have a program in the future that (roughly) does what your current program does. If what your current program does is all obsolete and the functionality it provides is all useless, then of course it's not an asset and neither changing nor rewriting it makes sense.
In addition to only applying if you want the program in the future to do roughly the same thing, this is highly dependent on how good the existing code is. The phrase "technical debt" exists for a...
Spending a year in developer time understanding the existing code is still much easier and cheaper than writing the same thing with all the same functionality again from scratch. The rewrite likely takes even longer and also results in bugs and missing features.
In addition to only applying if you want the program in the future to do roughly the same thing, this is highly dependent on how good the existing code is. The phrase "technical debt" exists for a reason, after all.
This whole situation has been very funny to watch from the sidelines, but it really feels like this is going to hurt any efforts to get old abandonware source code made public.
It might well do that, because the broad "look what happened with Winamp" point could easily stick regardless of the underlying nuance, but the thing that's been confusing me from the start (and IMO led to most of the problems) is that they weren't treating it like abandonware at all. That license only even conceptually makes sense if they think of the codebase as something precious that needs guarding, rather than a long-obsolete piece of freeware...
There's a highlighted comment at the bottom of the article that's (apparently) from someone who worked on it, and the first paragraph will likely sound pretty familiar to anyone who's done corporate software work:
If I could somehow beat it into the head of every manager in existence that code is a liability, not an asset…
Then we wouldn't get anything done. Which would probably be a good thing.
It's not really management that is the impedance or rather at least it's not development management. Code "has" to be considered an asset or at least an object that can be associated with capex instead of opex because then it can be financialized and the effort (labor hours) can be sheltered from impacting revenue and increasing profit.
It's kind of amazing that the owners are still using the same codebase, to be honest. I seem to remember some time after Nullsoft was bought AOL that they actually did a ground-up rewrite of most of it with a new major version.
If anything it seems like they should have just abandoned it altogether - obviously, ideally with the source opened up like the hypothetical ex-employee above mentioned. It's obvious that the PC isn't even where they're trying to go at this point because they have it marked as "legacy" on their webpage, underneath links for their phone versions. Literally the only reason I can think of why a user would want to use Winamp today is nostalgia, and I imagine with the changes through the years of different owners, it's not likely to be good at that either.
You're thinking of Winamp3, which was a complete ground-up rewrite using Nullsoft's then new Wasabi application framework. This version of Winamp was unpopular, because it was more resource intensive than 2 while missing many popular features like compatibility with old plugins. Its hallmark feature was support for custom UI skins.
Winamp 5 (so-named because the developers believed "nobody wants to see a Winamp 4 skin") went back to the old Winamp 2 codebase, with many Winamp3 features like custom skins backported to it.
It's also worth noting that while Justin Frankel sold Nullsoft to AOL in 1998, he didn't leave the company until 2003. Winamp 5.0 would be the last version of the app he had any involvement with.
Making that source code public doesn't do the community any good when the included license prohibits people from actually distributing their modifications.
Great, we can see how the app works, but I can only fix a bug, add a feature, or port it to a new platform if you accept my pull request, no forks allowed. I don't know how the people involved here had such a fundamental misunderstanding of how the open source community works. Do they really think there is money to be made off the code base for a 25 year old music player?
They think it's an asset (they likely even have a laughably arbitrary dollar value on it in their books), and the idea of giving away an asset is literally unthinkable to this sort of person.
There are two obvious things wrong with this viewpoint. First, of course, it's psychopathically antisocial. Human society is essentially built on kindness and generosity. But more immediately, a big pile of code without people with expertise to operate and modify it is literally a liability, not an asset. Attempting to do anything nontrivial with it without sinking six months to a year of (extremely expensive!) software developer time into understanding it first is overwhelmingly likely to cause it to implode in bugs and brokenness.
Spending a year in developer time understanding the existing code is still much easier and cheaper than writing the same thing with all the same functionality again from scratch. The rewrite likely takes even longer and also results in bugs and missing features.
This of course only applies if you want to have a program in the future that (roughly) does what your current program does. If what your current program does is all obsolete and the functionality it provides is all useless, then of course it's not an asset and neither changing nor rewriting it makes sense.
In addition to only applying if you want the program in the future to do roughly the same thing, this is highly dependent on how good the existing code is. The phrase "technical debt" exists for a reason, after all.