I do this as well - - everything from the JavaScript framework, to the ORM, to the web-framework is built or assembled by me. I even use my own special databases built on top of Tokyo Tyrant and Redis. It's basically my world where I know every part of the system. This makes me super productive and I can change anything. It's also a great learning experience. This said there is a huge problem with this approach and it's scaling your development team... It's hard for people to figure out how stuff works in an environment where nothing is standard.
My plan to solve this is to open-source my tools/libraries and switch to Flask, so at least some of the stack is familiar. Open-sourcing these tools will force me to isolate them, clean them up and write some documentation - - it can benefit other people and maybe open a pool of developers that know the tools better.
"My plan to solve this is to open-source my tools/libraries"
Quick advice: Don't. You'll make it worse.
You're already undermining your thing in that first sentence ("switch it to X so that other people will understand it"). Turning an in-house framework into a "ready for the real world" framework is a ton of work and will invariably need to dull down the sharp edges and general case a bunch of things.
The thing is, those sharp edges are what make it such a good tool. You want sharp edges on your tools. Dull tools might not hurt anybody else but they won't be as good at doing what they do.
You've got something that works really well for you. Chances are it's so focused towards your workflow and way of thinking about the world that it just won't be all that useful to anybody but you. That's just fine.
Trying to make it useful for everybody else will only succeed in making it less useful for you.
Hey Jason. The general problem is hiring people when you use a lot of internal tools - - as some of them are made in a haste and are hackish, and most of them don't really have good documentation. But maybe you have a point and the first step could be to clean the tools up and write some internal documentation for them.
> My plan to solve this is to open-source my tools/libraries and switch to Flask, so at least some of the stack is familiar. Open-sourcing these tools will force me to isolate them, clean them up and write some documentation
Pretty accurate… I like your idea of how to solve it… You can do it the other way around too, have/ask a coder with whom you work spend at least some time on cleaning up and documenting the code… Sounds like a lot of extra effort, but they are already trying to understand and conceptualize the thing for themselves, might as well write it down…
No framework approach only work for a one person team or very small team and by design cannot scale.
As soon as you try to bring somebody that will mainly "use" those tools/libraries instead of actively developing them, the tools/libraries becomes a de-facto framework to them, just a proprietary one with no community.
If/once you open-source it, it just becomes another framework competing with the other ones.
My plan to solve this is to open-source my tools/libraries and switch to Flask, so at least some of the stack is familiar. Open-sourcing these tools will force me to isolate them, clean them up and write some documentation - - it can benefit other people and maybe open a pool of developers that know the tools better.