Table of Contents
Success of PowerShell Based on Community Values
The success of PowerShell is firmly rooted in strong community involvement and the willingness of people to share their knowledge about how to get things done. This has been the case for as long as I have worked with PowerShell (starting with Exchange 2007 in late 2006). I learned from many and gradually moved from total novice status to become mildly competent. Some would say dangerously incompetent, but that’s another discussion.
Part of being in a community is acknowledgement of the work you reuse from others. If you find some useful code in a script written by someone else, incorporate the code into your script and include an acknowledgement of where the code came from. It’s simply being polite.
Reporting Room Mailbox Statistics
Which brings me to a post from the Office 365 Reports company on May 23 about reporting room mailbox statistics (Figure 1). This is an area that I know well. I covered it in a Practical365.com article in December 2022 and revised my script to add extra reporting capabilities in February 2023 following reader feedback for the original article.
Seeing the post in the Facebook PowerShell group, I opened the link to read the article to discover that much of the code in the script was lifted from my script posted in GitHub. No attempt was made to hide the source of many lines of code, which was copied and dropped into the Office 365 Reports script. Even the most cursory of examinations reveals the extent of the copying.
It’s true that the Office 365 Reports version uses the Microsoft Graph PowerShell SDK where I use an Azure AD registered app as the source of authentication to access the data held in room mailbox calendars, but look beyond that to the output and you’ll see where the copying happened. Figure 2 shows a screen shot published in my February 2023 article. Look at the summary for individual room mailbox statistics. Doesn’t that look very similar to the output generated by the Office 365 Reports version?
Any PowerShell script might produce rudimentary output that looks similar to other scripts. But if you examine their script, you’ll find many matches with the original code. In short, Office 365 Reports were lazy and copied code without bothering to hide their traces.
Poor Behavior From a Commercial Company
I have a real problem with this behavior. First, no one from Office 365 Reports (or AdminDroid, their associated company) contacted me to ask if they could reuse my code. Instead, Office 365 Reports went ahead and copied many lines of code (including a bug that I subsequently fixed) from GitHub and published their script. They didn’t bother responding to the comment I made to their Facebook post either.
Second, they didn’t bother to acknowledge the original source of much of the code in their script. I did not grant Office 365 Reports the right to reuse my code for commercial purposes, which is what they have done by including the code in a script developed to attract interest in Office 365 Reports and AdminDroid.
Plagiarism is Never Justified
I don’t like slamming companies in public, but I hate when companies like AdminDroid seek to benefit from the work shared freely within the PowerShell community. My suspicion is that this is not the first time that Office 365 Reports and AdminDroid have “borrowed” code from the PowerShell community to advance their commercial interests. I also don’t like the way that they post articles under assumed names like Kathy Cooper. I don’t believe that such a person exists. It’s just a nom de plume used to disguise whoever writes the articles.
If the people behind AdminDroid and Office 365 Reports want to contact me, I’m happy to hear their side of the argument. But right now this looks like a simple case of plagiarism. If that’s the way AdminDroid operates, why would anyone use their products?