Musink
How to get that killer feature you dream of
I commonly receive emails with feature requests, or asking how feature requests ‘work’. As such, this post explains how I handle such requests, and which features are added.
Requests for software features and wiki entries are important and very welcome. Some features already in Musink (Lite and Pro) are in response to requests made from users. Many pages on the Musink Wiki are in response to suggestions and requests. I appreciate all requests because they help me better understand areas for improvement in Musink. You can send requests by contacting me at Musink directly.
Nearly anything! If you feel that there is a subject which is not well covered on the wiki, please just ask.
Please, do send me you requests. Do understand that it's not always simple for me just to say yes, so don't be disappointed if I say "yes, but not yet".
There are five criteria which I use to decide which requested features will be added to Musink:
All requests which are made are entered into a (non-public) voting system. The more people request a feature, the more likely it is to be implemented.
I usually try to add features that (1) add significant value to Musink, or (2) will be useful for at least 10% of all users. The goal is to avoid feature bloat: having so many features that the software becomes very difficult, or slow, to do simple things in. The more features software has, the scarier it can look to a new user, and harder it can be to find what you like. For example, if there are 6 menus one must go through to add a new bar, writing music becomes laborious, and a new user is going to have difficulty writing their first score.
Some features are simply faster to code than other features. While it may seem that adding a new feature sounds simple, in truth, the coding can take a long time and, even if it doesn’t, the work required can balloon quite quickly. This blog post from Microsoft, for example, shows how adding only 5 lines of code to MS Windows can take over 40 people.
I don’t like half-baked software, and neither do you. That’s why every feature must be tested in every conceivable circumstance to be certain that it won’t crash when used. Lyrical text marks, for example, (which will be released in the next Musink Pro version) were implemented in around a week. There are, however, over 700 circumstances in which they could appear or be edited. Writing these tests has taken much much longer that simply implementing the lyrics feature. I love getting requests for features but just remember that no feature can be added ‘instantaneously’.
Beyond musicians, I receive feature requests from people and companies who would like some for of support or integration for their product. I am not against cooperating with such requests. However, remember that if this change is likely to benefit my users, it will benefit your bottom line. As such, fees apply for implementing features of a commerical nature. Please note that this is limited to genuine features for music composition; spyware, advertising, bundling, etc is not ever considered.
If you would really like your feature request implemented, here are some pointers: