The OpenSolaris Networking Community

Is there a difference between “Solaris Networking Strategy” and “OpenSolaris Networking Strategy”? At the moment the answer to that is probably “What is the OpenSolaris Networking strategy?”, but I think that it bears some thought.

Moreover, I think that the two probably are different, perhaps even should be different. Solaris Networking strategy is tied closely to the general aims of Sun Microsystems as a business which means that it is strongly influenced by hardware developments at Sun (Neptune, …), partnerships (Microsoft, AMD, Intel, …) and relative priority decisions (IPv6 improvements over Bluetooth support, for example). The group of people that actively participate in OpenSolaris might have a completely different set of priorities based on alternative interests (both business derived and those of a more personal nature). Of course, many of the interest areas will be common - everyone wants better throughput, reduced latency, improved standards compliance, etc. Even work that has a particular focus for one business area tends to improve others as well.

In thinking about the OpenSolaris Networking community, it’s difficult not to try and thing of ways to improve the level and quality of participation, particularly from people not currently employed by Sun. The networking-discuss list, for example, has worked well as a forum to support both new and experienced OpenSolaris and Solaris users. I think that it’s been less successful as a place to discuss the detailed workings of the current and future implementation, though some of that has happened. A couple of networking projects have spun off separate project specific discussion lists, in large part to avoid the more “general” discussion that takes place on networking-discuss. Whilst that may make sense for the project team in the short term it leads to fragmentation of the community, as important conversations take place in smaller groups.

Perhaps what we should do is introduce networking-code for the nitty-gritty details and encourage its’ use by all of the project teams for in-depth discussions. This would be easy to arrange from a technical perspective, though we’d have to carefully manage a transition and be sure that the intended use of the various lists is clearly described.

There’s no doubt that developing for OpenSolaris has some barriers right now, including the lack of a publicly usable bug-tracking database and the fact that the “main” source tree is still TeamWare based, replicated to Mercurial. There is active work in many of the problem areas, but I worry that some of these significant barriers are hiding smaller problems that we could work on in parallel. For the OpenSolaris Networking community, what might these be? It’s obvious that we should be producing more documentation about how the system works, but what parts should be prioritised? Improving the stability level of APIs is another good candidate, but which APIs are the most important? Which are we missing altogether?