Posted
I am curious as to what mechanism is being used to guide the future development of Synfire?
I assume that you (the developers) make the final decision regarding new features and improvements, but also accept the input of us licensed users.
It appears that the current form of user input is via this forum and direct emails, but I am concerned that those may not provide the most democratic process, or even a clear vision of the desires of the majority of users.
For example; there are a growing number of requests for added features, interface changes, and recommendations that Synfire behave like other DAWs. Much of that I do not want, because I'm concerned that Synfire will suffer the feature-bloat that is so common in most other music software. I want Synfire to be better, not bigger.
Of course, I could jump into each of those forum topics and express my concerns, but that seems negative and probably a waste of time. Unfortunately, such silence is often construed as tacit approval and that is exactly what I don't want.
So, the question is, "How does the Synfire development team prioritize feature requests and the future direction of development?" Is there a need for a formal process by which all licensed users have a voice in the future of Synfire? Perhaps, surveys or questionnaires that allow a more direct voice?
If you (the developers) say, "Trust us, we won't get carried away bowing to the whims of the squeaky wheels.", I can accept that. Otherwise I hope we can find a mechanism that allows users a more direct voice in the future of Synfire.
Mon, 2009-12-14 - 19:54 Permalink
Being the small entity Cognitone still is at this time, our human resources are limited. It is our main responsibility to find the right balance between keeping the development going and keeping our company a healthy business, because both depend on each other. That said, we not only need to develop the software, we also need to sell and support it (you now, all those videos and example projects, device descriptions and project templates you are still missing).
Setting the right priorities for technical issues and feature suggestions is a difficult task. An awkward detail might be annoying at the moment, while in the context of the bigger picture, it doesn't look so critical anymore. In order to not get distracted, we collect all issues and suggestions on an internal list (part of which is published on our site). Usually these items fall into distinct groups/topics. Once we get around to work on any such topic, we review the list and attempt to consider the collected items where possible. We deliberately do not publish the entire list, as this would put us under extreme pressure and lead to total distraction.
Rest assured we're not aiming at making Synfire become just another DAW (which it isn't anyway). However, if there are obvious obstacles in the user interface that get in the way of the productivity of experienced users, we will consider these and attempt to remove the barriers.
Substantial enhancements to the user interface are expensive and take their time. We can't do anything revolutionary overnight. These suggestions are usually classified as "Research" or "Open Discussion" until a detailed idea has settled if and how they can be implemented.
In every community, there are power users who bring up issues and suggestions more frequently and more elaborate than others. We appreciate this feedback, as the vast majority of users (>90%) tends to be silent. Nevertheless we know about this proportion and keep that in mind when making decisions. Unfortunately, for real votings and democracy, the active user community has not yet reached critical mass, which is why for the most part we follow our vision.
Therefore, if you feel there are things you especially like about Synfire and its user interface, and that you don't want to see changed, we are interested in learning about these. It is equally important for us to see where our concept works, as is for things that do not yet work.
Andre
Tue, 2009-12-15 - 00:08 Permalink
I think we could do a survey every now and then. Everyone interested in future directions will happily participate, I think.
As to forum votings, Andre is right. The participation in forum activity is low. A voting can't be representative. If we blew out a newsletter that would be far more effective.
Tue, 2009-12-15 - 00:58 Permalink
As to forum votings, Andre is right. The participation in forum activity is low. A voting can't be representative. If we blew out a newsletter that would be far more effective.
The newsletter is a great idea. Even if it only let people know the hot forum topics, or topics where input is requested.
Andre has made several posts here asking for user input on various topics. An email or newsletter letting users know those topics are available would hopefully spur some interest. And even if they don't want to participate, it is good public relations to let them know you value their opinion.
Tue, 2009-12-15 - 10:50 Permalink
I think the forums work fine for feature requests. Poll based voting is not necessarily a good thing.
In a thread all ideas are conversational. It is often the case that I don't fully understand an aspect of the software. If I make a feature request Andre will often have a reason why its implications go deeper than I would at first expect. I have to back up my ideas. This can be tedious but at least in the end I feel I have a satisfactory line of reasoning.
With forum polls I can vote without fully understanding the issue and its implications for all users. Democracy by opinion is not a good thing. Generally there is no way to change the vote and there is no guarantee that the voter is fully informed about the state and direction of things. This is usually the case and is especially so with a software as complex as this.
With polls, there is a thread attached where the idea is further discussed but the poll never reflects it. I always vote first and read second -- terrible i know, but who doesn't?
If I feel strongly enough about wanting or not wanting a feature whose development will prohibit other features from finding their way in, then I think more than a casual click of a [yes][no] is an order.
I think their current development schedule list is ideal. Its general enough to give them flexiblity to invent instead of just tweak, while giving us an basic idea of what to expect in the coming months and what sort of R&D is going on.
The one this I would like to see more of is user preferences. Reaper has a mountain of them and it is really one of the softwares best features. If there is something that isn't acting the way you would expect, a quick forum search will usually reveal that there is a user preference to alter its behavior.
Tue, 2009-12-15 - 11:07 Permalink
A famous development strategy says: "Make it run, make it right, make it fast" - in that order. Currently we are about to complete the "Make it run" stage.
There is plenty of room for future improvements and optimization.
Tue, 2009-12-15 - 13:54 Permalink
I think the forums work fine for feature requests.
Of course, forums work fine for feature requests, as do any other form of communication with the developers. The point is that these discussions should not be taken as representative of the entire user base.
As Andre pointed out in another recent thread, "Site logs indicate that only a fraction of our user base is visiting the forum at all. Many customers did not create an account."
Poll based voting is not necessarily a good thing.
No one suggested it was. Obviously, if the forums aren't representative of the user base, then any poll in the forum wouldn't be either.
With forum polls I can vote without fully understanding the issue and its implications for all users. Democracy by opinion is not a good thing.
Democracy, by definition, is 100% opinion. There is not, and should never be, a requirement that someone have an arbitrary level of knowledge or insight before they are allowed to vote!