<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 18, 2015 at 4:31 PM, Louigi Verona <span dir="ltr"><<a href="mailto:louigi.verona@gmail.com" target="_blank">louigi.verona@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br></div>What you say about the user is also true. Perhaps it is right to say that users and developers should work together. But the reason why developer, in my view, carries more weight in this matter, is because he is the one investing his time and skill. Therefore, it seems rational for him to make sure he understands the feature and why it is needed (if at all).<br></div></div></div></blockquote><div><br></div><div>I enjoyed your talk(s). But I wanted to note that I've had (recent) experience working with proprietary/commercial audio software development that somewhat paradoxically undermines your description of the role of the developer. Although it may seem strange, some companies choose or are forced to hire developers who, despite having excellent development skills, have close to zero knowledge about the domain they are working in. All the understanding of the workflow and desired goals is left to a "product manager" who defines the required changes/additions, and then the developers are expected to implement them without (necessarily) understanding their purpose. <br><br></div><div>Open source tends not to work this way, and we generally expect developers to function as de facto product managers (or at least feature managers). <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote></div><br></div></div>