3 ms·

You are right in that we're not BigCorps, but if anything, that makes it worse, as we don't have as many resources to spend setting up boxes we wouldn't have ot

by tghw 15y ago

You are right in that we're not BigCorps, but if anything, that makes it worse, as we don't have as many resources to spend setting up boxes we wouldn't have otherwise needed. It's not a moral and ethical calculation, it is a simple calculation of time. One of our main goals in the software industry is to reduce redundancy. Antirez's decision is increasing it. Arguing simply based on incentives is also a fallacy. If we were to look at everything from that perspective, no one would donate to charity and far fewer open source projects would exist.

generalk 15y ago
Antirez's decision is decreasing complexity and time for him and the people who help maintain his project. The code is right there. Any of your BigCorps are free to grab it and make it work. They are not free to demand the time of an open-source dev.
- tghw 15y ago
  Forking the project is less than ideal. Client libraries will have to spend time making sure they comply with both versions, and development in general will slow as each project will have fewer total devs. Better to bring that other team "in house" and have them help with any issues that come up due to the new cross-platform code.
  - generalk 15y ago
    > Forking the project is less than ideal. Except when the author of the project says he won't roll Win32 support into mainline development. Then it's the only option, but it's an option available solely because the author open-sourced his code under a license that allows it. Which is awesome. > Client libraries will have to spend time making sure they > comply with both versions I'm not sure that's the case. If I'm writing a Redis library (say Resque), I'm going to ensure it works with Redis. If it's also usable on Windows because of redis-win32, awesome, but that's not something I'd go out of my way to ensure. > development in general will slow as each project will have fewer total > devs. What? Why? Why would a project have fewer devs? Are you assuming some developers will work only on redis-win32 and not on mainline Redis? I don't think that follows -- changes to mainline Redis will probably be merged downstream into the win32 fork by that fork's maintainers, who wouldn't otherwise be working on Redis.
nupark2 15y ago
Standardizing on Windows as a deployment platform has known costs and benefits. One of the costs is in largely losing out on the traditional UNIX software ecosystem. There are some OSS projects that maintain first-class Windows support, but nobody should be surprised that when they find out that Windows is poorly supported by an OSS ecosystem that is predominately focused on producing software for UNIX descendent systems.
- tghw 15y ago
  Nobody is saying that they should standardize on Windows, just support it. The way Microsoft did the patch, using a cross-platform library that has support from another popular project, is the perfect way to address this issue.
  - nupark2 15y ago
    I was referring to the IT choice to standardize on Windows as a deployment platform for your organization. As for Reddis, the cost of supporting another operating system -- especially one as different as Windows -- is quite high. If you don't use Windows, there's little cost justification for doing so.

by tghw 15y ago

generalk 15y ago

Antirez's decision is decreasing complexity and time for him and the people who help maintain his project. The code is right there. Any of your BigCorps are free to grab it and make it work. They are not free to demand the time of an open-source dev.

tghw 15y ago
Forking the project is less than ideal. Client libraries will have to spend time making sure they comply with both versions, and development in general will slow as each project will have fewer total devs. Better to bring that other team "in house" and have them help with any issues that come up due to the new cross-platform code.
- generalk 15y ago
  > Forking the project is less than ideal. Except when the author of the project says he won't roll Win32 support into mainline development. Then it's the only option, but it's an option available solely because the author open-sourced his code under a license that allows it. Which is awesome. > Client libraries will have to spend time making sure they > comply with both versions I'm not sure that's the case. If I'm writing a Redis library (say Resque), I'm going to ensure it works with Redis. If it's also usable on Windows because of redis-win32, awesome, but that's not something I'd go out of my way to ensure. > development in general will slow as each project will have fewer total > devs. What? Why? Why would a project have fewer devs? Are you assuming some developers will work only on redis-win32 and not on mainline Redis? I don't think that follows -- changes to mainline Redis will probably be merged downstream into the win32 fork by that fork's maintainers, who wouldn't otherwise be working on Redis.

nupark2 15y ago

Standardizing on Windows as a deployment platform has known costs and benefits. One of the costs is in largely losing out on the traditional UNIX software ecosystem. There are some OSS projects that maintain first-class Windows support, but nobody should be surprised that when they find out that Windows is poorly supported by an OSS ecosystem that is predominately focused on producing software for UNIX descendent systems.

tghw 15y ago
Nobody is saying that they should standardize on Windows, just support it. The way Microsoft did the patch, using a cross-platform library that has support from another popular project, is the perfect way to address this issue.
- nupark2 15y ago
  I was referring to the IT choice to standardize on Windows as a deployment platform for your organization. As for Reddis, the cost of supporting another operating system -- especially one as different as Windows -- is quite high. If you don't use Windows, there's little cost justification for doing so.