I built MCNexus to solve the OFX plugin installation bottleneck

[Magno Ciqueira]

Hi everyone,

This is my first post here in the community, and I want to start by thanking you all for the help I've received over the last few years.

I want to give back by sharing something I built to solve a recurring problem in post-production suites. After creating an OFX plugin for color grading, I noticed that a lot of people struggled to install the tools on their computers. To solve this, I created MCNexus.

Basically, OFX plugin distribution and licensing have always been rigid processes, creating operational bottlenecks when it comes to maintaining compatibility and managing licenses. MCNexus works on two fronts to standardize this pipeline:

1. On the workstation (macOS/Windows Native App): Automates the allocation of binaries to the correct OS directories, handles updates, manages version rollbacks (essential for preventing breaking changes in legacy projects), and controls local keys.
2. For the developer (Infrastructure): Provides a standardized environment to publish commercial or open-source tools, so you don't have to build a deployment system from scratch.

The current architecture already features integrations configured for:

• Licensing: OpenKey (native) and Cryptlex (hardware-bound / node-locked licenses).
• Release Management: Direct integration with GitHub Releases, featuring protected downloads and channel segmentation (Beta, Demo, and Full).
• Commerce Automation: A workflow integrating GitHub (identity), Stripe (payments), and MailerLite (operational messaging).

The repository is public (Source-Available) for transparency and code review. If you develop OFX tools and are looking for a way to standardize the deployment and licensing of your projects, I invite you to check out the documentation and architecture.

Repository & Documentation: https://github.com/ciqueira/MCNexus

 

[Magno Ciqueira]

For those interested in seeing it in action, we already have a few integrated plugins up and running on the platform. You can check out the full list of connected tools here: https://github.com/ciqueira/MCNexus/blob/main/docs/DISCOVERY.md

 

[satoshi norikane]

Hi Magno,

Thanks for sharing MCNexus. I'm an independent developer preparing to release a color grading OFX plugin for DaVinci Resolve, and distribution and licensing are exactly the bottleneck I'm facing right now — so your project caught my attention immediately.

I've read through the README, the developer docs, the FAQ, and the roadmap, so I know code signing and notarization are already in "Current Work", an offline grace period is planned, and onboarding is per-project for now with a developer portal on the roadmap. It's a refreshingly honest set of documents.

One concern still keeps me from committing, though: continuity. Licensing and installation are the heart of a commercial product. With a single maintainer, a v0.1.x client, and a source-available license (so no fork-and-maintain escape hatch), what would happen to customers' ability to install and activate plugins if the project ever had to stop? Is any form of continuity guarantee under consideration — for example a documented wind-down policy, escrow, or a standalone offline activation mode beyond the planned grace period?

If there's a good answer to that, MCNexus would be a very strong candidate for my own release. The problem you're solving is real, and the architecture looks well thought out.

Best regards,

 

[Magno Ciqueira]

Hi Magno,

Thanks for sharing MCNexus. I'm an independent developer preparing to release a color grading OFX plugin for DaVinci Resolve, and distribution and licensing are exactly the bottleneck I'm facing right now — so your project caught my attention immediately.

I've read through the README, the developer docs, the FAQ, and the roadmap, so I know code signing and notarization are already in "Current Work", an offline grace period is planned, and onboarding is per-project for now with a developer portal on the roadmap. It's a refreshingly honest set of documents.

One concern still keeps me from committing, though: continuity. Licensing and installation are the heart of a commercial product. With a single maintainer, a v0.1.x client, and a source-available license (so no fork-and-maintain escape hatch), what would happen to customers' ability to install and activate plugins if the project ever had to stop? Is any form of continuity guarantee under consideration — for example a documented wind-down policy, escrow, or a standalone offline activation mode beyond the planned grace period?

If there's a good answer to that, MCNexus would be a very strong candidate for my own release. The problem you're solving is real, and the architecture looks well thought out.

Best regards,

Hi satoshi norikane,

Thank you for raising this. You’ve identified a real issue that I had not considered deeply enough from the perspective of a developer making MCNexus part of the critical infrastructure of a commercial product.

At the current scale, the infrastructure has substantial unused capacity and its baseline operating cost is negligible. My main investment today is development and operational time, along with development tools and the annual domain cost. This allows me to maintain the service during its early stage.

My intention, however, is not to promise a free service indefinitely. I am building MCNexus with the goal of turning it into a sustainable business. As adoption grows and infrastructure, storage, bandwidth, support, and maintenance begin to create meaningful costs, I expect to introduce a modest and predictable fee for commercial developers.

The objective would be to charge the minimum reasonable amount needed to operate and develop the platform responsibly while keeping it accessible to independent developers.

Since you are considering MCNexus for your own commercial release, I would genuinely value your perspective: would you be comfortable paying a reasonable recurring fee for licensing, activation, installation, updates, and distribution if that fee supported the long-term operation of the service? Would you prefer a fixed plan, usage-based pricing, or a combination of both?

That said, I recognize that financial sustainability alone does not answer your original continuity concern. Even a healthy paid service needs a plan for an unexpected or permanent shutdown.

The honest answer today is that MCNexus does not yet have a formal wind-down, escrow, or permanent offline-activation guarantee. I do not want to claim otherwise or promise a mechanism before knowing that it can actually be implemented and honored.

Your question has made it clear that continuity cannot remain only a future consideration. It must become a product and architecture requirement before MCNexus is offered as critical infrastructure for independent developers.

I am committing to adding continuity and tenant portability to the roadmap and to developing a documented and technically tested wind-down mechanism. Its intended scope will include:

