Doomhunk suggests a great idea and it was something I once did the following in a campaign (a non-canon, non-Third Imperium).
I defined two or three key worlds in the subsector, three or four key economic nuggets (one major luxury good, a couple of large companies, a tarriff war recently ended by Federal intervention), a couple of personalities - large and small - (a regional governor, a small-time planetary boss (a cross between Huey Long, Richard Daley and Robespierre)).
I then let my players create a few worlds each with the idea that they should play off this source material - feel free to add to it, but like improvisational theater, try not to fight what's already happened (saying that the boss shared a mistress with the Governor (ala JFK and Sam Giacana) was good, saying that he had been arrested was not).
If I had a conflict, I let the players work it out. After a lot of heated arguments, we had a very well fleshed out little chunk of real estate that our players were familiar with. As ref, I could add or tweak what we had done, but they knew as much (and occasional more) of the common knowledge as everyone and I almost never had to do a long bit of exposition as a ref. They players had ideas of where to go for information already ("Didn't Judge Harlan (the boss) exile one of his lieutenants to [World X] maybe he can help us?" - even if we never came up with that idea in the first place, it gave me a chance to improvise as much as the players, which was fun).
It made for good game play.
----
I think one way of doing a cooperative sourcebook for a cluster (is there a subsector in Ley that could be used?) is to do this:
Step 1: Find a few folks who can set out some overarching detail as a sort of "source code" and then have various folks build worlds aware of some of the local economic and political factors.
Step 2: Distribute the "source code" to various people who will create a world or two (or a background detail or two). When people are done, you see if there are any areas which are problematic - at loggerheads - and then deal with the overlap.
Step 3: Turn the new information into a new source code. Repeat as necessary.