Attendees of our Linux developer courses come from a variety of backgrounds and many are versed in other operating systems. It's not surprising they sometimes question why Linux doesn't do things in ways they are already familiar with; it is reasonable to want to leverage one's existing experience and knowledge when undertaking Linux-related tasks, whether at the kernel or application level.
While occasionally one might ascribe such questions to either laziness about learning new techniques or a pre-determined hostility to Linux, the vast majority of such questions grow from an honest curiosity and a desire to do the best work possible.
We impress upon our Linux training attendees that Linux has an open development culture; kernel developers are not adverse to learning from valuable external concepts and methods, even when they arise from proprietary operating systems.
While we can't use the code in such cases (and the community is extremely careful about this) investigation and debate is always welcome -- as long as from the outset it is accompanied with pseudo code, test code and proofs of concept. Talk that begins (and often ends) with "it would be nice if" tends to fall on deaf ears in the Linux community.
Furthermore, it is also critical to understand why Linux does things the way it does; that knowledge of the evolution of code and the history of earlier methods and implementations is vital. Otherwise, it is impossible to evaluate alternative approaches.
Some points, such as coding style, may seem unimportant, but when one is joining the Linux community, respecting the style, look and feel, of code is not a trivial issue. Many eyeballs will be focused on contributed code and if it is not in a format people can grasp and integrate, it is likely to be ignored rather than receive the kind of review, suggestions and patching that code constructed in a familiar style will get.
When one is dealing with other operating systems and kernels, the visibility of code used in drivers and the core kernel components can be quite limited, or even completely closed. Even when the source is visible license restrictions can limit re-use in new code.
For these reasons interaction of your code with other drivers etc can be hard to predict. In Linux, developers writing code with the proper open source licenses can leverage existing code as much as possible and this is a great advantage.
Sometimes new developers find existing kernel features are blocking what they would like to implement. It may be as simple as a symbol they need to reference in their device driver module is not "exported" from the kernel and thus, is not visible. Or, it may be a more structurally significant impediment.
Because most developers are accustomed to working in environments where they have had to find workarounds to deal with these deficiencies, they are inclined to do this with Linux as well, sometimes writing thousands of lines of workaround code. This is the wrong method to use in Linux.
What developers should do (after making sure they have some understanding of the problem) is to respectfully ask why things are the way they are - and whether a change in the kernel code they are trying to work with could eliminate their need for side-stepping workarounds. If the discussion doesn't lead to alternative ways to accomplish what they need without changing core code, they may volunteer to contribute the more general code that can be used in other work using the same features.
When this approach has been successfully applied, long workarounds can be replaced by much smaller amounts of cleaner code with a more general application.
Linux doesn't do what OS X, Windows, or any others do - because it's Linux. For over twenty years, Linux has evolved in a unique way, absorbing wisdom and experience from many sources, while being careful about where the actual code comes from. The development community is always open about such absorption, but it must always be justified and argued for in the open discussion that is at the heart of the Linux development model.