5 ms·

Wrong, wrong, wrong. Absolutely wrong. You said that Netatalk in its UMich days was "once successful" and "fully mature," and that its previous users didn't nee

Wrong, wrong, wrong. Absolutely wrong. You said that Netatalk in its UMich days was "once successful" and "fully mature," and that its previous users didn't need to maintain it anymore. Neither of those assertions are true. Fully mature? Reference my earlier post on CNIDs I never ran into the CNID issue when using Netatalk on our Mac OS 8 systems. By the time Mac OS 9/Mac OS X came around, the project's necessity was already diminishing and I (like many others) had long since stopped paying attention. I seem to recall contributing all of one patch to netatalk, and that wasn't because I was an evil corporate code stealer -- we just didn't need an AFP server anymore. Fortunately a few motivated developers wrote the CDB and DBD backends, and the problem disappeared. The BSD license is why they didn't contribute the fixes back, because they didn't have to. Vendors had absolutely no reason to use a GPL fork unless new contributors then implemented considerable useful code under the GPL. In other words, making it GPL wasn't the magic that got vendors to use the GPL'd software, providing them more value for free did the trick. But vendors ship tens of thousands of units every month running the GPL'd version, so it wouldn't hold water. How many of those actually significantly contribute back to the project? I count three active committers.

Scramblejams 17y ago
"I never ran into the CNID issue when using Netatalk on our Mac OS 8 systems." That's good! Unfortunately I did, and so did many others. A quick perusal of the old mailing lists will turn up plenty of this. We tried a test rollout in a division of a Fortune 50 company, and our backups saved us -- when a user noticed a file was missing, that is. "I seem to recall contributing all of one patch to netatalk, and that wasn't because I was an evil corporate code stealer." Excellent! All patches were appreciated. We could've used more of that. (And we'd have happily accepted patches from the storage vendors, they just wouldn't play ball. I don't think any of us felt the corporations were "evil," just that they were behaving like ... moochers.) "How many of those actually significantly contribute back to the project? I count three active committers." First, that's misleading. The three active committers take patches from others as they please. So to get a true picture you'd need to go through the mailing list and see where all the patches originally came from. And I haven't been involved in the project for some years, so you'll need to go research that yourself. Second, you've completely missed the point. And it's one you should really like. Netatalk entered a sick state because the people who had the desireable patches chose to hold them back. The BSD license allowed them to do so. Then other developers came in and said, we'll commit our patches, but we want a guarantee that those who ship our work will have to do the same. And that was enough to motivate them to make Netatalk fully mature -- every significant enhancement/fix implemented privately became available publicly, and more, thanks to those devs. And what was the outcome for ALL of Netatalk's users? The storage vendors were happy because they could stop maintaining their private forks and just ship from upstream. The users were happy because all these bugs were fixed and they had a responsive place to seek help. The devs were happy because they were assured that they were now on equal terms with the storage vendors. Whether the vendors continued development or not wasn't actually the issue. So everybody won, the users, the developers and the storage vendors. No, the GPL didn't write the code, but the BSD license allowed the code to remain private, and that's where everybody started losing. The GPL assured everyone that that couldn't ever happen again, which, as it turned out in this case, was a necessary precondition to success.
Scramblejams 17y ago
By the way, I think I've omitted something from the discussion until now that may help you understand why the GPL was perceived as the right license at the right time for Netatalk. The initial influx of developers after Netatalk's long moribund state was mostly caused by community discussion of the CNID issue. As users' hard drive sizes increased, more files were stored which increased the likelihood of triggering the bug which resulted in data loss. So more and more people hit the mailing list, wondering what was going on, what was going to be done about it, and were very anxious because not only was it a data loss bug, but a silent data loss bug. Even if users kept backups, they wouldn't know to use them unless they happened to notice a file was gone. This made Netatalk feel like a ticking time bomb. As the conversation's pace quickened, it attracted a handful of new developers who had a stake in Netatalk's success. As users compared notes and the new devs ran tests, they learned, as mentioned before, that some storage vendors had been aware of and resolved the issue in their products, but refused to share the fixes. Users who had lost files became angry. Why? The feeling was that these vendors had benefited from Netatalk for a long time, and now when the community needed help, the vendors were turning their backs on them. I think anger was an understandable reaction. After all, we're not talking about users missing out on some whiz-bang feature. If a cool new feature on your iPod is steak, then data integrity in a fileserver is water -- you can't live without it. Users were dying of thirst while the storage vendors were chasing them away from their freshwater wells. And so the community reacted, and decided that instead of hoping for the goodwill of others, a different license would be used to guarantee it. So, yes, a group of BSD-lovin' devs could have written the code, and we might be where we are today. But the community felt it had been taken advantage of under the liberal license, and reacted to prevent a repeat. In hindsight, the LGPL might've been a better license for libatalk by encouraging corporate use and development, but I'm not sure, and I don't know if that would've mollified the fans of liberal licenses anyway -- not that that latter point actually matters.

