I think there is some crud which still makes it hard to adopt DEV.to to launch your own platform because parts of the codebase need to be more vanilla so people are comfortable launching their own instances.
I wish I had the time, but I would love to launch a Cloud Computing version of DEV.to that is more niche in terms or tagging. I think DEV.to really needs someone to adopt an alternative to push it so it can be more agnostic.
I think if we want to make the platform-agnostic we need to start moving sections of the codebase into Rails Engines to prepare them to be their own repo.
Once you have a vanilla codebase and modular codebases you create provisioning scripts for multiple multiple cloud providers.
It just depends on how you want to monetize. Is it the platform or the traffic or both?
Yep, this falls into stuff we more or less have agreement on as far as how we get there. There is a long list of challenges ahead which we haven't wanted to address because the number one way we fail is losing touch with the basic needs of running this single DEV instance.
In the past few weeks, mostly since @molly_struve
and @jacobherrington
joined the core team to bring relevant experience and new perspective, we've begun truly thinking through some of what you're describing. But we're giving ourselves a long leash in terms of eventually making this codebase appropriately agnostic and technically efficient.
We'd eventually like to provide a few managed options and do support for the ecosystem alongside continuing to thoughtfully monetize this and any other networks we spin up to operate ourselves.
I think there is some crud which still makes it hard to adopt DEV.to to launch your own platform because parts of the codebase need to be more vanilla so people are comfortable launching their own instances.
I wish I had the time, but I would love to launch a Cloud Computing version of DEV.to that is more niche in terms or tagging. I think DEV.to really needs someone to adopt an alternative to push it so it can be more agnostic.
I think if we want to make the platform-agnostic we need to start moving sections of the codebase into Rails Engines to prepare them to be their own repo.
Once you have a vanilla codebase and modular codebases you create provisioning scripts for multiple multiple cloud providers.
It just depends on how you want to monetize. Is it the platform or the traffic or both?
Yep, this falls into stuff we more or less have agreement on as far as how we get there. There is a long list of challenges ahead which we haven't wanted to address because the number one way we fail is losing touch with the basic needs of running this single DEV instance.
In the past few weeks, mostly since @molly_struve and @jacobherrington joined the core team to bring relevant experience and new perspective, we've begun truly thinking through some of what you're describing. But we're giving ourselves a long leash in terms of eventually making this codebase appropriately agnostic and technically efficient.
We'd eventually like to provide a few managed options and do support for the ecosystem alongside continuing to thoughtfully monetize this and any other networks we spin up to operate ourselves.
I do feel I should say sorry to you Ben. You've probably heard my complaint about modularizing one too many times now.