Reading @les’ thoughts about the goals of Gancio reminded me of ideas about online events calendars I’ve been chewing over since my days working with Aotearoa Indymedia. There are a number of very different groups of event types, with different requirements. Off the top of my head:
- protest activism events; meetings, demonstrations etc whose organizers want to publicly announce them for open participation, while being discreet about who they are.
- community activist events open to all comers; everything from an open day at a community garden or opening hours for a radical library, to a hackathon or a gratis workshop etc, where their success depends mainly on reaching particular communities of interest/ practice, and organizers may or may not mind being publicly identifiable
- open access public events; public meetings, free concerts and street theatre, school fairs, art openings etc, where their success depends on being promoted as widely as possible and organizers don’t mind being publicly identifiable
- ticketed open access public events; gigs and music festivals, theatre shows, conference with registration fees, practical workshops with expense fees etc, where their success depends on being promoted as widely as possible and organizers want to be publicly identifiable as the legitimate source of tickets/ registrations
- private events; everything from birthday parties and family reunions, to house parties and workplace parties, to invite-only political meetings and conferences etc, where only a select group are invited, and the details of time and location are private.
In each of these event meta-types, the geographical scope of events could be local or municipal, or as mentioned by @les, regional, national, international or global. These meta-types and geographies can be combined in different way to come up with a wide range of use cases for federated events. For example
- within one city, a range of organizations might want to have their own events calender each, under their own controls, where their public events are federated to allied groups, gig guides, community calendars etc, and they can subscribe to events from the calendars of allied groups, coalitions they join etc.
- a global network of political groups might want to be able to call private, invite-only conferences, using a shared events calendar run by the network’s geeks to federate out the details of each conference to member groups, receive RSVPS etc.
So as well as all the usual reasons for having multiple free code projects in the same space (language preferences, trying different technical approaches etc), there is plenty of room for a range of federated events UIs, each targeting a group of use case(s) needed by specific user groups. The more the merrier 
What I’m hoping though is that all the free code projects working on different kinds of events systems can see the benefit of having a certain amount of shared infrastructure. Not only a standard set of protocols for how to represent and transmit event data across a federated network, reusing existing protocols and formats as much as possible, but also standardized libraries/ modules/ plugins for implementing that standard in each of the languages being used for events software. That way developers can focus most of their energy on making great UI for the specific user groups and use cases their projects were set up to serve, and share the work of maintaining the plumbing that links their users and events data together as and when appropriate.