I’ve been working in IT for 32 years.
Most of my time in IT has been focusing exclusively on Microsoft technologies.
Over 18 years of this time was working with SharePoint and CRM.
But something is happening at Microsoft. It has been happening for a while, but it is definitely happening.
Microsoft is changing from the company everyone (but me) loves to hate, and it is becoming cool. Well, cooler.
Microsoft is shifting its focus to open source.
Since 2004, Microsoft has increased its number of open-source projects. Their products and components went from closed-source that gave little consideration to third-party developers to open-source.
In fact, Microsoft is now the biggest open-source contributor in GitHub. Over Facebook, Google, Docker.
I never thought I’d see the day.
These open-source initiatives attract talented contributors. Developers who feel passionate enough to spend their own time and donate their time to make the products better.
Those contributors (Microsoft employees and volunteers) work together. Regardless of who they work for, where they live, their culture, or their degrees of expertise. Even people who work for competitors put their “differences” aside and work together.
And then something amazing happens: they become a community.
They work together to help each other. They also help anyone who wants to use the repositories for their own projects. They answer questions, they fix bugs, they help people diagnose issues.
One such community is the SharePoint Development Community.
The SharePoint Development Community is a community built around an initiative called Patterns & Practices (PnP). The PnP initiative includes guidance on best practices around SharePoint, code samples, Office 365 APIs, Office Add-ins, SharePoint Frameworks, developer controls, starter kits — and many more.
Someone who played a big role in making the community what it is today is Vesa Juvonen.
Vesa is a Senior Program Manager within SharePoint engineering. He works with the team responsible for the SharePoint customizatin model. He also leads the virtual teams who created the various (and awesome) PnP initiatives.
Patrick Rodgers, who is a Senior Program Manager with Microsoft FastTrack, and a lead for PnPJs also plays a big part in this community. Apparently, he’s a mediocre bowler, but he’s a great community builder.
I’m sure that there are many other people at Microsoft who deserve the credit for this, but Vesa and Patrick are the two “faces” that you see in most calls, presentations, videos, conferences, etc.
If anyone knows who else at Microsoft deserve credit for the SharePoint Development Community, please let me know. They definitely deserve our thanks.
Patrick, Vesa, and their teams do an amazing job educating and sharing with the community, but also listening to the community.
They also work hard empowering the community to build something better. If the times that Vesa accepts and closes pull requests on the SharePoint repos is any indication, they work above and beyond 9 to 5, Monday to Friday.
They don’t have to go the extra mile. They don’t have to be entertaining and engaging. They could just ignore non-Microsoft people and build a product without asking the community. After all, that was the standard m.o. for Microsoft for the longest time.
And then there are all the other superstars of the SharePoint Development Community. Those who don’t even work for Microsoft, but take an active role in the community.
People like (pulled from the top contributors in GitHub):
…and many more. There are too many to list (I actually feel guilty not listing everyone here. I’m sorry if I missed anyone).
All whom have real jobs. Most of them maintain active blogs, tweet, and contribute to the SharePoint Development Community. Oh, and they probably have a families and have to sleep, some time. (I also secretly believe that one of them works with SharePoint during the day, and fights crime at night).
All those people contribute because they care. Because they are passionate. Because they want to help.
More importantly: they are welcoming. I’ve contributed a few tidbits in the PnP and SharePoint repos and they have never made me feel out of place. I’ve never felt like I was an outsider trying to get in a tight clique.
So why am I writing such a lengthy post about the SharePoint Development Community?
Because I’ve noticed that people are getting nasty.
More and more, I see new issues in the various GitHub repos where people post rude comments, or use an otherwise unkind tone.
I don’t know if it is because they think that every contributor is a Microsoft paid employee, and that it is everyone’s job to drop everything to help them, or because they were raised by wolves, but there is no need to be nasty.
If you open a sample web part that someone built over a year ago — code that they shared with everyone to help grow the community — and it doesn’t work because the libraries have since changed, you don’t need to get offended.
They didn’t break the web part on purpose.
If you try to use a PnP API and it doesn’t quite work the way you expected, they didn’t plan to break it so that it would ruin your day.
If the documentation for something that changes every week is not quite up-to-date, don’t get offended. We don’t keep a second set of secret documentation that is more accurate just to mess with you.
Don’t turn this into a evil-Microsoft-is-at-it-again thing.
The people who contribute are all people, like you and I, who have jobs and families.
I get it.
Your boss is bugging you to get stuff done. Your clients are all in a hurry to see something delivered.
You run into an issue with SPFx, PnP, code samples, or documentation. It is frustrating.
Everyone who contributes to the repositories have experienced the same thing.
Everyone is willing to help. Otherwise, they wouldn’t contribute.
So if you submit an issue, be kind. Be considerate.
We want to help. Don’t submit an issue that says:
This stupid thing doesn't work
It doesn't work
…because we can’t help you.
Help us help you!
Take the time to fill the issue forms. They all have guidance. Take a second to read the guidance and follow instructions.
For example, here is the start of the sp-dev-fx-webparts issue form:
Use the following form to submit an issue only if it’s related to samples in this repo. If you have an issue related to the SharePoint Framework or its documentation, please submit the issue at https://github.com/pnp/sp-dev-docs/issues/new. This will help us respond to your issue faster.
Thank you for reporting an issue or suggesting an enhancement. We appreciate your feedback – to help the team to understand your needs, please complete the below template to ensure we have the necessary details to assist you.
_(DELETE THIS PARAGRAPH AFTER READING
Notice that it says DELETE THIS PARAGRAPH AFTER READING ? Go ahead, delete it before submitting your issue.
Why? Because everyone who follows the repository gets a notification when you file an issue. If they are like me, they probably receive a notification on their mobile device. They check the issue on their way to a meeting, or while waiting for the barista to mess up their names again.
You have very little of their time to get their attention. All that text you didn’t remove gets mixed up with whatever information you provided about your issue. If they can’t make sense of your issue, they may put your issue aside until they have time to make sense of it.
If you see a section like this:
## Category - [ ] Question - [ ] Bug - [x] Enhancement
Just put a x in the right category and leave the other ones empty (with a space between the [ and the ]). It helps those who want to help quickly categorize and triage your issues.
If you have a problem with any of the Web Part Samples, take the time to fill the Authors section of the issue form. The instructions are quite clear:
Because of the way this repository is setup, samples authors do not get a notification when you create an issue. It makes it less likely for you to get your issue resolved or to get help. For the section above @mention any author of the sample. Authors’ GitHub handle can be found on the main sample documentation page, under the “solution” section. Use the
PREVIEWtab at the top right to preview the rendering before submitting your issue.
For example, if I messed up one of my sample web parts, make sure to add @hugoabernier in that section. It will notify me, and I’ll gladly help. As would almost every other person who contributed a sample.
If you find an error in the documentation of the code, feel free to make the changes and submit a pull request. The contributors are people just like you.
And if you can’t contribute, because you’re too busy or you don’t know what the fix should be, keep in mind that everybody else who contributes probably doesn’t have time, or may not have the right answer — just like you. They all have to make the time to find a fix and make the changes.
Microsoft has come a long way.
SharePoint — from codename Tahoe to what it is today — has changed a lot too. It constantly becomes better.
Someone at Microsoft took a leap of faith one day and decided to build this amazing SharePoint Development Community. They broke all the rules, broke from tradition, and gave us a place where — together — we can all build something even better. From what I would guess, they probably spent a lot of their own time to make this happen before gaining support from management.
Whoever took the first step, and all those who supported them (and continue to support them) deserve our thanks.
Everyone else who contributes to the community makes every one of our jobs easier every day by paving the way with samples and best practices.
They all deserve our respect and thanks as well.
I truly hope that other areas of Microsoft take the example from the SharePoint Development Community and builds their own community. I’m looking at you, Dynamics 365 — we could use a CRM Framework to build better CRM solutions. (And I’ll help!)
Until it becomes a widely adopted model at Microsoft, we should all appreciate what we have and treat everyone kindly and respectfully.
Please forward this message to everyone who deserves our gratitude.
Thanks to Yannick Plenevaux (who, frankly, also deserves to be on this list) for pointing out that I forgot to mention Bert Jansen in the list of Microsoft people who go above and beyond. Bert is a SharePoint service engineer who does a lot of work with SharePoint PnP (processing pull requests, issues, running test automation and teletry). To quote Yannick: “[Bert]’s an amazing coder! The father of modernization tooklit”.