• export of each developer’s products, licenses, entitlements, and release information;
• the developer’s ability to retain and redistribute their own release artifacts;
• a migration or standalone licensing path that does not leave existing customers permanently dependent on MCNexus;
• a documented procedure for an orderly shutdown, including the scenario in which I am personally unable to operate it.

The principle I want to follow is simple: developers should continue using MCNexus because the service provides value, not because leaving it would make their customers’ purchases unusable.

I cannot honestly present this as an existing guarantee today. What I can commit to is not presenting MCNexus as continuity-safe until there is a documented and technically tested mechanism behind that claim.

Thank you again for the thoughtful and constructive question. It has helped identify an important requirement for turning MCNexus from a working project into a responsible long-term service.

Best regards,
Magno

 

[satoshi norikane]

Hi satoshi norikane,

Thank you for raising this. You’ve identified a real issue that I had not considered deeply enough from the perspective of a developer making MCNexus part of the critical infrastructure of a commercial product.

At the current scale, the infrastructure has substantial unused capacity and its baseline operating cost is negligible. My main investment today is development and operational time, along with development tools and the annual domain cost. This allows me to maintain the service during its early stage.

My intention, however, is not to promise a free service indefinitely. I am building MCNexus with the goal of turning it into a sustainable business. As adoption grows and infrastructure, storage, bandwidth, support, and maintenance begin to create meaningful costs, I expect to introduce a modest and predictable fee for commercial developers.

The objective would be to charge the minimum reasonable amount needed to operate and develop the platform responsibly while keeping it accessible to independent developers.

Since you are considering MCNexus for your own commercial release, I would genuinely value your perspective: would you be comfortable paying a reasonable recurring fee for licensing, activation, installation, updates, and distribution if that fee supported the long-term operation of the service? Would you prefer a fixed plan, usage-based pricing, or a combination of both?

That said, I recognize that financial sustainability alone does not answer your original continuity concern. Even a healthy paid service needs a plan for an unexpected or permanent shutdown.

The honest answer today is that MCNexus does not yet have a formal wind-down, escrow, or permanent offline-activation guarantee. I do not want to claim otherwise or promise a mechanism before knowing that it can actually be implemented and honored.

Your question has made it clear that continuity cannot remain only a future consideration. It must become a product and architecture requirement before MCNexus is offered as critical infrastructure for independent developers.

I am committing to adding continuity and tenant portability to the roadmap and to developing a documented and technically tested wind-down mechanism. Its intended scope will include:

• export of each developer’s products, licenses, entitlements, and release information;
• the developer’s ability to retain and redistribute their own release artifacts;
• a migration or standalone licensing path that does not leave existing customers permanently dependent on MCNexus;
• a documented procedure for an orderly shutdown, including the scenario in which I am personally unable to operate it.

The principle I want to follow is simple: developers should continue using MCNexus because the service provides value, not because leaving it would make their customers’ purchases unusable.

I cannot honestly present this as an existing guarantee today. What I can commit to is not presenting MCNexus as continuity-safe until there is a documented and technically tested mechanism behind that claim.

Thank you again for the thoughtful and constructive question. It has helped identify an important requirement for turning MCNexus from a working project into a responsible long-term service.

Best regards,
Magno

Hi Magno,

Thank you for such an honest and thorough reply. "Not presenting MCNexus as continuity-safe until there is a documented and technically tested mechanism behind that claim" is exactly the kind of statement that builds trust — and the scope you outlined (data export, retaining and redistributing release artifacts, a migration/standalone licensing path, and a documented wind-down procedure) covers precisely the gaps I was worried about. I'll be watching the roadmap for these.

To answer your pricing question: yes, I would be comfortable paying a recurring fee. Honestly, I see a sustainable paid model as a positive — a free service that depends entirely on the maintainer's goodwill is itself a continuity risk. A service I pay for is one I can reasonably expect to stay alive.

As for the structure, here's my perspective as an independent developer preparing a first commercial release:

- Fixed costs before revenue are the heaviest burden. At the stage where I have zero customers, even a modest monthly fee competes with code signing certificates, notarization, and payment processing fees. A free or very small base tier for pre-revenue developers would remove the biggest barrier to trying MCNexus.

- Once sales start, usage-based pricing tied to activations or license issuance feels fair and scales naturally with my success. I'd happily pay more as I sell more.

- So my preference is a combination: minimal (or zero) fixed base + usage-based component, with predictable caps so costs never surprise me.

One condition though: the continuity mechanism we discussed is a precondition for me to build a paid dependency on MCNexus. Paying for a service makes the "what if it stops" question more important, not less.

Thanks again for taking the question seriously — it's rare to see this level of transparency from a project at this stage.

Best regards,
Satoshi

 

[Magno Ciqueira]

Hi Satoshi,

Thank you — your feedback strongly aligns with one of MCNexus’s core goals: to be a practical and accessible starting point for independent developers, within reasonable operational limits, without adding heavy fixed costs before their products generate revenue.

Your suggested model — a free or minimal pre-revenue tier, followed by predictable usage-based pricing with clear caps — gives me a valuable direction. I’ll validate it against the real infrastructure and support costs before defining final pricing.

I also fully understand that continuity is a precondition for your adoption. I will make this work explicit in the roadmap and treat it as a requirement before presenting MCNexus as a production SaaS dependency.

When your plugin is ready for release, you can count on my direct support with the initial integration, onboarding, and launch process. Helping independent developers through that critical first-release stage is part of MCNexus’s purpose.

Thank you again for helping shape the project.

Best regards,
Magno