Recently, I have been helping to organize and volunteer at a few local tech events and it struck me how much of the experience in organizing things aligns with other projects I've been involved in.
I don't know why this would surprise me - I have some background in project management (I've read the books anyhow). Despite the fact that my work experiences have been in the management of software development, the issues, and the means of resolving them are pretty much the same.
In the recent case, stakeholders have been the people donating money or time to the project - pretty much the same view taken in developing software. It's important to correctly identify stakeholders because while everyone has an opinion, most of them don't matter. This might sound harsh, but bikeshedding is a very real problem.
I can't tell you how many discussions I've been involved in with people who have no intention of participating in the proposed events. In community projects the stakeholders might be sponsors, organizers, or event attendees - there is no single piece of advice for identifying them (that I know of) but you can be sure that the rest of them will let their opinions be known.
This one is true across the board, and obviously so, but every project has limited resources to work with. Whether that is time, money, or quality there are always going to be constraints1. The difference in managing community events is there is typically little room to move on the money-end of things, which in my experience means more time spent to maintain quality. Funnily, there is also the "cost" of time spent raising money from donors, which is a huge time-sink that can make a huge difference in the quality and is not to be ignored.
There is rarely anything technically challenging about organizing a software conference (unknown unknowns), much in the same way that there is little technically challenging about most line of business applications. The hard parts are inevitably working with other people or teams. People have different interests and often the most challenging aspects are aligning expectations with the most likely outcome.
On an unhappy note, the most likely outcome is that not everyone will be happy with the result. Happily, you can optimize for reducing this number. Whether it's coworkers, sponsors or attendees, you can focus on keeping the majority happy and count it a success. One important note about optimizing this outcome is identifying stakeholders - if one person holds all the power and is diametrically opposed to the general consensus, they are probably not a good fit for the project.
This one is more tenuous with my past work experiences, but I think there is a kernel of truth to the idea that a key figure (perhaps a customer, perhaps management) proposing something totally counter to the majority is a red flag. I'm not sure I have a good solution to this in a work context, but in "managing" a community, there is a point when it makes sense to just acknowledge that someone might not be a good fit at this point in time. It beats the heck out of trying to do the impossible and be everything to everyone.