This project although popular on nuget for downloads appeared to have been for the most unmaintained as the last update to the nuget package had not occurred in approximately in almost 2 years  and before the last update was over 6 years ago which in terms of computer software is something comparably to the rise and fall of entire programming paradigms as in functional programming rise over object oriented and the disuse of aspect oriented or at least its consignment to java (and rebranding as microservices 😀)

I wanted to add some new fake data generators for the program in particular the following

  • Faker.Identification.Next() - Using a true random number generator instead of the more predictable Random.Next within .NET
  • Faker.Identification.MedicareBeneficiaryIdentifier() - The new Medicare unique identifier to be used in lieu of Social Security Numbers from 2020-01-01. Example : 8NK0Q74KT53
  • Faker.Identification.SocialSecurityNumber() - Create an approximate reasonable SSN, not complete but of enough quality to appear valid in most cases.  Example : 249-17-9666
  • Faker.Identification.DateOfBirth() - A gaussian random number birth date from now with a max of 120 years and normalized over a +/- 46 years from the midpoint. Example : 1971-11-16T00:00:00.0000000Z

How did I encourage the maintainer to accept this new functionality?  By making a pull request that helped out with organizing the project and bring it up to date with the latest versions and making sure there were tests to go along with my changes and this part gets left out a lot include documentation.

Also of help was to be polite and helpful with making any changes desired of the pull request.  Now the project has the changes I desired and is available for others to use in Open-source software projects.

So when you want to make a change to an existing popular library or framework in OSS I recommend the following tips

  • Be polite
  • Solve the problem (don't expect the maintainer to make the effort to fix your problems)
  • Make it easy for the maintainer to verify, test, and understand your change
  • Follow the format of the maintainer(s) and be flexible