5 ms·

The author touched on the value of the original author, and this is something missing from the RiiR projects I've encountered. An open source project is more th

The author touched on the value of the original author, and this is something missing from the RiiR projects I've encountered. An open source project is more than just code. It's the community: the original authors and maintainers and their years of experience in that problem space. If you don't have a plan to move the community over to Rust (and the RiiR projects I've seen did not) you're (A) duplicating effort, (B) ignoring the value of engineering experience, and (C) making a major decision for an open source project (rewriting it) without collaboration with the current maintainers. (C) is anti-collaborative, and an extreme measure that should only happen in extreme circumstances (not "just because it might be better"). At my employer, the number one reason (I'm aware of) to open source our internal software is to solicit collaboration from other companies. Take away collaboration, and it's going to be a harder sell to open source anything.

_bxg1 7y ago
This is a good point. And unfortunately, in a long-lived language the network effect means you have almost no hope of moving a whole community over to a new language at once. Just look at what happened (or rather, didn't happen) with Python 2 libraries. And that was a less-old and less-permeated language than C(++). So maybe instead of "rewrite it in Rust", the answer is "build a new solution in Rust that meets the needs of a community of people who already use Rust".
deleted 7y ago
[deleted]
orange8 7y ago
> (C) is anti-collaborative, and an extreme measure that should only happen in extreme circumstances (not "just because it might be better"). I agree with A and B, but C just feels like gate-keeping. Open source license do not require collaboration with the original authors. You can freely fork any opensource codebase and modify it as you wish without asking someones permission.
- scottlamb 7y ago
  You can...and certainly cloning a git repo or hitting the "fork" button on github is a normal part of the development workflow. If you're experimenting those changes may be discarded. If you're contributing those changes go back to upstream. But I don't think either of those are what the author means by fork. Other folks have talked about this. [1] [2] I think the author means: if you're maintaining changes in your fork indefinitely and advertising this fork to others as superior to the original to use or as a canonical place to file issues, you should have a good reason. Communities are valuable; please don't divide them or throw them away lightly. Try working with the original maintainer first. [1] https://news.ycombinator.com/item?id=16600219 https://news.ycombinator.com/item?id=16600219 [2] https://news.ycombinator.com/item?id=20001570 https://news.ycombinator.com/item?id=20001570
  - chii 7y ago
    > you should have a good reason And what constitutes a good reason? The epitome of open source is that you don't need to explain of your fork is really superior, the users will come.
    - Aeolun 7y ago
      Creating a wrapper around an existing library will never be superior to a native rust library to me.
      - carlmr 7y ago
        It may be superior if there's ongoing maintenance and improvements on the original code. RiiR certainly has it's place though. Ripgrep for me as a user is vastly superior to grep and a large reason for that I see is in the safe optimizations allowed by the borrow checker. They're certainly possible in C, but it wouldn't be maintainable. Also I'd look at how stable the library is you're wrapping and the size of the code base. It may be lower effort to rewrite than to wrap.
    - scottlamb 7y ago

_bxg1 7y ago

This is a good point. And unfortunately, in a long-lived language the network effect means you have almost no hope of moving a whole community over to a new language at once. Just look at what happened (or rather, didn't happen) with Python 2 libraries. And that was a less-old and less-permeated language than C(++). So maybe instead of "rewrite it in Rust", the answer is "build a new solution in Rust that meets the needs of a community of people who already use Rust".

deleted 7y ago

[deleted]

orange8 7y ago

> (C) is anti-collaborative, and an extreme measure that should only happen in extreme circumstances (not "just because it might be better"). I agree with A and B, but C just feels like gate-keeping. Open source license do not require collaboration with the original authors. You can freely fork any opensource codebase and modify it as you wish without asking someones permission.

scottlamb 7y ago
You can...and certainly cloning a git repo or hitting the "fork" button on github is a normal part of the development workflow. If you're experimenting those changes may be discarded. If you're contributing those changes go back to upstream. But I don't think either of those are what the author means by fork. Other folks have talked about this. [1] [2] I think the author means: if you're maintaining changes in your fork indefinitely and advertising this fork to others as superior to the original to use or as a canonical place to file issues, you should have a good reason. Communities are valuable; please don't divide them or throw them away lightly. Try working with the original maintainer first. [1] https://news.ycombinator.com/item?id=16600219 https://news.ycombinator.com/item?id=16600219 [2] https://news.ycombinator.com/item?id=20001570 https://news.ycombinator.com/item?id=20001570
- chii 7y ago
  > you should have a good reason And what constitutes a good reason? The epitome of open source is that you don't need to explain of your fork is really superior, the users will come.
  - Aeolun 7y ago
    Creating a wrapper around an existing library will never be superior to a native rust library to me.
    - carlmr 7y ago
      It may be superior if there's ongoing maintenance and improvements on the original code. RiiR certainly has it's place though. Ripgrep for me as a user is vastly superior to grep and a large reason for that I see is in the safe optimizations allowed by the borrow checker. They're certainly possible in C, but it wouldn't be maintainable. Also I'd look at how stable the library is you're wrapping and the size of the code base. It may be lower effort to rewrite than to wrap.
  - scottlamb 7y ago