The Google Summer of Code 2020 was very productive for completing a lot of tasks. Specifically, the “Done” tab of the Kanban Board created for my project will have 150+ cards (including issues & pull requests) by the end of the GSoC 2020.
Aim of the Project
The primary aim of the work done for this project is to improve the maintainability of OpenWISP. While designing OpenWISP and making it highly customizable, we went a tad bit too far with separation of the concerns and ended up making a lot of repositories. This caused the problem that introducing a change in the code required multiple pull requests at different places. This was slowing us down to achieve our main goal and releasing new features.
Modularization can be a boomerang if taken to the extreme.
— Federico Capoano ( @nemesisdesign )
So we sought to solve this problem and we decided to merge repositories which added more work and provided little to no benefit as a separate repository. Not only that, we took this opportunity to clean up the code and add some features. We improved the documentation, added utility functions to make development easier, made Django modules extendable and introduce all the big and little code improvements we could think of during the course of the project.
After the main aim of the project was completed, I was also able to help in improvement and bug fixing of some of the modules, most notably, we were able to tackle a lot of openwisp-radius release blockers during GSoC and we are getting very close to the release.
Project Details
Let us now discuss the project in depth, since the nature of the project required me to make a lot of minor and major pull requests, it is only practical to discuss the highlights, the complete work is available in the Kanban Board itself. That said, let’s see the highlights (links to the changes are available at the bottom of the blog):
1. Merging django-ipam & openwisp-ipam: The first milestone was getting the first two repositories merged. In the future when our focus is on releasing this module, I am sure that the new focused approach of maintaining only one repository will speed-up the process of making changes in the module.
2. Merging django-netjsongraph into network-network-topology: After the ipam module, I focused on network-topology module, being a relatively smaller module we were able to introduce swapper in the module quickly and this acted as a practice ground for adding swapper to the rest of the modules as well.
3. Merging django-netjsonconfig into openwisp-controller: Since openwisp-controller is the central module used by a lot of people, we had to do rigorous testing and ensure backward-compatibility for all the changes introduced in this pull request, this is yet to be released.
4. Merging django-freeradius into openwisp-radius: Finally, we come to the radius module, since this module is not released yet, we had more wiggle room to make backward-incompatible changes and hence this module saw a lot of improvements.
5. Fixing release blockers in openwisp-radius: The sheer amount of work done towards the release is amazing, it includes the work to fix bugs, refactor API, re-implement existing functions more efficiently, make the applications more extendable as per user review, improve documentation and even added some new features like restricting freeradius API usage with IP addresses.
6. Swagger in the openwisp-radius API: The swagger API documentation will ensure that our documentation is up to date while not adding any additional burden on the developer to make and maintain the documentation.
Some more notable changes were:
- Sample Applications: Added a sample app in each repository, this will act as an example for the users extending the django modules and help in writing more reliable code and testcases.
- Swapper: Added django swapper to each repository, again making extendability easier.
- Documentation: From adding the feature explaining GIFs in the documentation to refactoring the entire documentation sections to make it easier for users, during GSoC a lot of improvements where made to the module’s documentation.
- openwisp-users: Added some new utility functions and made openwisp-users extendable to enable users to make changes to their user fields as per their organization requirements.
What’s Next for the project
Some of the modules are released and some of them are going to be released very soon, for this project, the next step is to focus on finishing the already open pull requests and release blockers. When that is done we will be able to get the modules published. Once the modules are published, we would take feedback from our users and spend resources into improving our work based on the feedback.
While that would be the end of this chapter in the journey, there is a lot more to do:
This was just the beginning. The first step of learning lessons about proper modular development.
— Federico Capoano ( @nemesisdesign )
We will surely find more improvement and optimization points in the future.
We will surely be ready to learn from our mistakes in the design.
We will surely improve OpenWISP to ensure the development remains quick and easy to deliver the final product releases frequently and consistently.
The Experience
Just like the last year, my experience with OpenWISP was great. My last year’s blog of GSoC project report was read by a lot of students finding organizations to which they can contribute. Hence, I decided to include some takeaways from my experience working with OpenWISP:
- Impact: Unlike college projects and other interships where your code is only used by you and a handful of the people reviewing it, the code you write when working on an open-source project matters. It’s released to the public and when people use it, you get feedback and you meet the oppertunties to improve your work.
- Code quality: Being able to write code is only half of the story; readability, best practices and other non-functional aspects define the difference between a developer and a ‘good’ developer. When working on OpenWISP, you are exposed to such good practices and these practices will help you in any future endeavours.
- Great working peers and mentors: Work culture is important and no doubt most of us look for the same when joining a new team. In OpenWISP, you can expect to meet friendly, helpful and knowledgable people with whom you can discuss your problems and solutions. I believe I have been able to complete so much work thanks to the timely feedback from my mentors and peers to help me to avoid wasting time in re-inventing the wheel.
- Future Prospects: There is a great demand for network management system in the OpenWRT universe, and to the best of my knowledge there is no alternative to OpenWISP. The difference of supply and demand is great for you to find oppertunties in the future.
- The core code: When working on a young project like OpenWISP, you get to work on the core modules that define the project itself. Developing a project is great but when you are a part of designing a solution, you get to meet a broader and meta level of problems and learn about the methods to solve them.
Hope this helped in explaining my experience in Google Summer of Code 2020. Good luck with your Goals!
References & Links to the work:
- Work in “Done” Column of Kanban Board — http://bit.ly/GSoCs01
- Merge module into openwisp-ipam — http://bit.ly/GSoCs02
- Merging module into network-topology — http://bit.ly/GSoCs03
- Merging module into openwisp-controller — http://bit.ly/GSoCs04
- Merging module into openwisp-radius — http://bit.ly/GSoCs05
- Release blockers fixed in openwisp-radius: http://bit.ly/GSoCs06
