Bruce is right, I guess I shouldn't have redirected his reply. It certainly did more harm than good, and although I assumed it's addressing to me was a mistake, I should better account for such a situation where that reply was intended only for me and not to be public.
I think we need to put down our grenades-- I understand the need to express the frustration as I have on occasion as well (and furiously), but hopefully soon we can give up on the grenade lobbing and forgive any issues we've had in the past, not only for our own peace of mind but for the good of the idea (as opposed to the "tribal pride" model). As I've said, license issues *do* block us from sharing code specifically but code isn't the only thing that can be shared. Even if we never come to a point where we resolve our differences, we do need to come to a point where we can peacefully coexist, without tension between our project developers. This first phase of flaming was unavoidable given the circumstances. As Chad said, driver cross polination is very good example, and since drivers in SharpOS will be separated by a well-defined ABI, they can be classified as a separate work from our kernel, and thus be licensed in a different way. If we wanted to, we could collaborate on driver APIs, something which has never been covered by either the ECMA standards nor any non-standard .NET functionality which exists. But if we completely do nothing, like Bruce said, we will be duplicating a large amount of effort. And we still haven't really looked at our (possibly differing) driver visions and consolidated them and it's possible that such a solution is not practical, but things like this need to be talked about and now is a better time than ever to do it. Up to the executable-level, except for places where executables make use of kernel features, we get free compatibility thanks to the standards. This offers a plethora of places we can work together. We don't have to coordinate in the dark. If we are able to see each other's development transparently, it gives us more opportunities for collaborating efforts on shared infrastructure. Which brings me to The biggest problem so far in allowing such collaboration. The communication barriers have not yet changed. The Cosmos project is very opaque to me, with so little available to work with information-wise that it's very inaccessible. You added me to your private development mailing list, which I very much appreciate, it was a great first step and gesture of co-existence, but for now my participation there is totally limited to observer only, not only to avoid stirring up trouble but also because the mailing list is closed, and my principles stand for open discussion. As I understand your use of a private list is only temporary, so that you can keep the project team small and the design clean, so I urge you to make this change sooner rather than later, as it will help a lot in the communication process. Just as our discussions here are shared with you freely (and now you participate more, even if it is so far only when you are mentioned), we would like you to share your discussions with us, so that we might participate in yours. --- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
