Thanks, Natalia. 
I appreciate offers for shelter very much.
You asked how I decide on what functionalities to add to Buoy. The answer is that there is no formal decision making process. What usually happens is someone with a need expresses that need to me in some manner, we converse about it over some communication medium, and then I add some functionality that hopefully meets that need. It’s very do-ocratic. An example will help clarify this.
Three weeks ago someone came to me in person and expressed concern that Celly, a SMS/txt messaging service that saw its popularity skyrocket thanks to its use by the Occupy Wall Street protest groups, was no longer suitable for their small group of activists. Two reasons were given: first, the service discontinued offering their free tier product line, and second, Celly began requiring users to install a smartphone app in order to send SMS messages. This causes two big problems for the activist who approached me. First, they have no money to afford to pay for Celly. Second, a significant percentage of their membership does not own smartphones, but rather flip-phones. These two issues are of course related: the local activists are all poor, working-class people.
I asked them some questions about what they had been using Celly for. This conversation lead to a better understanding of their use cases. Effectively, they had been using Celly as a kind of SMS/txt broadcast channel for the group, so that one member of their collective to send a single txt message and that txt would be received by everyone else in the collective. The collective is small (less than 20 people).
Over the next week (two weeks ago, now), I wrote a feature called the Team SMS/txt broadcast channel into the functionality offered by Buoy Teams. It meets the criteria the activist collective needs, including the ability to use it forever with no additional financial cost. One week ago, groups using Buoy alreay saw an update in their dashboards and could download and install the new feature with one click.
That’s the usual process.
Of course, I have created more “formal” channels for receiving feedback. These include the GitHub issue tracker, intended mostly for coordination amongst developers (and I include people who conduct user testing, writing documentation, and other non-code tasks to be “developers”), the WordPress plugin support forum, intended mostly for end-user-to-end-user volunteer support, our public Gitter chat room, intended as a way to get live support if someone is available to offer it, and our dedicated project email address available with PGP encryption, intended for those who need more assurance privacy but still need a support channel.
In practice, however, I am the only developer and have written virtually every line of Buoy’s code myself, so GitHub is mostly just me talking to myself, the WordPress plugin support forum has seen some use but is mostly me answering questions by end-users instead of users helping one another out, the public Gitter chat room is primarily me making announcements about my own work to people who are lurking and watching me do so, and the dedicated email address is dormant and receives no mail.
I would love for all of these channels to get more use, but the reality is that basically no one pays any attention to what I’ve done beyond nodding and smiling and expressing how good an idea they think this is to me when they hear of it. :\
To wit, that story of the SMS broadcast channel feature that now exists in Buoy? After I discussed the use case with the person who approached me about needing such a feature that could replace Celly, I have not heard from that person on the matter again, despite repeateded attempts to communicate about it over the two weeks since the feature has been implemented. I say this not to disparage this person themselves, but rather to point out a pattern relating to your question, about how I receive feedback. The pattern is: I receive feedback through a variety of means, and am generally able to very rapidly translate such feedback into working features that could be used immediately by the people who approach me. In practice, although the people I’ve communicated with are eager to express to me what they need, once I actually implement it, I never hear from them about it again.
This makes iterative improvement difficult for somewhat obvious reasons.