How should I structure a new open source group

Question

I have taken the lead to start a new open source group for the hardware description language VHDL. There are many existing (open source) projects out in the world and many are hosted on GitHub. On the other hand the IEEE working group marked some proposed language changes as "move to open source".

So we discussed that we start a new open source group. The idea is to upstream many duplicate code parts to a more "global" core library (which does not yet exist for that language).

So at first I managed to get the VHDL username from an existing GitHub user, so I could register VHDL as an organization. The I started a little wiki to collect existing open source projects for VHDL and to collect proposed functions / packages, which should be part of a Core Library.

I'm a maintainer for a open source VHDL repository by myself, but I don't want to contribute all our code to the new child! (It's just too much for the start)

I'm trying to contact other authors and projects. I invite them to participate in the new group.

My road map looks like this:

1. Get each other to know / list existing projects
2. Gather proposals for what should be included in a VHDL “Core Library”
3. We will have (recorded?) presentations of existing projects 10-15 minutes + 10-15 minutes for questions If possible a live-demo is recommended.
4. Talk about proposals and unifying interfaces if duplicates exist
5. Set up a testing infrastructure (VUnit or Cocotb might be good candidates)
6. Do the coding + propose pull requests
7. Run tests on the new code
8. Merge it, tag it, release it !!

Have I missed important things? What should I do in another way?

Answer 1

If you have not already, read through Producing Open Source Software and/or The Open Source Way - they have lots of good information about all of the things that people tend to forget when running an open-source project (that is, everything other than the code).

One thing I don't see mentioned in your list at all is the subject of licensing. This is likely to be the subject of much argumentation now, but if you try to consolidate licensing after you've brought in a bunch of projects, it'll be a huge pain in the ass. And if you don't have it handled, most corporate users won't be able to use your project. Decide on a license now, and anything that isn't compatible will have to be re-implemented to be included.

I also think it's very helpful to decide on goals up front for the project. Are you trying to include everything possible, or a small subset to avoid bloat? Are things included if they're useful, or only if they meet certain quality standards? Do you accept libraries without an active maintainer on the core team? Getting your core team on the same page as to your goals creates a much better product, and publicizing them allows users to easily ascertain whether your project is right for them or not. For instance, compare Rails' philosophy with Django's; "convention over configuration" and "explicit is better than implicit" are at odds with each other, and so each framework is better off by choosing one.