On Wed, Jul 9, 2008 at 7:25 PM, Jean Jordaan <[EMAIL PROTECTED]> wrote: > 'lo there > >> It's strange, isn't it? Not open-sourcing, you 'kena' (talk abt MSFT), >> open-sourcing, you also 'kena'. I'm still lost to this way of >> thinking. > > It's not so strange. OSS is not just a kiddy pool where everyone is > splashing around for fun. > Have you ever read the Linux kernel mailing lists? Technical choices > that affect the entire OSS community have to be extremely well > motivated to gain acceptance. If you're going to do something that > will cost everyone time to learn and implement, you should have good > reasons (not "I'm personally not familiar with it").
Hmm. Seems my opinion of Linux kernel mailing list is totally opposite of yours (though for the same base reasons). I dislike the mailing list because from what I've been able to read in my spare time, there are just too much politics and one-man show there. Sure you could easily have your patch got into the kernel, if you're one of the few top people there. Don't take my word though, I only read "some" of the more interesting threads, so maybe I'm biased towards the more exciting "fights" rather than the more mundane day-to-day stuffs. And I disagree with your latter point. That's just reducing the amount of innovation you could have. Sure, "don't reinvent the wheel" seems to be a catchphrase nowadays, but I think it's very misleading. That said, Google does not release just about everything it has to the open source pool. There are lots of evaluation works done, like how useful this would likely to be, etc. Plus there are further work (a lot of them) to eliminate dependency with internal codes. It's not as if releasing a piece of code is as easy as extracting it off the version control tree and publishing it away. Some of the main reasons why protocol buffer was released was likely due to (I'm not related to protocol buffer people in any way, so I'm not sure how correct this is, mostly my hypothesis): 1) It has a very compact wire format; 2) It has been tested through and through internally; making the release pretty stable; 3) It has supports for languages most used right now (C++ and Java; Python is a smaller language and I believe it can be converted to JSON easily, whether the converter is open-sourced or still a work in progress is another matter); 4) It is very easy to use from C++, Java, and Python; you could just assume that a protocol buffer is just some native data structures (it is actually). While open-sourcing might look easy, it is not. Once a code is open-sourced, there will be streams of requests for improvements, questions to be answered, complaints to be heard and considered, etc. (The blog posts, while some may consider harmless, are usually written be the engineers who were involved in the development; and they have pride with their works, like most of us, coders, do). > > Look, I didn't study PB, and my reaction is mostly just to the nature > of the announcement, which only compares PB to a straw man (DOM > processing of XML), and which doesn't respond to substantive critical Hmm. Seems the main announcement only states something like "think XML but ...", I might be wrong, but it's just stating the most popular format; if it were to say some other specifications like "think ASN.1 but ..." how many people are gonna be interested? > comments. PB obviously works very well for Google, and maybe the > people who implemented it know ASN.1 backwards. We shouldn't have to > take it on faith, though. They probably do, or at least knows what it can and can't do. Seems that the principle is reuse whatever available if it is good enough, otherwise... Cheers, -- Chris [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ Slugnet mailing list [email protected] http://wiki.lugs.org.sg/LugsMailingListFaq http://www.lugs.org.sg/mailman/listinfo/slugnet
