Couldn’t the same argument be made for doing everything “in-house”? Not open to (other people’s) ideas, innovations, or collaboration?
Anyways, I think there are good arguments for both approaches and I stand with my previous stance we should weigh them carefully in the future, before wasting valuable maintainer time.
I assume there’s truth in both perspective. I think it’s always good to apply some skepticism when anyone comes up with the idea of reimplementing a certain feature, protocol etc. that already exists (maybe that is what @Kaspar calls “bias towards inferior”). On the other hand, we shouldn’t judge the solutions based on who implemented it but rather on software quality properties. In my opinion Murdock is a good example: it was certainly perceived with a high degree of skepticism from several community members (including me), because of the number of mature existing solutions. In the end we tried to compare it to Jenkins based on some objective properties and finally concluded that Murdock’s advantages outweight the effort of maintaining it and the lack of documentation/support from the outside.
Yupp, that’s actually what I had in mind when writing about this NIH syndrome in RIOT. I know of at least two people who have turned away from RIOT because they had the feeling that there ideas weren’t appreciated by the community.
We agree on that.
My question was: did we not weigh them carefully in the past, and did waste valuable maintainers time?
I actually feel attacked every time the NIH sentiment comes up. I feel implicit blame that I did not weigh alternatives carefully, and I did waste valuable maintainers time. And this is for stuff where I put in quite some of my (valuable) time, to improve RIOT to the best of my knowledge, and did spend considerable time to make other solutions work, and came to the conclusion that some solution we produced ourselves is better than another (“careful weighing”).
I would like to work in a community that is open to actual careful weighing and the result of that. We do have some homegrown components that we (at least the contributor(s) and the reviewer(s)) chose to use. Concrete complaints to specific instances are obviously always welcome, exactly like with any “external” code. But a standing unspecific blame of “NIH” is IMO just inappropriate.
I would really like to know what the issues in these instances were. This would be a serious issue, if we give people the impression their ideas are not appreciated. Have they or you addressed this issue? On the other hand, I can imagine that their ideas were rationally not good and not worth having them in RIOT. Even though it can be hard to get rejected, it must be this way in order to maintain a high quality in the RIOT kernel.
I am not in all of the details. So, I cannot say anything regarding it. Only read all of your comments. So, just my two cents about it in general. How about having a general framework to approach these kind of situations in the future? You cannot change the past anymore. Something like:
etc. etc.
In order to make a good rational decision. Also document the decision and what it is based on, so that it is transparently documented and visible for everyone. In critical cases, you may even want to ask the community to get some input from them. And maybe challenge the current implementations according to all of those criteria as well.
Yeah, one issue is that future activity / maintenance overhead or number of bugs found or adaptation overhead or the cost of changing an API upstream are hard to measure.
Sorry, but that has been some time ago and I do not want to reopen old sores. The take-away message is that the community has not always been as open for contributions from newcomers as I would have wished for.
I think I got a little bit trapped here by the term “not invented here” because I had an unsent mail in my draft folder for about two years since we had the last discussion on this issue. I have never sent this mail because this topic quickly becomes an emotional one and I didn’t want to put more oil to the fire.
@Kaspar, I know that you’re spending a lot of time and effort into making RIOT a technically awesome piece of software. I - and I assume most of the community - do highly value your contributions. Actually, I think I have never seen a technically weak contribution from your side.
I just want to avoid two scenarios:
The latter is difficult because chances are not too low that we actually can do it better because the new contributors obviously don’t know the system as well as we do. But I argue that in many cases spending time to guide these new contributors is well invested - and better than implementing the feature in question on our own. At least in the long run.
I think that the we need some kind of archive of thoughts about build vs adopt. This forum is a good place. Maybe a lot of discussion might happen in a pull-request, but having that linked here is also good.
I worry that some might see documenting the rational decision might seem like bureaucracy, but it doesn’t have to be overwhelming: three or four paragraphs. What. Why. Pro. Con.
I think that the biggest problem with any contribution is drive-by contributions/contributors. The always advantage of adopting common code is that the community is presumably bigger. But that’s an assumption that needs to be validated. If we need to make some patches, and getting them upstreamed is difficult, then we are actually creating technical debt.