Corporate Open Source Anti-patterns

Bryan Cantrill had an insightful talk "Corporate Open Source Anti-Patterns" surrounding events from 8-12 years ago, and all I'll say is history definitely echoes sometimes: ▶ this video

Just yesterday I came across one of his other videos, and I guess Bryan Cantrill still as a bit of grudge against Oracle: Light ranting: ▶ this video A bit heavier ranting (with the fallout after his usenix ranting): ▶ this video Selected quote: "Any explanation of Oracle that doesn't end with a nazi allegory does not fully explain Oracle" Bryan Cantrill is really fun to listen to, is a tech veteran now, and is still as passionate and energetic as he was the first day (Another interesting video about programming languages he experienced during his (long by tech standards) career: link )

This is one of the Corporate Open Source anti-patterns Bryan Cantrill mentions in his talk a number of years ago: ▶ this video It always feels scummy having to assign copyright for my own contributions to a big company.

I agree, many of the open source licenses are not pairwise-compatible. But the fact that GPL is a strong copyleft license makes collaboration more difficult. And the idea that CDDL was made specifically to be incompatible with GPL is at best a speculation. See Bryan Cantrill's video about the history of Solaris [0] and about different licenses [1] [0] link [1] ▶ this video

▶ this video this is a talk by Joyant's Bryan Cantrill where he make the case that announcing something is going to be open sourced in the future is bad and is an anti pattern.

I hope Bryan Cantrill will do a follow up of sorts to Corporate Open Source Anti-patterns[1] once this is all settled. It would be interesting to know what lessons there are to learn from this. [1] ▶ this video

This piece is (by far) the best written on the io.js fork and its ramifications. As I have said many times before, we are forkaphilic[1] -- forking is healthy because it allows (and encourages) experimentation with divergent ideas. The primary idea that io.js appears to be experimenting with is "more frequent releases", in particular very closely tracking V8. This is somewhat ironic because the close tracking of V8 has been a major contributing factor to the delay in 0.12: despite good intentions, V8 breaks node.js frequently -- and debugging those problems is a time-consuming and arduous task requiring a great deal of technical sophistication. We have made clear that our technical priorities for the project are production-grade stability and performance; to the degree that other have different priorities, forking should be encouraged. In part to allow cross-pollination from any fork, we eliminated our CLA earlier this year[2]; the community can rest assured that good ideas from either will be able to be in both. [1] ▶ this video [2] link