Scramblejams 17y ago

"I never ran into the CNID issue when using Netatalk on our Mac OS 8 systems." That's good! Unfortunately I did, and so did many others. A quick perusal of the old mailing lists will turn up plenty of this. We tried a test rollout in a division of a Fortune 50 company, and our backups saved us -- when a user noticed a file was missing, that is. "I seem to recall contributing all of one patch to netatalk, and that wasn't because I was an evil corporate code stealer." Excellent! All patches were appreciated. We could've used more of that. (And we'd have happily accepted patches from the storage vendors, they just wouldn't play ball. I don't think any of us felt the corporations were "evil," just that they were behaving like ... moochers.) "How many of those actually significantly contribute back to the project? I count three active committers." First, that's misleading. The three active committers take patches from others as they please. So to get a true picture you'd need to go through the mailing list and see where all the patches originally came from. And I haven't been involved in the project for some years, so you'll need to go research that yourself. Second, you've completely missed the point. And it's one you should really like. Netatalk entered a sick state because the people who had the desireable patches chose to hold them back. The BSD license allowed them to do so. Then other developers came in and said, we'll commit our patches, but we want a guarantee that those who ship our work will have to do the same. And that was enough to motivate them to make Netatalk fully mature -- every significant enhancement/fix implemented privately became available publicly, and more, thanks to those devs. And what was the outcome for ALL of Netatalk's users? The storage vendors were happy because they could stop maintaining their private forks and just ship from upstream. The users were happy because all these bugs were fixed and they had a responsive place to seek help. The devs were happy because they were assured that they were now on equal terms with the storage vendors. Whether the vendors continued development or not wasn't actually the issue. So everybody won, the users, the developers and the storage vendors. No, the GPL didn't write the code, but the BSD license allowed the code to remain private, and that's where everybody started losing. The GPL assured everyone that that couldn't ever happen again, which, as it turned out in this case, was a necessary precondition to success.

Scramblejams 17y ago

By the way, I think I've omitted something from the discussion until now that may help you understand why the GPL was perceived as the right license at the right time for Netatalk. The initial influx of developers after Netatalk's long moribund state was mostly caused by community discussion of the CNID issue. As users' hard drive sizes increased, more files were stored which increased the likelihood of triggering the bug which resulted in data loss. So more and more people hit the mailing list, wondering what was going on, what was going to be done about it, and were very anxious because not only was it a data loss bug, but a silent data loss bug. Even if users kept backups, they wouldn't know to use them unless they happened to notice a file was gone. This made Netatalk feel like a ticking time bomb. As the conversation's pace quickened, it attracted a handful of new developers who had a stake in Netatalk's success. As users compared notes and the new devs ran tests, they learned, as mentioned before, that some storage vendors had been aware of and resolved the issue in their products, but refused to share the fixes. Users who had lost files became angry. Why? The feeling was that these vendors had benefited from Netatalk for a long time, and now when the community needed help, the vendors were turning their backs on them. I think anger was an understandable reaction. After all, we're not talking about users missing out on some whiz-bang feature. If a cool new feature on your iPod is steak, then data integrity in a fileserver is water -- you can't live without it. Users were dying of thirst while the storage vendors were chasing them away from their freshwater wells. And so the community reacted, and decided that instead of hoping for the goodwill of others, a different license would be used to guarantee it. So, yes, a group of BSD-lovin' devs could have written the code, and we might be where we are today. But the community felt it had been taken advantage of under the liberal license, and reacted to prevent a repeat. In hindsight, the LGPL might've been a better license for libatalk by encouraging corporate use and development, but I'm not sure, and I don't know if that would've mollified the fans of liberal licenses anyway -- not that that latter point actually matters.