Questions: The Bogus open-source project

[bchavez]

Hi everyone,

I think what the .NET Foundation is doing is great with OSS projects and kinda wanted to talk about a few things.

I'm the maintainer and creator of github.com/bchavez/Bogus. NuGet here. Bogus has 2.7M NuGet downloads and 2,279 GitHub stars. Probably somewhere in the top 40 C# projects on GitHub. Also, Microsoft has started taking a dependency on Bogus (see Microsoft Docs here).

The TL;DR; on Bogus is that it's a really cool library that helps generate realistic but fake-looking data. Generally, you use Bogus to test UI or seed databases with test data.

I'm trying to decide if pursuing the Project Maturity Model is right for Bogus. I care very much about my users and that's the main reason I'm here.

Sometime in 2015, I wrote Bogus to test my applications for .NET. Also, I wanted Bogus to fill a huge gap in the .NET ecosystem. Bogus seemed to solve the same problems that many other developers had too; hence the success thus far.

The foreseeable future of Bogus still seems bright because the issues of privacy and protecting personal information are still hot button topics in tech.

I don't want to say I did it alone because I've had some great PRs from absolutely fantastic contributors. But for the most part, the whole operation has been a one-person show; from making all the design decisions to code reviews and releases, etc. I really love maintaining Bogus. I don't suffer from maintainer burn out in any way shape or form.

At some point, I decided to monetize on the success of Bogus by creating Bogus Premium (a closed-source project, not available on GitHub). Premium is a paid yearly subscription that extends Bogus' datasets with industry-specific data like Idc9 medical codes for the health-care industry. Premium also offers some extra tooling making Bogus easier to use. The purpose of Premium was also to establish a sustainable model for the core Bogus project.

Licenses for Bogus Premium are sold by my very small 1-2 person business Bit Armory Inc. So far, I've had customers from governments and corporations to individual developers supporting Bogus through their licenses of Premium. I thank soo much and love each paying customer because they help me eat and pay rent at the end of the day. :heart:

My questions are:

• How would the .NET Foundation view Bogus participating in the Project Maturity Model?

• Is it okay to have a project both maintained by .NET Foundation and Bit Armory Inc even though profit is generated by Bit Armory Inc through Bogus Premium? Bogus is technically an independent project licensed under the MIT license. Bogus Premium builds on and extends the underlying Bogus package when used together.

• The PML Level 2 policy mentions "reproducible" builds; could someone clarify how "reproducible" a project should be? Specifically, the Bogus (Bogus.dll) open-source core assembly is signed with a private key that cannot be decrypted by the public; so reproducing binary equivalents is not possible. The public can build Git hash equivalents without the private key, but the private key is not available to sign the assembly with the same signature as the one published on NuGet. I'm okay with giving access to this private key to my successor, but it should remain private. Additionally, protecting the private assembly signing key from public use is also an important part of the licensing mechanism for Premium. https://github.com/bchavez/Bogus#build-environment-variables

  If FORCE_VERSION environment variable is set with a semantic version number (eg: x.y.z), the build tasks will use the FORCE_VERSION to produce builds with the exact version number. Useful for testing out-of-band custom builds. However, it is not possible to reproduce exact binary equivalents of released NuGet packages because packages release on NuGet contain assemblies that are digitally signed with assembly signing enabled. The public does not have access to the signing key.

• I'd like to maintain benevolent dictator status as long as I'm alive maintaining Bogus; much, in the same way, Microsoft maintains control over the "open" C# language spec. Will the .NET Foundation impose restrictions to this type of governance model under its umbrella? What if Bogus tries to pursue PML Level 3 and 4 where Health: >1 maintainer is required?

• PML Level 1, 3 and 4 mentions requiring "stable versions"; what does that exactly mean? Bogus has an aggressive release cycle. The aggressive release cycle, in part, I think has contributed to the success of the project because being responsive to user issues and fixing bugs immediately is important. I don't wait for years, months, or weeks, to release a fix. Usually, releases are done within 0-48 hours. If 1,730 unit tests pass on master a release is tagged immediately.

  As you can see, v28 has indicated some 28 breaking changes since v1 (mostly deterministic PRNG behavior changes and lesser API changes); but it hasn't been an issue for some 2.7 million downloads. Nowadays, I'm much more conservative when making changes to public APIs; but I don't hesitate to break if it's really, really, really important and breaks are clearly identified in the changelog.

I just wanted to get a sense of the scope of the .NET Foundation's new project maturity model and see if it could strengthen the future for Bogus users. Thank you for your time and congrats on .NET Core 3 :balloon:

Thanks, Brian Chavez

[clairernovotny]

Hi Brian,

Great questions! I'll let some of the others chime in as well, but I had one question about the assembly signing you mention -- do you mean strong naming the assembly or something else? For OSS projects, it's considered a best practice to check in the strong name key to the repo. Strong name keys do not provide any security, it's pretty much just a cryptographic name. They're only verified on .NET Framework, and only in very limited circumstances (installation to the GAC and loading in another AppDomain). It's ignored on any other platform.

For versioning, we still need to work out the details on what reproducible means. I would tend to expect it to be based on a file committed to the repo, like a version.json. Tools like Nerdbank.Gitversioning work very well here, auto versioning based on a seed file so that any commit is reproducible.

I don't see any inherent reason you can't have a core MIT licensed project and then build on that into a closed-source private product. That's perfectly within the scope of the MIT license.

[bchavez]

Hi Oren,

My apologies for the confusion! Thanks for the response!

You're right, I was referring to the strong naming of the Bogus.dll core assembly. The strong name key is available in the Bogus repo named as Bogus.snk.enc; however, the strong name file key is encrypted and can only be decrypted on CI/CD when I've tagged the repository with a version number for a release using my GitHub account.

Users are free to compile Bogus using their own strong name unencrypted .snk file; however, the Premium tools manually inspect the public strong name of Bogus.dll at runtime on their own terms independent of the runtime's verification checks. If the public strong name wasn't created with the decrypted Bogus.snk.enc the Premium tools won't work.

Also, the license verification algo is public and part of the Bogus.dll core assembly. The public is welcome to change the algorithm but doing so and using a different .snk file won't circumvent the licensing for Premium provided the closed-source tools aren't cracked too.

Another reason I prefer to keep the strong name key private is there was a false-positive security incident related to Windows Defender + Bogus back in May. It seemed easier tell users to sn -vf Bogus.dll and provide them with public key info rather than to provide an exhaustive set of SHA256 hashes of specific cross-platform versions of Bogus.dll to ensure nothing had been tampered with.

[richlander]

First, congratulations on building a project that you love and that has enabled you to create a business. That's awesome and I enjoyed reading your story.

Everything you wrote seems compatible with this program. The program is "pro-open source" and is absolutely not "anti-commercial". There are specific call outs in the doc for corporate-backed projects, so that is a good indicator that commercial scenarios are a key part of the story, as long as they are open source.

We'll write more on reproducible builds. I hadn't thought about the issue with keys, so that's a good use case to cover when we write up docs on it.

As @onovotny is kindof suggesting, you may be placing more emphasis on strong name signing than is deserved. That said, the model you have with your premium tools seems fine.

If that's enough, feel free to make a PR to register your project. Otherwise, we can answer more questions.