Re: [Discuss-gnuradio] GNU Radio Organizational Changes to Address Growth

[Johnathan Corgan]

Most of you already know me, as I’ve been in the GNU Radio community for eleven years in various roles, including release manager, integration manager, Live SDR developer, infrastructure manager, engineering consultant, and technical trainer.  Today I’m happy to move on to the role of Chief Architect.

It is an exciting time of transition for GNU Radio.  Recently there has been large growth in several areas--growth in our user base, our number of contributors, the types of radio applications and computing environments that GNU Radio is running in, and hardware vendor support for interfacing with GNU Radio applications.

Much of this success comes from the efforts of unpaid volunteer contributors whose code they have made freely available to others in the community.  This is the nature of open source development, and to a large extent this has been accomplished without much formal direction from the project.  As the GNU Radio codebase has grown more complex, we’ve seen the need for more structured guidance and coordination across development efforts.

As Ben has outlined, we’re filling out the new organizational roles of Tech Leads, whom we are looking to champion their respective areas of development.  This includes:

• Developing a roadmap for feature development and communicating that roadmap to the user community and code contributors across the project

• Identifying and recruiting individual code contributors

• Shepherding feature proposals in their area through the process of getting community feedback and clarification

• Coordinating code integration in their area of the code tree prior to final review and merging

• Ensuring support issues and questions in their area of responsibility are properly resolved

In the next few weeks, Ben and I will be sharing more details about how we will fill out the organization and how we will be operating the project and the new Foundation.  Key among these are:

• A new process for proposing, getting community feedback on, and documenting new (significant) feature development, patterned after the Python Improvement Proposal process many of you are already familiar with

• A more structured code review, unit testing, integration, and release management process

• Roadmap-based development tracks that allow better coordination among different developers, especially for feature sets that cross organizational lines

• Improved communication among our globally distributed community and developer base

As Chief Architect, I’ll be working closely with Ben, our user community, and each of our Tech Leads to accomplish these goals.

-Johnathan