Different Types of Code Maintainer
In software development there are many different types what can be classed as part of the wider group we call Software Maintainers.
Not all of them need to have write access to code, or even read access.
This post is to help dis-spell the myth that only those that have Write Access are Software Maintainers, though they are the ones with the most power and the ones that ultimately are the last ones to approve or decline new features as well as the most likely to be the ones that implement it, especially in closed source tech, but in open source tech, this typically is not the case and the maintainer team will usually want community contributions, which once they are approved are then supported either by the individual/team that provided the new feature/bug fix, or are supported by the core maintenance team.
Please Note - This is written from my experiences over the last almost 2 decades (I started writing my own code in 2006) & much of the lessons here are from time spent working alongside the PowerShell Team with their many Projects, including PowerShell itself but also so many others including Windows, Xbox, Office & Microsoft 365, Azure and many other non-Microsoft technologies.
** Please also Note** - That I am currently the only, non-Microsoft person that is on more than one of the PowerShell Working Groups & am in the process of adding a mechanism that brings an auto-updatable page and a nicer mechanism to query the members of the Working Groups, as well as to add the ability for historic members to be continued to be recognised for their input to PowerShell. You can have a look at my Work In Progress (WIP) PR to see how I am having a think of achieving this.
I know others could & some definitely should look to come and join some of the working groups, especially those that have knowledge and are long standing community members but I also know that people are busy, especially if they are currently working or unfortunately recently on the market for a new role so this may not seem like a great use of their time.
With Code Write Access
There are a number of different types of personas that have require Code Write Access
Maintainers
There are different types of maintainers.
Full Access Maintainers
Full maintainers, typically are those that are part of the core team of a product and are able to (depending on the team) enact significant amount of change across almost all of the projects that the team over sees.
An example of this typically is a group at the Organisation level called Maintainers and is able to be added and tagged by collaborators and above.
These maintainers may have the power to push directly to the main/master branch as part of branch policies. Even though they likely will not use this in larger projects. I have used this previously when I have either a critical fix that needs pushing in or have had a time sensitive feature to deploy and others that were part of teams were off, or busy on other projects and could not review my code. I only ever would do this in a small handful of times, and much prefer having another set of eyes review before code gets merged. But sometimes needs must. Though with adequately resourced teams, split across global regions this shouldn’t really be an issue for the largest of organisations.
Partial Maintainers
These may have direct write access to a small number of the teams projects, and whilst they may have push access they usually are unable to push direct to the main/master branch in these projects but can do so to any other branches that aren’t protected.
These maintainers have the power however to review, approve and merge PR’s in line with the project repositories policies.
They usually are, but aren’t always, employees of the organisation that is developing the projects.
Project/Feature Developers
These could be short term contractors that take ownership over a small section of a codebase and have been for a short time, granted maintainer access to help get that project/feature/s developed and merged into the codebase.
These may be from the same organisation or may be from the community as (ideally) paid or (more commonly) unpaid or may be contributors that are contracted in from a partner organisation.
They usually will depending on the project have anywhere from full maintainer rights to no direct code write access & work like those below that have collaborator access or may even be those that have read access and can fork and then submit PR’s to the project.
Automated Bots & Apps
This is an area that you want to be very careful with. Especially as lots of codebases can be obliterated due to misconfigurations of these bots & apps. You also must regularly review what has access and to where.
In fact, if you are reading this post, I must kindly instruct you to schedule time to do a review of these kinds of tools across your code bases as well as apps that are connected to your social media profiles, like Facebook, Twitter (X) etc & your email accounts.
Please also whilst your at it, schedule some time to go through and change passwords & set up MFA and a password manager if you haven’t already.
Without Code Write Access
Woo, now we get onto the more interesting areas of different types of code maintainer.
Collaborator Access
These are the individuals, that may help in Issue Triage and Pull Request reviews. They, likely, like myself, are knowledgable of the code base and may be a developer of new features, but have no ability to complete PR’s and merge them.
Automated Bots & Apps
There are many of these out there that like like dependabot, or other Security Scanning Applications, may help your organisation in keeping your code secure by scanning for known vulnerabilities or weaknesses in your code base.
Without any Code Access
There are many individual personas that whilst may never have code access they directly impact the products tha tare being developed.
Project/Program Managers
The most common is the classing of Project/Program Managers. These individuals may not even be coders but they work with those that do the code development as a sorta middle ground between them and general users.
Helpdesk and IT Administrators
Whilst both may do some coding, they often are the ones reporting issues that their internal users have reported to them, to the teams behind the products that they’ve provided their users.
IT Administrators that have significant code development and Application Lifecycle Management experience, including critical infrastructure for their organisations, are the most likely group of individuals, other than Application Developers, that are going to be the most likely to be, not only frustrated when the issue triage process, is slow, or seems to fall into a black hole and seemingly be completely ignored. They are the ones that you have to keep happy and keep a good dialog with. They also, are the types of individuals who will get extremely frustrated when processes seem to drag for extremely long amounts of time.
General Users
The more users that makes use of software or hardware that is produced, the higher likelihood issues will be caught and bugs fixed, this is if you give the users a quick easy mechanism to do so & importantly can have it collect & send logs automatically. However that also has headaches for the product development & support teams.
I remember when I was in a helpdesk role & a particular issue, accidentally created 15k incidents over the course of less than a week that took 6 months to solve for those users. However because of those 15k incidents, it was estimated by the team, that I ended up a part of, that nearly 1 Million incidents where not created as part of the completion of that project, as the fixes for those users (which were multiple issues per user) identified missing gaps that were a part of that projects overall deliverables.
Other kinds
There are other kinds of maintainers, that can include those that design how an application is put together, but may never write the code for it. These can often be called Architects, but also they may just be a General User that just thinks something doesn’t make sense and has no desire
Summary
Open Source or Closed Source software and the lack of quick churn on fixing bugs, as well as adding new features is both fun and infuriating.
An issue that should have been fixed and has had a PR raised for it should in Open Source not take years to get merged. I am one of these kinds of individuals & in my time just on the PowerShell Repo alone, seen PR’s that are stuck from as far back as 2022.
This isn’t just a PowerShell team issue, its a systematic issue of teams being significantly stretched thin and there not being enough people across all the above areas, to take parts of the workload off of the Full & Partial Maintainers. It also is kinda frustrating that when orgs like Microsoft have money in the bank they aren’t using it to the level they could to be able to make the open source world more sustainable, maintainable & actually directly offer individuals that do step up and help, some funding for doing so.
Oh, and no AI cannot be a drop in replacement for a human and our unique ways of thinking. Anyone that says that, is doing us all on this planet a disservice & forgetting that without the complexity of human social interaction, coupled with a desire to learn, adapt, adopt and improve, we would not have AI tools today. Even if they mostly are a massive dynamically generated IF -> ELSEIF -> ELSE statement & well they aren’t gonna replace skills like those of us in Software Development. Ever. Especially when we collaborate with other like minded individuals over long periods of time.
Software development is hard. Software Deployment is hard. Getting People to adopt software and implement good practices of its use, is hard.
This is why we have adoption processes, and why there are people like me that are recognised as Microsoft Global Community Innitiative Regional Leads as well as people who, I use to be like, in the Microsoft Most Valuable Professional, Regional Directors & Student Ambassadors programs that work with different teams across Microsoft that do what we can, when we can, to aid things like adoption of new software & the deployment processes of that software.
This is why I regularly create issues & submit PR’s to fix/improve/add to existing code & use my experiences as every single of the above persona’s to do what I can where I can, to improve things so that my skills have as much impact as I possibly can achieve. However, there is only so much I can do & unfortunately I have some pretty big decisions which leads to some big projects ahead of me that I must dedicate time to, as I can’t continue to serve the PowerShell community or the Software Development communities, when every month is a struggle & I don’t get enough to survive on.
Yes some may say “go get a job then” & I’ve spent so many wasted hours trawling through so many 💩 job adverts, which will be one of my #IRrrwR - Irregular / Ridiculous rants/rambles with Ryan! especially as I have already loosely designed a Presentation about how to manage your Job Search like a Project.
However, I’ve long said that we need Government led open source development funds as part of My 2024 Wishlist post however I’d been saying this in private for a long time beforehand too. I will not stop saying it until it happens.
Lastly
If you enjoyed this post, please share it & leave me a comment via the GitHub form (I have a outstanding task to add a link to a Microsoft Form if you don’t use GitHub) & please, if you can, I’d really appreciate it if you could look through the Hire-Me & Donation-Policy pages.
I have lots planned for the next month as well as the next 5 years & some of that stuff will happen sooner than I had been thinking & others may come later than I’d been thinking they would. But yeah I am incredibly frustrated with a lot of things atm and I am channelling that frustration into as many of my days as I can for as long as I can each day.
This post and the one coming next on my Windows 12 wishes; the return of Windows Phone & more is almost finished and needed me to finish this one, before I could post it.
I do hope this post is of use, and whilst I don’t think it’s been a waste of my time in writing, that’s because I know the importance of talking & writing,