The best way for me to describe this best practice is to use an anti-pattern as an example.

I once came across a Puppet developer who would start a module completely from scratch, and then copy and paste lines of code from a Forge module into the new module. From then on, that module exists entirely outside the community! It's not a fork even, so to integrate changes that have been made over time from the community becomes a real pain. You would have to cherry-pick those changes to get the functionality into your own, and you will probably still be left with regression problems. Generally, a best practice is to always at the very least fork the Forge module! This means you get the Git history, which often contains the thoughts that have gone into producing that module.

You see, if you were ever a reader of the great book The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary (https://www.amazon.com/Cathedral-Bazaar-Musings-Accidental-Revolutionary/dp/0596001088), then you will understand that the Linux-orientated philosophy of software development through a bazaar, collaborative working style trumps spinning off development into a cathedral, independent working style. Well, that's my take on this developer's working style. He was working cathedral-ly, as opposed to bazaar-ly. Effectively, you are making the decision to pit your cathedral team against the multitude of the bazaar, and to my mind, that's simply not wise project management when it comes to giving you a competitive advantage in the internet age.

Sometimes, modules on the Forge get a bit out of date. If the metadata for the module is out of date, you can always produce that again using the PDK new module command (https://puppet.com/docs/pdk/1.0/pdk_generating_modules.html#create-a-module-with-pdk) and commit the new metadata.

Of course, to be a great Puppet community member, it would be an even better practice to make pull requests for the changes you have made and contribute to the work of the community.