← See all articles

Feature Requests for Musink Sheet Music Maker Software

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.

Send Your Requests!

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.

Which requested wiki pages will be added?

Nearly anything! If you feel that there is a subject which is not well covered on the wiki, please just ask.

Which features will be added?

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:

  1. Can this already be performed another way in Musink?
  2. How many people have requested this feature?
  3. How many people will find this feature useful?
  4. How long will it take to code in to Musink?
  5. How long will it take to test?

The voting system

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.

Feature bloat

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.

Coding can be quick, testing takes time

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’.

Commercial interests

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.

Market me your feature

If you would really like your feature request implemented, here are some pointers:

  • Tell me how long you have used Musink, and what you write in Musink
  • Tell me if you have purchased Musink Pro, or if you have donated to Musink Lite development. I will pay more attention!
  • Tell me how this feature would help you, and how it would help others
  • If you want something changed, be constructive; offer ideas
  • If you have a commercial interest in a feature, provide research into user numbers, and a formal offer for reparation
← See all articles