Yes, that's true, but I bet you some of the functionality that you wrote can be factored out into a more generic library that applies to everyone's use case. So

Yes, that's true, but I bet you some of the functionality that you wrote can be factored out into a more generic library that applies to everyone's use case. So it could be that half of your code is "library" code that could be open sourced - if it could be written generically with typeclasses. For example, Rust has typeclasses (called traits) and Rust has a lot of libraries that do the right thing for you. fn accumulate<'a, T: Monoid>(tuples: &[(&'a str, &Fn(i32) -> bool)], i: i32) -> Option<T> where T: From<&'a str> { tuples.iter() .filter(apply(second, i)) .map(first) .cloned() .map(<&str>::into) .fold1(T::op) //op just concatenates, but Cow<'a, str> does not satisfy Add } Here, the functions first and second are taken from tool.rs, fold1 is from itertools, the type Monoid and the function op is taken from monoid. I did have to write the delayed apply function myself, though. It's definition is: fn apply<A, B, C, F, G>(mut f: F, a: A) -> impl FnMut(&B) -> C // must still be `for<'r> impl FnMut(&'r B) -> C`, because that’s what filter requires where F: FnMut(B) -> G, // must not be `for<'r> FnMut(&'r B) -> G`, because regular functions do not implement it G: FnMut(A) -> C, B: Copy, // for dereferencing A: Clone { move |b| f(*b)(a.clone()) // this must do any bridging necessary to satisfy the requirements } I think that could also be in a library somewhere