@pleerock please create a tweet about this and ask for retweet at least. Also it makes sense to wrap this huge text into a medium post

havenchyk on 17 Dec 2018

👍29

I just want to add that this Open Source project is maybe one of the best open source projects I have ever seen around. You guys are doing a really amazing job!!!

ematipico on 18 Dec 2018

👍82 ❤44

@ematipico thank you!

pleerock on 18 Dec 2018

I totally agree and understand you! May be you should:

Place this description and sponsors at beginning of README, not end.
Instead of just "Sponsors" section, ask for action to become a sponsor.
Place short description of your challenges and link to open collective in the issue template. Ask for high quality reports.
What's about tweet and other posts in social media, as asked by @havenchyk? We want to share it.

EDIT: found the tweet: https://twitter.com/typeormjs/status/1074728123554586624

Bessonov on 31 Dec 2018

👍5

Why not use Open Collective https://opencollective.com/
I use that site to give money to Dokku.

Just a thought :smile:

AnthoniG on 15 Jan 2019

@AnthoniG we are using OpenCollective

pleerock on 16 Jan 2019

@pleerock what about Patreon

rustamwin on 16 Jan 2019

👎2

@rustamwin what is the point of using two donation systems? I guess donator doesn't care about where to donate?

pleerock on 16 Jan 2019

Some donators maybe use Patreon

rustamwin on 16 Jan 2019

👎2

@rustamwin for me two donation system just confuses thing and for me it looks like people won't know what system to use for donation. I'll create a Patreon if any donator ask for it.

pleerock on 16 Jan 2019

Place this description and sponsors at beginning of README, not end.

If we can get the investment, we will donate to typeorm soon, thanks to the contribution of typeorm.

zuohuadong on 19 Jan 2019

👍10 ❤1

broke the 10k milestone :-)

consense on 28 Jan 2019

❤15

Donated. Thank you. A donation is a small price to pay for an excellent library that has saved me hundreds of hours.

dcworldwide on 27 Mar 2019

👍5

Dear developers. I want to say that the problem can not be only on one side.

I could write my projects using your ORM, and give a part of my earnings to you. So I always did, that's the way it should be.

But if I am writing a project for production, this means that I can not find time to contribute to your ORM. I need a stable solution to write a project on time, and do not exceed the deadline.

That moment came recently. As technologies for the new project, I chose Nest.js and of course, TypeOrm. I recently found a trivial issue that I reported to you. You have not answered the fourth day. Let me remind you, I have a deadline. What should I do at such moments? Right. Search alternatives.

Please do not think that I am angry with you. I'm just trying to explain to you how things are on the part of the developers. I guess you think that everyone is using your development, and no one wants to share money with you. It is not always so. I could, but I had to find another solution.

We do not work full time because people do not donate us. People don’t donate us because we don’t work full time. It's a vicious circle. Someone has to break out of it. And in opensource projects it should always be a developer. Because he initially understood that opensource is deferred earnings. First he does, then he earns. So, can you first close 600+ issues, and then talk about donations? ;)

I very much hope that you will not take my message as a simple flash of aggression and extract from it a useful idea for yourself. In the meantime, I will again write a project on Django. I really hope that I will write the next project using your ORM. Good luck :)

trixden on 29 Mar 2019

👎103 😕26 👍8 😄2

So, can you first close 600+ issues, and then talk about donations? ;)

@trixden its not a reasonable request. We already have 2400 issues closed, and it took HUGE amount of time, years of full time work. Do you think many people whom I already helped started to donate? When people's issues are resolved they simply disappear, nobody cares about doing something else. Nobody understands how much time and efforts it took for developers. Nobody appreciate exist job that already have been done. You already have a great product, that deserves many, and you are asking about even more not doing anything for what you already have. I have spend over 100k of my own resources to bring what you already have right now. Did you think about it before using it for free? Don't you think to give something for what you already have? Closing 600+ issues will take another year to resolve if I work full time on TypeORM, are you suggesting me to quit job and start working on them? Of course I can't afford it myself. The only solution is to ask people for donation, wait when enough people do it, then start doing the job. I understand you are a new user and face problems like this, but what you are asking doesn't make sense. There are other people who appreciate exist efforts that they already have for free and are interested to help to make it even better and this ticket opened for them, not for people who are used to use other efforts for free and never return something back.

pleerock on 29 Mar 2019

👍72 ❤22

@pleerock i realy understand you, and it's very sad. Yes, If there are many projects in production written with TypeORM, and developers donated nothing, this is very bad. I understand that behind this free project there are long works of developers. If I had written at least one project in production using TypeORM, believe me, I would have done so that I was not ashamed of the questions you asked above. But now i can't do that.

trixden on 29 Mar 2019

👎27 👍1

Strongly disagree with @trixden . It's not how open source works. Open source is about sharing. @pleerock already made the first move and spend enough time to create this great product, which can compete with more mature alternatives. So, what did you done for TypeORM, @trixden? Create an issue report? Great! But why should anybody care about it in the free time? @pleerock care about that. But wait, why don't you contribute to TypeORM and create a high quality pull request to fix your issue? Why don't you want spend your free time, like @pleerock already did? Do you feel open source spirit?

Bessonov on 29 Mar 2019

👍31

@Bessonov did you read my first comment? There are all the answers to your questions. I did not say that this is a bad project. He is so good that I spent three days on it.

trixden on 29 Mar 2019

Whoa been battling with alternatives for literally weeks. I did everything I wanted in two days with Typeorm including converting all our old model code. I felt like a godlike programmer for once. I'll kick some beer money. I'll talk to my work about some real money.

kferrone on 5 Apr 2019

@kferrone sounds great, thank you!

pleerock on 5 Apr 2019

@pleerock as a maintainer of another open source project that's gone through similar questions over the years about sustainability and dealt with issue overload, I just wanted to say great work with TypeORM and I wish you all the best making it sustainable.

Open source responsibility isn't a small amount of work and it looks like you've been doing an incredible job with this project. Good luck from here ❤️

JedWatson on 8 Apr 2019

👍20 🎉12 ❤9

Thank you for the amazing work. Just donated and hope the this picks up more momentum and typeorm keeps growing!

tonyxiao on 18 Apr 2019

❤6 👍6 🎉5

On OpenCollective I can see that while you get some money, it isn't some impressive amount. I donate monthly a small amount and I'm going to increase it a bit this month, but you are not the only OS project I support this way and I can do only so much. Meanwhile, it's sad to see PRs piling up - what I assume is because you can't afford to work full-time.

So, what can we do apart from donating? Some coordinated action on Twitter, Facebook, other social media? Maybe you could reach out to other projects using TypeOrm as dependency? For example, Nest.js is really successful now - both with adoption rate and on OpenCollective, maybe you could make some mutually beneficial agreement? Also, Nest.js has some nice banner that shows up on install/update that encourages to support it - perhaps you could do the same?

forsetius on 5 May 2019

👍8

My personal opinion on why nest.js got so much attention is because its a good framework for people coming from other platforms and because nest is giving them similar experience they had on other platforms, including typeorm. I know some companies donating to nest who are actually using typeorm as well, but they do not donate to typeorm. And I think they wouldn't use nest without typeorm, and most probably same true versa. We all know that database layer is the most important part in most applications. But companies might only see nest because its a s front-facing product. Nobody looks deeper. Asking nest about support isn't an option since they need money too (who don't need, right?). The only option is to reach those companies somehow and ask them to donate to us too. We need more donations from companies to reach our goal faster. My current goal is to get at least 3k-4k/month (currently its around 1,5k/month) to switch full time to typeorm. My backup plan is to accumulate enough money this year and switch to typeorm for at least 6 months of full time work next year (maybe earlier, just based on my approximate calculations).

pleerock on 5 May 2019

👍26 ❤1

Is there any work going on TypeORM at the moment?
We have 800 opened issues, 100 PRs etc.
It looks abandoned for many people. There was no release for almost 2 months...

murbanowicz on 29 Jul 2019

👍1

They are busy fixing typos. Give them some time

it's dead

On 29 Jul 2019, at 19:58, Marek notifications@github.com wrote:

Is there any work going on TypeORM at the moment?
We have 800 opened issues, 100 PRs etc.
It looks abandoned for many people. There was no release for almost 2 months...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

kaaboaye on 29 Jul 2019

👎5

@pleerock
Can it be temporarily maintained by other members of the community?

zuohuadong on 30 Jul 2019

Pleerock was very clear previously. Donate, like I have and; when the budget increases, he will resume work.

dcworldwide on 31 Jul 2019

This is not how it work usually.
Take a look at Nest. There was just small amount of donations for long time
but Kamil kept doing great job and it paid back.
How company can donate if developers have to spend time creating
workarounds for such a lot of stuff.

śr., 31 lip 2019, 07:20 użytkownik dc notifications@github.com napisał:

Pleerock was very clear previously. Donate, like I have and; when the
budget increases, he will resume work.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/typeorm/typeorm/issues/3267?email_source=notifications&email_token=ACHTJES7H6AWPLZJ4JNP443QCEOLHA5CNFSM4GKXSUAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3GDOQY#issuecomment-516699971,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACHTJEWQ5E5IMRYS7VNLN43QCEOLHANCNFSM4GKXSUAA
.

murbanowicz on 31 Jul 2019

👎3 👍3

Can it be temporarily maintained by other members of the community?

@zuohuadong it already does have, people who have time do it.

Take a look at Nest. There was just small amount of donations for long time
but Kamil kept doing great job and it paid back.

@murbanowicz You are comparing incomparable things.

First, nest has 5 times more in donations and it makes huge sense. Give TypeORM 5 times more donations and I promise to spend no less time than Kamil does.

Second, nest is at least 10 times easier to maintain, because these are two different things - web framework and ORM. TypeORM is kinda 10 times higher in complexity if no more. It requires much more time and efforts for everything here.

Also, I bet most of nest users are nest users because of TypeORM, but not so many people give a credit for that, I guess it's because TypeORM isn't on a surface.

can donate if developers have to spend time creating workarounds for such a lot of stuff.

It's inpropriate position. If your company developers spend too much time on creating workarounds it either means devs do something wrong either you do something specific/complex that requires additional resources for investment. If you don't like to spend your developers time you can invest into tools you use. If you don't like to invest into tools you use - either continue using your developer resources which should be more expensive, either start creating your own tool which should be even more expensive. You already have a good tool that saves you resources, why arent you think it deserves what you saved?

Nobody is going to do lot of free and hard work for people like @kaaboaye, sorry.

pleerock on 1 Aug 2019

👍12 👎9

@pleerock

It already does have, people who have time do it.

Commits on Jul 31, 2019
chore: Update README.md …

betov18x authored and rustamwin committed 22 hours ago

Commits on Jul 24, 2019
docs: update typo in using-ormconfig.md …

fix markdown ？

No version has been released for 2 month.
We have 800 opened issues, 100 PRs etc.
Where is " already people"?

zuohuadong on 1 Aug 2019

@zuohuadong we already had similar discussions already. ORM is quite stable right now and two months without new releases isn't that much. Number of issues don't tell anything, we can have a bot that automatically closes staled issues like many projects have, but we all know it's good for maintainers but bad for issue creators. Number of PRs don't tell anything as well because there are many unfinished prs, some of them need remplementation, some of them need few days if no more to test and completely review. Again, other maintainers do a lot and thanks to them we had last release only two months ago and not ten months ago. Please be respectful to people, they already do a lot and as I said nobody can quite their jobs and start working full time for free for you.

pleerock on 1 Aug 2019

👍9

@pleerock We did try to get donations with the previous project owner, but when we went into the details we got to stuff like #534 or #1601 which are really important (not only them) and we could not convince PO to pay money when we have to keep using workarounds for this kind of stuff.

murbanowicz on 1 Aug 2019

@pleerock have you considered just adding a paid license if someone would like to use TypeORM in a commercial project?

It doesn't need to be 100% bulletproof and I'm sure some people would ignore it and use code without a license. However, if you're a dev working in some company, it would be much easier to ask for a license for a product, which will save you X hours of work, rather than asking for a donation on a product, which already did the job ;)

In many cases, a person who writes the code isn't the one, who earns profits from the written code afterward. OpenCollective is targeting mainly developers, while I think you could get much more stable income by targeting the people, who actually make money on the code you wrote.

Here is an example of such move: https://github.com/handsontable/handsontable/issues/5831

agarbund on 1 Aug 2019

👍5

@pleerock We did try to get donations with the previous project owner, but when we went into the details we got to stuff like #534 or #1601 which are really important (not only them) and we could not convince PO to pay money when we have to keep using workarounds for this kind of stuff.

@murbanowicz You use open source project with a lot of implemented features.
If you try to implement same functionality by yourself, probably, you will spend year, and only then you will be able to add extra features.

@pleerock About complexity, that's true, but i not understand why with so limited resources you try to support every database. Why not select few one until better time.
To be able support every database you need a lot of time, money, full-time developers with specific knowledge of each database.
In same time, when someone from community want help and implement feature he must do it for every database, and finally, when it's done your team must validate that one feature for every database as well, which again require a lot of time or resources.
That's why we see 100+ opened PRs.
Sometimes i think, i can't donate enough money to let TypeORM grow as fast as i want.
In same time i can't implement required features for every database as good as must be.

@agarbund good idea in general. Maybe make free core features and paid DBMS drivers.
But paid product should include support, bug fixes and new features.

GitStorageOne on 1 Aug 2019

@murbanowicz there is a design philosophy behind rejection of #534 or #1601 - first one brings some design issues and problems with other features we have and approach in a second one is implementable in a different way, so its a question of your preference what way to do same thing. I wouldn't too much in detail with those particular issues, its not a good place for this discussion. Both examples I found bad "to have problems and implement workaround for them". Why you wouldn't convince PO to pay money for hundred of other more important and useful features you already have? I could implement those features as well, and some day you could come to me and ask for another feature telling me that you couldn't convince PO to pay money for soft deletion and scoped filters that are already implemented.

@agarbund thanks for suggestion but I would like to avoid going that way. I know there are many startups which wouldn't be able to pay, but I don't want them to prevent doing great job using TypeORM. MIT is simple and simplicity is important for many people. I don't want to get money from people/companies who just started to use TypeORM, I want to get donations from people/companies who got many benefits using TypeORM.

@GitStorageOne databases is just one problem from hundreds. TypeORM is huge on features and each feature brings its own small but annoying complexity, and in total it brings complexity we have. Dropping any feature (including any supported database) will be a step backward and bring even more discontent in community.

pleerock on 1 Aug 2019

@pleerock

In the way you use the adapter, you only need to maintain the core code, and the adapter is maintained by other developers.

zuohuadong on 2 Aug 2019

@udanpe so what to say.. you got it all wrong. It doesn't make sense for me to response to such messages, but you probably should go with sequelize+decorators, I don't understand what you are doing here to be honest.

pleerock on 2 Aug 2019

It seems like we are at a stalemate here. The developer of this library wants money and it honestly doesn't seem like he'll get enough... At least any time soon.

CooCooCaCha on 5 Aug 2019

@CooCooCaCha statement you're looking for was made much earlier https://github.com/typeorm/typeorm/issues/3267#issuecomment-489450860
It's a six months perspective, but at least it is something.

As for general situation: It's not perfect - we've been between versions(0.2, 0.3) for some time, there are lots of open issues/PRs. On the other hand library is pretty stable - yeah it got bugs, but if something which is disturbing shows up someone from the community steps up, make a fix/implement a feature and PR gets merged. It won't be merged right away, but it usually takes 2-4 weeks.
FYI: I'm not looking on July stat's - it's a holidays month so everything might get slower, but everyone need to take some time to cool of(even from OSS).

Someone mentioned separating ORM core code from the specific db drivers code - It is planned, it should make maintaining typeorm much easier. However making such changes requires some(a lot of) work and time, which we currently lack of.

As for suggestion about licensing - we probably could make a pricing model like such: free for noncommercial uses, paid for commercial if your revenue is greater than X per year. It would solve the case of startups, but in general I'm not sure if changing licensing is the way to go.
However there is a good point there - most of the cases it is easier to ask your employer to buy a license then to make a donation.

To sum up - typeorm is not dead, there are no plans to kill it. However currently we are kind of in suspension. No one expected it to go this way, but here we're and we are adapting to circumstances(see the comment mentioned before).

PS: For those who didn't go through many of the discussions here. @pleerock often writes in a way that might be seen as harsh, offensive even, if that is not the intention. I guess this is just one of cultural differences - how straightforward people are, if they go straight to the point in their statements.

Kononnable on 6 Aug 2019

👍6

@Kononnable Thank you for the clarification. I tried not to pass judgement because this is open source and ultimately the developer and the users can do whatever they want.

However, I don't think this situation is good for either party. Donations come from users and suspending development does not inspire confidence.

Honestly this whole situation feels jarring and I can't help but wonder if this could have been handled in a less dramatic way.

CooCooCaCha on 6 Aug 2019

I am regularly donating (modestly) and was under the impression that @pleerock would donate whatever time the total donation sum would allow him to work on this project which is more than fair.
Is this not really the case and the money thing more a binary "if threshold not reached no activity, if reached full-time" situation?

In either case thanks for the great library :-)

consense on 6 Aug 2019

@Kononnable provided good points, thanks. I still plan to spend around 6 months to open source, but once I finish project I'm currently working on. I have a bunch of new ideas to implement in typeorm and open source 🤗

pleerock on 6 Aug 2019

👍24

As for general situation: It's not perfect - we've been between versions(0.2, 0.3) for some time, there are lots of open issues/PRs. On the other hand library is pretty stable - yeah it got bugs, but if something which is disturbing shows up someone from the community steps up, make a fix/implement a feature and PR gets merged. It won't be merged right away, but it usually takes 2-4 weeks.

This in between versions situation doesn't feel like a very good situation; and that situation for issues not the case for all PRs.

The most or second most painful issue in TypeORM that has been affecting me is the issue fixed by your PR #3262. Which you've stepped up to and made a PR, but seems to have been stuck in limbo for a half year specifically because TypeORM is currently in limbo between two releases.

I think TypeORM releases need to be made smaller. Instead of having a roadmap of all the issues desired for a release and not releasing until they are all finished; bugs in the next release should be tracked and when next has some changes for a new release ready for awhile and there aren't any outstanding bugs with those changes, a release should be made asap.

dantman on 28 Aug 2019

👍16 ❤2

I am totally new to TypeORM... where is the next branch ? :kissing_closed_eyes: If I'm not wrong, the master branch is the current 2.x ?

LoicMahieu on 26 Sep 2019

👎1

There is no future for the library if you can't pay an attention to it regularly.

I do understand why you need donations and it is totally ok, but I don't understand, why you are waiting for such a long time to work for it fulltime. For others it looks like a dead library with tons of issues and no commit activity. If you will spend an hour per week, you can close a bunch of PR and issues and it is better than a half-year wait.

silentroach on 30 Sep 2019

👍5 👎1

@silentroach you can call it "tons of issues", but I won't call it so. Maybe there are some missing features for some people, maybe there are small bugs in some functionality used by some people. That's fine if you keep in mind how many features ORM has. Any software has bugs or missing for some people features. There are no serious, big or blocking issues, and 90% of functionality is in place and working fine which is acceptable for most projects and use cases.

About your definition of a dead library. If you don't see a commit activity it doesn't mean you can't use it and be productive with it in your projects. Yes, it can mean you won't get some features you want or somebody might not fix the bug that you faced for you, but again, you can face same issues or different kind of issues in any other open source project. Any library you'll use will have something that you miss, or it won't follow your philosophy, or it will be less maintained by the time, etc. It's up to you to decide set of cons and pros of each solution and choose what works best for you.

Regarding to your comment on spending an hour per week. Well, its easy for you to say "go and spend an hour per week to fix all our issues". Actually an hour isn't enough to review weekly PRs, merge and test them if needed. But it's not a case, few hours or half of the working day might be okay. And I basically try to do it, maybe not every week, but maybe once in a few weeks. I released latest version two weeks ago. I don't merge every PR, but do it only with changes that I'm okay with, because if I merge something that can potentially break things, it will be much worse. Its much better to have product in a current stability, rather than merge doubt functionality or fix and then again wait for weeks to fix it back (keeping in mind how much time I have). I'm using TypeORM in many my projects and I'm super satisfied with its stability. Most of the times actually, people are misusing some functionality or simply don't use it the right way. Its not possible for me to answer everybody, understand their use case and propose a better solutions for their problems.

pleerock on 1 Oct 2019

👍9 👎1

I just want to be able to fix bugs I found by myself. And when I get no reaction to my PR for 2 weeks - it looks dead to me as contributor.

silentroach on 1 Oct 2019

👍11

Typeorm is for example messing up associations by creating new copies of entry instead of modifying it.

I have reported this long time ago and still I didn’t get any response. No one even looked at this report so how can you tell that their are no serious bugs if no one is even looking at the reports?

My report: https://github.com/typeorm/typeorm/issues/2689

On 1 Oct 2019, at 08:52, Umed Khudoiberdiev notifications@github.com wrote:

@silentroach you can call it "tons of issues", but I won't call it so. Maybe there are some missing features for some people, maybe there are small bugs in some functionality used by some people. That's fine if you keep in mind how many features ORM has. Any software has bugs or missing for some people features. There are no serious, big or blocking issues, and 90% of functionality is in place and working fine which is acceptable for most projects and use cases.

About your definition of a dead library. If you don't see a commit activity it doesn't mean you can't use it and be productive with it in your projects. Yes, it can mean you won't get some features you want or somebody might not fix the bug that you faced for you, but again, you can face same issues or different kind of issues in any other open source project. Any library you'll use will have something that you miss, or it won't follow your philosophy, or it will be less maintained by the time, etc. It's up to you to decide set of cons and pros of each solution and choose what works best for you.

Regarding to your comment on spending an hour per week. Well, its easy for you to say "go and spend an hour per week to fix all our issues". Actually an hour isn't enough to review weekly PRs, merge and test them if needed. But it's not a case, few hours or half of the working day might be okay. And I basically try to do it, maybe not every week, but maybe once in a few weeks. I released latest version two weeks ago. I don't merge every PR, but do it only with changes that I'm okay with, because if I merge something that can potentially break things, it will be much worse. Its much better to have product in a current stability, rather than merge doubt functionality or fix and then again wait for weeks to fix it back (keeping in mind how much time I have). I'm using TypeORM in many my projects and I'm super satisfied with its stability. Most of the times actually, people are misusing some functionality or simply don't use it the right way. Its not possible for me to answer everybody, understand their use case and propose a better solutions for their problems.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

kaaboaye on 1 Oct 2019

Or global filters which are definitely not 'some feature used by small group of people'

murbanowicz on 1 Oct 2019

@silentroach its up to you. 2 weeks is simply nothing if you are really interested in. Checkout typescript repository for example, people are waiting for years to get features they need. And Im one of them - Im not stopping being a typescript user no matter how much I need this feature, I'm having to leave without them or implement temporary solutions. And sometimes they arrive in a few years, sometimes in a few months.

Or global filters which are definitely not 'some feature used by small group of people'

@murbanowicz when one library gets every single feature from every single person it becomes unmaintainable mess. If you are interested in extended functionality like what you want - consider creating an extension.

I have reported this long time ago and still I didn’t get any response. No one even looked at this report so how can you tell that their are no serious bugs if no one is even looking at the reports?

@kaaboaye I reviewed your issue, and looks like as usual its not a bug, but as usual an issue in code because of incorrect usage.

pleerock on 1 Oct 2019

👍6

@pleerock I don't agree. Global filters is pretty fundamental feature for the modern ORM, it is not some edge case used by few people.

murbanowicz on 1 Oct 2019

👍4

Ok, so I usually don't contribute to conversations like this but I'm kind of stumped by all the negativity in this thread and I feel like I need to step in on behalf @pleerock and the other contributors and offer my own viewpoint.

First of all, typeorm is amazing. I've been working with it for about a year now and so far I haven't found a single issue with it that couldn't be fixed by digging through the documentation or writing slightly more verbose code (e.g. using QueryBuilder). Certainly none I would consider a show stopper or even a significant annoyance. Sure, TypeORM doesn't have all the features that everybody may need ever but keep in mind that ORMs are very complex beasts and every feature added adds to this complexity.

I think part of the problem here is that some people expect ORMs to be this magical tool that handles every single edge case for them without them ever having to worry about the architecture of the underlying database. News-flash: that's never gonna happen. The truth is, the more you rely on the abstractions offered by "full featured" ORMs the more likely you are to shoot yourself in the foot.

Also, I think it's silly to think that just because a project hasn't received a ton of attention in a while means it's dead. There hasn't been a release in a while? Maybe that means it's stable. It has a ton of open issues and PRs? Maybe that means its hugely popular. As for all the open issues, a lot of those are simply people asking questions that could easily have been answered by digging through the documentation...

To sum up - TypeORM is stable, fast and does pretty much everything you could reasonably expect from an ORM being developed for free buy a bunch of people in their free time. It's hands down the best ORM for typescript out there period and if you don't agree, well, nobody is forcing you to use it and you have no right whatsoever to expect that the maintainers implement $YOUR_FAVORITE_FEATURE just because you keep trolling them.

To @pleerock, @Kononnable and all the other maintainers. You rock. Thanks for this amazing project and keep up the good work!

MaKleSoft on 1 Oct 2019

👍37 ❤7 🎉6 🚀4 😄3 👎3

@MaKleSoft $MY_FAVORITE_FEATURE is a fix, I made it for free in my free time for a bug I found and reported by myself.

TypeORM is great and I want to make it even better and more stable, of course I expect some attention to my PR, like other contributors.

silentroach on 1 Oct 2019

❤10 👍5

@silentroach I get that not getting attention on your PR can be frustrating but you have to understand that reviewing and merging PRs is time-consuming work, too (sometimes more so than just writing the fix yourself). Your willingness to contribute is applaudable but keep in mind that this is not your project and even if you invest time creating a PR that doesn't mean that the maintainers are obligated to consider it. Certainly you have have no right to attack anyone just because you haven't received an answer within as little as two weeks.

MaKleSoft on 1 Oct 2019

👍2

@MaKleSoft you right. Sorry @pleerock and best luck with contributors.

silentroach on 1 Oct 2019

I think fullpage license is better, free to free. https://github.com/alvarotrigo/fullPage.js#license

License
Commercial license

If you want to use fullPage to develop non open sourced sites, themes, projects, and applications, the Commercial license is the appropriate license. With this option, your source code is kept proprietary. Which means, you won't have to change your whole application source code to an open source license. [Purchase a Fullpage Commercial License]

Open source license

If you are creating an open source application under a license compatible with the GNU GPL license v3, you may use fullPage under the terms of the GPLv3.

The credit comments in the JavaScript and CSS files should be kept intact (even after combination or minification)

Read more about fullPage's license.

shynome on 6 Oct 2019

😕2

Fantastic project and great idea setting up contributions / sponsorships. Just clicked the button myself.

I just wanted to float an additional thought in this thread. What about specific bounties, such that folks could "create" more time for certain issues to get attention and get merged in? Bounties could (at a minimum) require a sponsor from the core team, since they would have to dedicated time to merge the pull requests, etc. They would more than likely also be the ones fixing the issues / making the improvements. Anyone could create these bounties, but having the list groomed / endorsed by the core team could keep things flowing with the roadmap.

This obviously doesn't replace the need for more consistent sponsorship, but it could be a valuable ancillary method to support improvements through pooling some more directed resources of the community together. Folks get the "attention" they are looking for on specific issues and the developers get the resources they need to give them that attention.

Just a thought. There's always a battle for priority and getting the resources necessary to address various items. Having a good pipeline of these could offer some additional predictability in compensation for the project devs, while also giving the community some more collective voting (by dollar) power.

Thanks again for all the hard work!

arimus on 11 Oct 2019

First of all @pleerock you have done a great job! There is nothing else you could have done better by yourself and a handful of core contributors.

Regarding your original post which started it all, I want to say is that open source has nothing to do with whether or not something is free. For what is worth, in my opinion, the main two reasons for sharing code is to encourage collaboration and to help others learn. Two very noble causes that should be supported and sustained for the sake of the open source movement. This tool is not free... you paid for it. In addition, early users took risks and also helped you via testing/bug reports. So you got help too and learned in the process.

And I agree with @MaKleSoft the project is very popular and stable. But like I said, some on-going work/energy still needs to be put into this project. Even if its triaging and closing down issues for the sake of "reputation" (note the quotes). There is value in going through all of those issues and responding. It is a learning opportunity for the reviewer and the reporter. It's also an opportunity to surface good ideas and apply them at scale. It maintains the reputation of the tool, which in turn is a win-win for everyone.

Frustrating collaborators such as @silentroach or anyone else who attempts to follow the spirit of open source is counter-productive to the movement, it gives the movement a bad reputation.

And so... if you want to follow the real open source spirit, then open up control to the project and delegate. Let others continue to carry on your great work and contributions.

The alternative, which is what I would do personally, is find a way to recover your investment. You paid for this after all. Donations are not enough. I am happy to give you commercialization ideas or to purchase control rights 😈 (kidding).

However, leaving things up in the "limbo" (again it is a mere issue of reputation of the tool and open-source) is a lose-lose for everyone.

ricardojr on 16 Nov 2019

👍7

My recommendation is to prioritize official support for fewer databases (Postgres, MySQL, and maybe Mongo). I suspect this encompasses the vast majority of users.

Ideally, the rest could be supported by their communities with extensions (blocked by https://github.com/typeorm/typeorm/issues/2479), particularly since many are for-profit.

jcrben on 20 Nov 2019

👍29

@pleerock I'm willing to help with issues/pull request labelling, closing duplicates, reproducing etc. as triage

Ginden on 21 Nov 2019

❤2

Ideally, the rest could be supported by their communities with extensions (blocked by #2479), particularly since many are for-profit.

This makes more sense. These three databases (MySQL/MariaDB, Postgres and Mongo) are probably enough for most of the typescript developers. SQL Server has Microsoft on the back and most of the their users will use .NET to develop. Same as Oracle for JAVA.

I don't think TypeORM should support so many databases, you guys can leave the small databases to community to support and focusing on the most popular databases, to make them solid and of course, save tons of time (Money) on supporting them.

Thing is like two ways, if it's hard to find money, then just simplify it and save money.

chengjia080787 on 10 Dec 2019

👍29 👎2

We're considering using this ORM in the company that I work at.

I just have some general questions, hoping to get some answers :D

Is this project still actively maintained?
If we contribute to the project, both in time and money, would we have a greater say in the direction of the ORM?

endurance on 13 Dec 2019

👍19

@endurance hello im not with the team but I hope @pleerock will think this over. This is the best ORM for node so far. Dont want to lose this project. please sir pleerock hope you consider

artoodeeto on 17 Dec 2019

👍9

TypeORM is the best TypeScript so far. I'm really sad about the situation of the project.
Relying on individual donors is usually not enough for a good ORM. I suggest, maybe we can look for some company support or led TypeORM. Most successful open source projects is rely on company support.
Just an immature suggestion😅.

whlsxl on 28 Jan 2020

👍9

There is no future for the library if you can't pay an attention to it regularly.

I do understand why you need donations and it is totally ok, but I don't understand, why you are waiting for such a long time to work for it fulltime. For others it looks like a dead library with tons of issues and no commit activity. If you will spend an hour per week, you can close a bunch of PR and issues and it is better than a half-year wait.

You don't understand why he's waiting for such a long time to work for it fulltime? Really? Do you think his bank/landlord will take a "I'm working on my open source project" as payment for rent or mortgage? Do you think he can walk into a grocery store and pick things off the shelf and declare "well I'm working on an open source project"?

If he spent an hour a week he will NOT close a bunch of PR issues. Any seasoned developer will tell you that's a comical statement. If you can close "a bunch of PR issues" working just an hour a week, I will hire you for 2 hours a week.

For the record I'm using TypeORM, there are some limitations/bugs but I have my own workarounds, and regardless, I am GREATLY appreciative of all the work they've put into it. When we can raise some investment I will 110% donate.

hchor on 12 Feb 2020

❤6 👎2 👍2

@hchor the difference between you and me is that I was both donator and contributor and you are not 🤷‍♂️ I really appreciate authors work, but open-source projects need everyday attention.

Now I'm not using TypeORM any more.

silentroach on 12 Feb 2020

👍3

@hchor the difference between you and me is that I was both donator and contributor and you are not 🤷‍♂️ I really appreciate authors work, but open-source projects need everyday attention.

Now I'm not using TypeORM any more.

Firstly, thanks for your contributions. But that still doesn't negate the fact that the author can't pay their bills with an open source project where he doesn't get paid, and thus when you asked why he can't work full-time.... well, there's your answer. Nevertheless, thanks and let's not derail this thread. If you have any real solid alternatives, please send me a private message, I would greatly appreciate it.

hchor on 12 Feb 2020

😕2 👎2 👍1

@hchor I never asked him to work full-time, just asked for attention on PRs with bugfixes

silentroach on 12 Feb 2020

👍8

@hchor I never asked him to work full-time, just asked for attention on PRs with bugfixes

typeorm is no longer actively updated, we can create a lightweight typeorm together.

The code will be separated into core and adapter parts.
The core implements functions and operations.
The adapter is used to adapt to various databases.
We just need to maintain the core and leave the adapter to other developers.

zuohuadong on 26 Feb 2020

Soft delete was added to typeorm yesterday. It sounds like work is still
being done?

endurance on 26 Feb 2020

👍1

Any opinions about Prisma 2 or https://github.com/mikro-orm/mikro-orm ?

ttsirkia on 27 Feb 2020

👍5 😕1

Any opinions about Prisma 2 or https://github.com/mikro-orm/mikro-orm ?

mikro-orm +1

zuohuadong on 28 Feb 2020

👍3

Any opinions about Prisma 2 or https://github.com/mikro-orm/mikro-orm ?

mikro-orm +1

fyi, mikro-orm creates proper relationships via ObjectId array references in Mongo compared to TypeORM (which in contrast embeds related objects)

desmap on 16 Mar 2020

👍1

@pleerock Have you guys considered to partner up and work with the Ionic company?
Afaik, Ionic is already developing cross-platform solutions based on SQLite, but they do not yet offer any ORM. The ORM part is the missing piece that you could provide.
With Ionic, you would not need to support such a huge variety of databases. Instead, it would be sufficient to support SQLite + something that works in the browser.
Also, Ionic is financially backed such that they could pay you a reasonable income.

fkirc on 22 Mar 2020

👍1

@pleerock , My 2 cents,
I can understand your frustration and you are free to do whatever you want.
However, I believe that a warning on the main readme documentation would be welcome.
There's no point in letting people go into typeorm knowing that it will often end in unnecessary frustration and ranting.
Of course, typeorm is not necessarily unusable, however, one would appreciate to know that if he is using typeorm he is mostly on his own if something is wrong or not properly documented.

Now for the funding: besides the fact that the Nodejs driver/orm/querybuilder landscape is crowdy and fragmented and that it is always difficult to get a meaningful support for a single project, you will have a hard time to get support without a readable strategy.
What if people donate and in the end it's not enough? Not only they would have given for nothing but mostly would have lost time invested in a dead end project.

FredericLatour on 24 Mar 2020

👍6

Actually TypeORM suffer of a lack of basics features/fixes which are really needed to become, IMO, a true professional tool.

Another thing which is confusing is the amount of opened tickets, i know it requires times, but the current triage seem a bit foresaken which don't give a good view of what's done exactly.

When i talk about TypeORM the first feedbacks i'got are:

Too much opened/unresolved tickets
Many are still opened after years
A lack of basic features

So yeah, TypeORM is really cool, you made a really good job on it, but maybe you should consider open a bit more contributors chairs to help you to maintain the repository, then you'll be able to focus on the most important part, the code ;)

Maybe you can also consider to ask for TypeORM exposure on NestJS readme/websites, i don't see why they would refuse to give a hand ;)

antoine-pous on 10 Apr 2020

👍7

Hello everyone, I think in situations like these we need to address our own needs.

I want to gauge your interest for pooling money together and create a well-maintained fork of TypeORM.

Please see the basic proposal here: https://docs.google.com/document/d/1KXTPvJhaqcV_TIuanEjww1FG2tLqiijm9TPqliLzgRE

Interested Contributors So Far

@artoodeeto
@iWinston ? (waiting for response, nominated)
@pleerock ? (waiting for response, nominated)

Next Steps

Get to 6 core contributor with equal decision making power
Video Meetup to learn more about each other, especially our vision of the future
Video Meetup to decide on 2020 roadmap and decision making process
Fork!

ricardojr on 10 Apr 2020

👍10

@ricardojr hey I'm down and I'm willing to help maintain your forked typeorm. I think @iWinston is using this at their job maybe we can use his forked too or he could be a team lead since he knows the package. My issue with this is that they don't address the current issue first instead they keep adding features which I know it's cool and it helps but I think they should address the current problem then slowly work on a feature.

artoodeeto on 11 Apr 2020

👍3

I know its hard to understand when you aren't dealing with it, but I'll just provide a one small example. Today I wanted to review and merge few PRs. This is how it started:

I wanted to review and merge this small documentation PR (#5862).
I looked few times, looked okay.
Then I asked myself - "hmm wait, aren't we support this functionality? - because from what I remember we had this feature request I and think we had a PR for it?".
I started to search in a codebase for tests and didn't find anything.
Then I decided to write test case since this functionality isn't covered.
From tests I understood functionality isn't supported.
I was surprised and started to search for github issues and I found that my initial assumption was wrong - we didn't implement this feature, and it was just a discussion over it.
I decided to implement requested feature since its easy fix and all investigation and test coverage was already made. It was just a few lines of code change.
I also faced issue #3125 during search and provided answer to people misunderstanding on related issue
I ended up coming here and write this post and it took another 30 minutes.

Overall it took almost 6 hours and everything started from a small documentation PR which I couldn't merge without doing most of this job. While actual fix without writing tests took only two (!) minutes. Now imagine how much time its needed to close remaining 160 this time non-trivial PRs, to close 1500 issues? Now include new PRs and issues coming all the time. Now include new features. Now include developers motivation when people claiming and judging all the time (there are different levels of developers, there can be a young man with one or two years of experience and he thinks we MUST do everything for him, otherwise its a "shame for us", we can see haters everywhere).

Communication takes most of development time. Understanding people's problem, code review, discussion take too much time. I think TypeORM is quite stable and it doesn't make sense to bring to the documentation point that you won't get your answer in issues from the maintainers. Yes you might won't get it, but there is a chance somebody else can answer you or you can get help on SO. At the end you can ask for commercial help which is always an available option. Regarding to bugs - yes, there can be bugs like in any software. Some bugs come with so many features we have to maintain. And when we merge a PR of one, we can break something else. Yes, there are ton of improvements we can do. But anyway imo TypeORM is stable and I'm sure most of "opened issues" you are talking about are just some misunderstanding (it's in people psychology to think "its their issue, not mine") and since you don't get an answer you are sure its a bug. But in most cases its not - #3125 is good example I closed just now. At the same time every issue participant was sure its a bug, unfortunately.

You think it's easy to ask companies to donate / pay you? No, it's not. I had a discussion with nestjs and they told they need money themself to support their project. It's completely understandable since they are small too. If you want bigger companies (like ionic mentioned, or even your company) to help this project, YOU must ask them. Because only YOU can affect them to do it, because they don't care about tools people use, but they do care about YOU and many others asking. Companies usually only think about profit, what's the point for them to spend money on something that they can use without spending the money? Unfortunately this is how 99% companies work, they simply don't spend money until you suggest them something that they need and something they can't get for free. Most of current and previous donators are companies whom I provided a personal help.

You think it's easy to maintain your own fork. Yes, it might be not hard to maintain your own fork with only changes you need. But it's super hard to maintain a fork with all changes people request / issues they have. People tell to use mikro-orm or something else instead, but what's the point to write about it here? I guess because they know its immature yet or missing features they need. And I know that any other orm is going to have same fate (or most probably worse) once it get mature, full featured and popular. I'll say more - this is a fate of most open source projects. I see so many amazing projects get abandoned (I'm sure you do too), tools that are great in solving problems they solve and had a great start at the beginning. And this is our responsibility, nothing comes for free, and when we have it for free - we don't care. Companies don't care. Most people only claim for features they need and judge if it's missing without understanding the reason in deep. Others just don't care until they have a problem. I strongly believe we need to change this culture to help open source not to die every time.

pleerock on 13 Apr 2020

👍18 ❤4 👎1

@pleerock I agree to everything you just said 100% 👍🏽 It is not easy, which is why I am simply proposing

Find 10 core developers who share your own vision and give them decision making power, which includes the ability to close down issues that don't fit the roadmap.
Reduce your time to simply managing those developers, making sure they are still adhering to the vision. It does not mean looking at their PRs, but simply checking on them every month, for 1 hour.

Bonus:

Get this project off Github and find a repo provider that allows you to charge at least $2/month/developer. Companies/Freelancers don't want free things... companies/freelancers want things that get the job done at a cost-effective price point, without risking embarrassment in front of investors/customers/CEOs. Free has nothing to do with it. Anyone who complaints about a mere $2/month/developer fee is a hypocrite. I currently donate to nest.js.
Limit access to Slack and only allow subscribers to access it.

ricardo-journey on 13 Apr 2020

👍2

I would actually go in the opposite direction:
Instead of maintaining the current library, I would make a radical feature cut-down to focus only on cross-platform frontend apps (browser, iOS, Android, Electron). For those platforms, SQLite and sqljs are probably the only databases that you need.

I see the following reasons for focusing on cross-platform frontend apps:

The competition in the cross-platform space is scarce. There are hardly any ORMs that work well for cross-platform apps.
In contrast, there is a sharp competition in the Node.js space.
For things like Microsoft SQL Server, I guess that most devs do not even remotely consider to use TypeORM, let alone TypeScript.

fkirc on 14 Apr 2020

👎9

@pleerock I agree with you sir. But @ricardo-journey may have a somewhat solution, take core devs. assign them with issues, maybe some will review, some will answer questions, or like that. I know dev.to does this. Also, I would be happy to contribute. $10 a month, I will even cancel my disney+ subscription.

artoodeeto on 14 Apr 2020

😄1

For those platforms, SQLite and sqljs are probably the only databases that you need.

@fkirc are you suggesting that ongoing support for MySQL, Postgres, and SQL Server (or even Oracle, as much as everyone hates it) be halted? or that those drivers should be removed entirely? i hope not, because that would be a serious miscalculation of how relevant and prevalent each of those systems are, and will continue to be for many years.

For things like Microsoft SQL Server, I guess that most devs do not even remotely consider to use TypeORM, let alone TypeScript.

this is not a good guess. as much as i want to give you the benefit the doubt, it sounds like you only have experience working on brand new projects where you have total architectural autonomy, from data layer to code.

think about how many companies there are in the world that have existed longer than the last 5-10 years. the better among them (the ones making smart technology decisions and eng hires in 2020) are trying to evolve and adopt newer technologies like TypeScript and TypeORM at the application level, but there's very little chance any of them are also trying to migrate their data layers from MySQL/Postgres/SQL Server to something like SQLite. it might be the right tool for the job in _some_ cases, but i don't see these other DB systems going away or becoming less relevant any time soon -- they're still highly performant, evolving, and very saturated.

my sincere apologies if i'm misunderstanding what you're suggesting, but as written, it sounds very misguided.

feather-jmalone on 14 Apr 2020

For those platforms, SQLite and sqljs are probably the only databases that you need.

@fkirc are you suggesting that ongoing support for MySQL, Postgres, and SQL Server (or even Oracle, as much as everyone hates it) be halted? or that those drivers should be removed entirely? i hope not, because that would be a serious miscalculation of how relevant and prevalent each of those systems are, and will continue to be for many years.

Yes, this was a suggestion as an attempt to reduce the maintenance costs of TypeORM.

For things like Microsoft SQL Server, I guess that most devs do not even remotely consider to use TypeORM, let alone TypeScript.

think about how many companies there are in the world that have existed longer than the last 5-10 years. the better among them (the ones making smart technology decisions and eng hires in 2020) are trying to evolve and adopt newer technologies like TypeScript and TypeORM at the application level, but there's very little chance any of them are also trying to migrate their data layers from MySQL/Postgres/SQL Server to something like SQLite. it might be the right tool for the job in _some_ cases, but i don't see these other DB systems going away or becoming less relevant any time soon -- they're still highly performant, evolving, and very saturated.

Now we have to distinguish between frontend and backend.
If an "old" company adopts TypeScript for the frontend, then SQLite/sqljs should be fine.
In contrast, if a company slaps Node.js onto an existing backend database, then they would need drivers like MySQL/Postgres/SQL Server.
But my overall argument is that TypeScript is much more prevalent in the frontend.

fkirc on 14 Apr 2020

👎4

But my overall argument is that TypeScript is much more prevalent in the frontend.

Typescript works everywhere. No differentiation on frontend and backend.
There is absolutely no problems to move even old projects to TS, step by step, file by file with backward compatibility.

GitStorageOne on 14 Apr 2020

👍2

But my overall argument is that TypeScript is much more prevalent in the frontend.

Typescript works everywhere. No differentiation on frontend and backend.

While TypeScript works everywhere, the databases do not.
In fact, there exists a differentiation between frontend and backend databases.
In the frontend, SQLite and sqljs should be sufficient for most users.
In contrast, databases like Postgres/MySQL/Oracle are more likely to be found in the backend.

Now my argument is that TypeORM should specialize in one domain (frontend) instead of trying to fit each and every use case. Reasons for this are competition and market distribution.
Note that with "frontend" I do not only mean the browser, but cross-platform apps for browser/Android/iOS/Electron.

There is absolutely no problems to move even old projects to TS, step by step, file by file with backward compatibility.

Yes, but who does that in the backend? Most likely Node.js projects, unless you refer to a complete rewrite of a backend service.
As already outlined, there is a sharp competition for databases/ORMs in the Node.js market.
Therefore, I believe that TypeORM would be better if it focused solely on cross-platform apps instead of backend services.

fkirc on 14 Apr 2020

👎8

Instead of removing drivers support, each drivers must be implemented as plugin and TypeORM should simply be an abstract lib.

Then it will allow to reduce issues for most used drivers painless. Actually TypeORM use mainly it's repository to expose examples, but it can be improved by using one repo per plugin, where one plugin represent exclusively one driver support.

So instead of installing a big amount of drivers/test suites we'll install only the required stuff and reduce drastically side effects. Another thing which can be cool is allow donators to simply tell which plugin should be focused in priority, maybe simply allow them to upvote 3 of them in the full list.

By splitting correctly everything it will be simplier to maintain TypeORM and all it's components, no need to focus SQLite for falsy reasons :)

antoine-pous on 14 Apr 2020

👍4

Let's prevent a discussion of what should be removed and what not. One can say remove mssql support, second would say remove everything except electron support, third would say remove decorators support, another would say something else. I would say drivers aren't problematic at all, let's remove automatic schema synchronization and cascade persistence and simplify query builder - most problematic and hard to change parts of the codebase. TypeORM is used by thousands developers and every one has its own use case and his own opinion of what he needs and what he doesn't need. If you remove one thing, even smallest one, you would definitely harm somebody. And of course I would get wave of hate. This question is delicate and its not a proper place for this discussion.

pleerock on 14 Apr 2020

❤4 👍1

What about this approach ?

Someone or some company wants some bug to be fixed or some feature to be added:
=> this one or the company accepts to participate for some amount.
=> Some one else also accepts to add some amount for the same feature.
=> etc ...

At some point, a developer in the community accepts to handle the fix or feature for the total amount of money that was allocated to this issue. A percent of the amount goes to the maintainers anyway.

Some rules (of course more rules would certainly rise):

At anytime if the issue is not being handled, one can cancel it's payment.
If someone accepts to handle an issue, he'll get the payment once the issue is being fixed and validated.

The tooling needs to be developed around this approach but I believe this could work.

FredericLatour on 14 Apr 2020

What you guys suggest makes sense and this how many of us can imagine it could work in theory, including me. In practice, however, situation isn't ideal and we already know it from our own experience. Number of factors should match to make proposed solutions to work in practice.

First of all - new core contributors. I already provided you an example of how much time it took me to review one issue. Now imagine how much time it will take for others considering they know codebase (and millions of underlying stones) less than me. We already had many core contributors in past years - people start to work and maintain when they have a time (they are in vacation for example), then once their vacation is over (or they have too much work in their company), they understand that they can't keep spending so much time on this, knowing that its impossible to have a visible progress without making it full or at least a half time. But who can afford themself to work full or half time these days? Students? Yes, but this tool requires an experienced skill set and usually students disappear in a while. Can you afford to do it? Well, even if you think yes, even if you start to do it, its more likely you'll face same problems as previous people.

So, situations when you tell, hey just take 10 contributors, let them work, and just review things once in a month isn't possible. You simply can't find people who are going to work in a long-term for free (or for a small amount of money that people currently donate). Also, contributors exist when they work with technology their current job position provide. And today people are working on one technology stack, tomorrow they can work on a different stack. And they don't have a reason / motivation to keep maintaining this thing.

Situation when you have money depends on how much money you have. Shop can't open and close its business whenever customer would like to buy products from there. Same story here - people (contributors) need to work full time, have a stable income and justify the time they are spending with lot of investigations, hard work and support they do. Every issue they are going to fix is a process where they need to: understand the problem, investigate code to find a solution, code solution, test it, fix all related problems, provide a test coverage, update documentation, communicate related issues and consequences with community. We all are developers, and we all know how hard our work is and how slowly things move when we don't spend the whole days or nights programming one small feature or trying to fix one annoying bug that you can't figure out for a days. To take it serious we need a stable income and team of developers working full time on this product.

I can easily build a team of developers who can maintain and improve TypeORM and lead it to the bright future. We will build a roadmap, close most of issues we have and start to ship a new features. But nobody I know is going to join me in this hard work for free. I can guarantee I'll be able to do it if TypeORM will have $10k donations per month. TypeORM is used by thousands developers, hundred of people have seen current issue, 200 of them added 👍. If everybody (200 people) could donate 25$ monthly (I know its a lot for many people, but let's just imagine) - it could promise a stable income and I can start to hire people. But looks like this crowdfunding strategy is a " 🦄" too.

Another solution I see is to have a few companies that can donate significant amount of money (or wait until one of many startups here could rise money and donate to this project). I always provide support to donator companies. Here, you can help too if you ask your company for donations. Company would have a better tooling, happier developers and my support. Also, company saves money on developer time when they have this kind of support and developers don't need to spend much more time in toolset issues fixing.

pleerock on 14 Apr 2020

👍12 👀1 🚀1

I can guarantee I'll be able to do it if TypeORM will have $10k donations per month
@pleerock Great! Do you need help setting it up?

In this world, there will be employers who will offer you $50K/year, others $200K/year, others $400k/year. Each job would have pros/cons, but if any of these align to what you want to do, I guess you would take the $400k/year and ignore the other offers.

There will also be users of this tool willing to pay $0/month, others $X/month. It seems you have rightfully concluded that the only pricing model that aligns to what you want to do, is the $X/month. You should then make the decision to ignore the option that doesn't get you closer to your goal.

I think the open-source strategy has helped this community get here. Now it is time for a commercial fork to co-exist with a community fork. I don't think that goes against anything and there is nothing to lose trying.

Happy to help you manage the commercial fork. 👍🏽Just reach out. All you would have to do is put a notice on the ReadMe, point to the new repo, and assign a few managers. And there you go! A startup is born.

As opposed to MANY of your users, your startup actually has a proven product and proven market demand.

ricardo-journey on 15 Apr 2020

I will donate $25 monthly to see this project shine.

On Tue, Apr 14, 2020 at 5:26 PM Ricardo Rodriguez notifications@github.com
wrote:

I can guarantee I'll be able to do it if TypeORM will have $10k donations
per month
@pleerock https://github.com/pleerock Great! Do you need help setting
it up?

In this world, there will be employers who will offer you $50K/year,
others $200K/year, others $400k/year. Each job would have pros/cons, but if
any of these align to what you want to do, I guess you would take the
$400k/year and ignore the other offers.

There will also be users of this tool willing to pay $0/month, others
$X/month. It seems you have rightfully concluded that the only pricing
model that aligns to what you want to do, is the $X/month. You should
then make the decision to ignore the option that doesn't get you closer
to your goal.

I think the open-source strategy has helped this community get here. Now
it is time for a commercial fork to co-exist with a community fork. I don't
think that goes against anything and there is nothing to lose trying.

Happy to help you manage the commercial fork. 👍🏽Just reach out. All you
would have to do is put a notice on the ReadMe, point to the new repo, and
assign a few managers. And there you go! A startup is born.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/typeorm/typeorm/issues/3267#issuecomment-613711457,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGU7I2IG6GDPAPPOEHRQ3TRMTPIJANCNFSM4GKXSUAA
.

endurance on 15 Apr 2020

👍13 🚀1 ❤1

don't want to speculate an amount prematurely, but i can confidently say that my organization is willing to contribute some number monthly for as long as we're using TypeORM. what is the current preferred channel for contributions?

edit: especially now that GitHub just dropped their prices considerably :)

feather-jmalone on 15 Apr 2020

I think 10k is very doable. I will also contribute as much as I can! This is an awesome ORM that I have been using for a bit for my startup and I would hate to see it go to waste.

smblee on 15 Apr 2020

❤7

I'll see when my company is up how much we can donate to help :)

antoine-pous on 18 Apr 2020

Just to pitch in, pro @pleerock and anti some haters.

TypeORM works great for my uses. Yes, it does miss some features. But I build capable applications with it and nestjs. No, they aren't commercial otherwise I'd get my company to pay.

It's stable, it works and there's decent support.

acepace on 21 Apr 2020

@acepace Your comment is completely useless. Your usage is certainly extremely basic.

As soon as I tried to use typeorm I faced two problems:

I had to dig hard to discover that @CreateDateColumn and @UpdateDateColumn were relying on Mysql default field value to be set to CURRENT_TIMESTAMP to get their initial values but on the other hand was not relying on MySql ON UPDATE default value to update @UpdateDateColumn value.
Not only I'm not sure this is a sensible choice but the documentation is completely unhelpful (it says that it deals with those columns but it's not mentioned that it only works if the schema was generated from scratch or if you update your database definition) and of course you can't get any answer and are on your own to find out.
I also just got bitten by BeforeInsert that is not always firing (typeorm/typeorm#5493).
the documentation is very lacking overall and there is no way to ask for clarification.
As far as I can see there are many other problems unanswered or unresolved ...

That said I'm not blaming @pleerock. He is free to do whatever he wants. I can understand his frustration. However, I would like to make two comments:

At the very least, it would be fair to warn on the first page that the development is in pause and that one can not necessarily expect any answer to any question. The software is not unusable, far from it, but take it or leave it as it is....
When someone starts an open source project, he does not necessarily expect making a living from this project. This is obviously always a possible opportunity, a bet, but not one is to blame if it does not work.
If the project becomes a "kind of" reference then there is a possibility that it get sponsored in a meaningful way. However, let's face it, even though Typeorm is a nice piece of software, it lives in a crowdy ecosystem:
mysql
mysql2
mariadb-connector
knex
sequlize (sequelize typescript)
objection
loopback
bookshelf
featherjs
prisma
typeorm
mikro-orm

Many people are using it because it comes with some specific support by their framework of choice. Being written in typescript, it often comes as the de facto choice for those frameworks written using typescript. That said, many people are using it for such basic CRUD needs that they could use basically anything. That's certainly why so many people are using it in comparison to people donating. For many people, it's not core business at all. They could replace it by raw sql queries or knex for multi db compatibiltiy.

If you were expecting to be successful with an open source project up to the point where you could make a living from donation and if it does not work, I'm not sure it makes any sense to make others feel guilty because they are using a software that you were certainly initially enjoying each additional download.
If the open source path is unsuccessful and still you want to try making a living from your work, you can always take a different path (meaning commercial - though I'm not really convinced it would work).

Open source can be quite frustrating I have to admit however if a framework/library was not released every day for addressing the exact same problem, maybe open source developers could expect more from sponsoring/donation.

FredericLatour on 22 Apr 2020

👎8 👍5 ❤1

@FredericLatour you might have some points, but most of your statements are full of subjective opinions.

@acepace Your comment is completely useless. Your usage is certainly extremely basic.

How can you judge if his use case is basic if you don't know what he is doing? Personally I have many projects built using TypeORM and one of them is almost half million lines of code with over 500+ tables (yes, TypeORM entities) successfully running on production and I know many other people having success running on it production with many users and different use cases.

At the very least, it would be fair to warn on the first page that the development is in pause and that one can not necessarily expect any answer to any question. The software is not unusable, far from it, but take it or leave it as it is....

It's not necessarily you must receive answers from maintainer, there is a community, and other people can answer, or other people can find and propose a solution.

When someone starts an open source project, he does not necessarily expect making a living from this project. This is obviously always a possible opportunity, a bet, but not one is to blame if it does not work.

Nobody blames. What's happening is other people blaming about missing answers from maintainer, etc. etc. Nobody really obliged to do it, but people forget about it. What you basically say its open-source, nobody really obliged to make donations, and I completely agree. But who told you someone is obliged to answer every question different people (with different skill set / knowledge / previous experience) is going to raise?

Now about your particular problems.

I see you make loud statements here and in other repos, but what if I tell you are mostly wrong? Other people might listen to you without going deep in details and it can have a consequences for everyone.

I had to dig hard to discover that @CreateDateColumn and @UpdateDateColumn were relying on Mysql default field value to be set to CURRENT_TIMESTAMP to get their initial values but on the other hand was not relying on MySql ON UPDATE default value to update @UpdateDateColumn value.

This functionality do its job. What about how they work internally, it doesn't have to be documented. Its not possible to document every small detail, especially such low-level details. Right, for some people it can be important to know, but for others more complicated documentation means harder learning curve. For people who wants to understand it, it's easy to check source code or generated queries. There can be a reason why ON UPDATE wasn't used that you don't know.

Not only I'm not sure this is a sensible choice but the documentation is completely unhelpful

Why do you make such conclusions? Do you know all related issues and were able to find the most balanced choice?

I also just got bitten by BeforeInsert that is not always firing (#5493).

I'm quite sure this guy does something wrong, so I believe you do too. This functionality is test-covered and there is a low probability that its a bug. If there was a bug it would have more comments and likes.

the documentation is very lacking overall and there is no way to ask for clarification.

I already provided answer above about documentation and asking for clarification.

As far as I can see there are many other problems unanswered or unresolved ...

Same here. I already answered before that in software there are always place for bugs. But again, most of opened issue - are just questions, misunderstanding, incorrect usage etc. etc. Because people come with different knowledge, different previous experience, different skill set. Personally I can't afford myself to figure out each problem and try to answer every question. But since its open-source and community-based project, anyone can do. You too.

Now, even if there were real issues with BeforeInsert and @CreateDateColumn/@UpdateDateColumn - I don't see how really significant these problems can be in a serious project with more or less complicated use cases.

pleerock on 22 Apr 2020

👍15

Regarding @CreateDateColumn and @UpdateDateColumn

You must be kidding :)

Here is the documentation:

@CreateDateColumn is a special column that is automatically set to the entity's insertion date. You don't need to set this column - it will be automatically set.

@UpdateDateColumn is a special column that is automatically set to the entity's update time each time you call save of entity manager or repository. You don't need to set this column - it will be automatically set.

The problem is not that it's doing the job or not. The problem is that by reading this documentation, you are expecting Typeorm to handle things automatically. How am I supposed to know that I need to rely on my DB for this to work properly when the doc says it is handled automatically.
The result is that one will quickly realize that it doesn't work (unless he has set up the DB column accordingly but there is no reason to set it up because of the documentation).
Of course, because it sounds so weird that there is such a bug, one will question its own code and then do some researches and try to sort all the posts, feedback, workarounds because no one seem to come up with a definitive answer on what's going on here (unless I miss it).

You : Its not possible to document every small detail, especially such low-level details. Right, for some people it can be important to know, but for others more complicated documentation means harder learning curve.

It's really no a detail in that case. It is an essential information for using the feature.

Me : Not only I'm not sure this is a sensible choice but the documentation is completely unhelpful

You : Why do you make such conclusions? Do you know all related issues and were able to find the most balanced choice?

The documentation being unhelpful on that matter is not a conclusion but a fact.
Now regarding this approach being a sensible choice, I stated "I'm not sure". I would hardly consider this a conclusion. That said, being logical as we, hopefully, all are as developers, it seems rather natural to question this choice (even if the feature was properly documented):
I mean, why would one rely on the DB for date creation? It makes things unnecessarily complicate with more moving parts. And why making such a choice for date creation and then relying on Typeorm in-house code for date update?
So, indeed, there maybe a conscious choice behind this approach, however, it's not uncommon to somewhat document (clarify) a technical choice that is not logical at first sight.
That being said, this would be just a plus and not a necessary information.

Regarding @BeforeInsert()

You: I'm quite sure this guy does something wrong, so I believe you do too. This functionality is test-covered and there is a low probability that its a bug. If there was a bug it would have more comments and likes.

Here is the documentation:

# @BeforeInsert
You can define a method with any name in entity and mark it with @BeforeInsert and TypeOrm will call it before the entity is inserted using repository/manager save. Example:

@Entity()
export class Post {

    @BeforeInsert()
    updateDates() {
        this.createdDate = new Date();
    }
}

From this documentation, I'm not sure how I am supposed to make it wrong. There are many issues related to BeforeInsert. To tell the truth I didn't push further on this matter but I will make the guess that this is merely a documentation issue as mentioned here.

Would certainly be better having those hooks at the repo level or something similar but that's another subject.

Regarding my comment to @acepace

You: How can you judge if his use case is basic if you don't know what he is doing?

He is the one who was very judgmental in the first place. Coming here and say pro @pleerock and anti some haters is just being useless (at best - I was polite):

I can't see much haters here: some are providing ideas for getting financial support, some are proposing to pay a little amount, some express frustration, some disagree with you.
The guy basically explains that Typeorm works for him and therefore, everybody should go back home and say thanks.

Now, how come I'm judging his use case basic?
The guy explains that he is building capable applications but that it's not commercial - if not he would get its company to pay.
So his Company (or the company he works for) is building capable applications that brings zero added value to this Company (if not it would be commercial). I'm assuming those are certainly basic applications. If not, we can be certain that his Company would pay for using a stable product with decent support.
But you are right, maybe I was too fast. Maybe those non commercial applications are ust Open Source application that are published somewhere on Github??

Misc

You: Personally I have many projects built using TypeORM and one of them is almost half million lines of code with over 500+ tables (yes, TypeORM entities) successfully running on production and I know many other people having success running on it production with many users and different use cases.

No doubt about that. As I said, TypeOrm is far from unusable. That said being the developer makes things somewhat easier when documentation is lacking.

You: I see you make loud statements here and in other repos, but what if I tell you are mostly wrong? Other people might listen to you without going deep in details and it can have a consequences for everyone.

I made indeed a couple loud statements especially on FoalTS repo (a recent backend web framework a la Nestjs that I used to test) that somewhat promotes typeorm by default which I consider a bad idea considering the current situation.

I can't see anything wrong in those statements:

First of all, I did not disrespect you. I clearly explained that I could understand your position. (Still it does not change the situation).
I explained the problems I had faced when testing Typeorm. You may consider that those are minor problems but it is really exhausting to fight with a lacking documentation when there is no chance to get any clarification.
I was really doing basic stuff and had to spend hours just to get to understand how to set up CreateDateColumne and UpdateDateColumn properly. How many of those matters when going into a more complex scenario? How many hours fighting between the documentation / issues or maybe the source code as a last resort to get how to properly use some feature?

I stand on my postion, I consider that the current situation of TypeOrm does not make it suitable for the ORM of choice of a Framework and I would certainly double warn anyone that would consider using it for a new project in Production.

Me: At the very least, it would be fair to warn on the first page that the development is in pause and that one can not necessarily expect any answer to any question. The software is not unusable, far from it, but take it or leave it as it is....

You: It's not necessarily you must receive answers from maintainer, there is a community, and other people can answer, or other people can find and propose a solution.

For some reasons, nobody seems to answer. Here is an issue I posted regarding @createDateColumn back in March. It's not like this was an utterly complex question. I was feeling there was something wrong with the documentation (it could not be such an obvious bug) but at the same time I was somewhat unsure how that such an important information for using this feature was still missing when multiple issues had already been raised. At that time, I was not aware of the "Future of TypeOrm" discussion.

Here again I stand on my position and that would fundamentally be my only complaint: That is not fair to let people go into TypeOrm without any kind of warning regarding the situation. The fact that TypeOrm is more than usable is not a proper excuse in my opinion.
Now, it is perfectly fine that people knowing what the situation is decide to keep going with TypeOrm.

FredericLatour on 22 Apr 2020

👎6 👍2

Obviously this is a very complicated code base to maintain, and there are couple problems this repo is facing right now, and I would say one of the biggest issue is... There are just too many GitHub issues and you don't have enough time to maintain them at the same rate.

I think the possible resolutions of an issue can be summed up to

merged and closed with a duplicate reference
closed after pointing to a documentation
add new documentation and link it the issue
add to backlog if it's a genuine bug.
add to backlog if it's a good feature request.

I would say the majority of issues can be resolved using 1~3, which is often very simple. This is a good news!

I think the first viable step to make this repo more manageable for you (before you hopefully get your 10k monthly funding), would be to get people to help you with steps 1-3. You can focus more on 4-5.

This is a very complex repo and I - by no means - will ever be as knowledgeable as you are @pleerock about every single details and technical decisions that went into this. But I am hopeful that there are a number of people who is interested and willing to help you with cleaning up the simpler GitHub issues :)

smblee on 23 Apr 2020

👍24

@smblee that was my suggestion and @ricardojr too. He could use some help, some of us are willing.

Also for the @CreateDateColumn and @UpdateDateColumn (I'm not anyone's side here) but @FredericLatour was right, the documentation wasn't clear enough. I had to read the codebase and checked the issues. Maybe because some of us used to being lifted by the ORM we used, Like me, in rails, I don't have to set up On Update on database,timestamp method will do it for me because the documentation says so. But I see the pattern here, You have to set up the migration the same as the SQL, if you want to do a cascade it should be in the migration too though I'm not sure, that's how I do it now. lols.

Anyway I'm not on anyone's side but we're grown-ups here and maybe we could talk about a solution.

artoodeeto on 23 Apr 2020

👍2

@smblee I think there is a secondary feedback loop to projects that have too many open issues and pull requests. Maintainers can't keep up which turns off contributors due to slow response times. Why submit a pull request if no one is going to look at it? Empowering a larger group of people to triage problems would definitely help prevent that.

dsbert on 4 May 2020

👍12

Why not leave the PR reviewing to the community?
You could stipulate a minimum number of community reviewers for each PR based on how complex you judge it to be. This would force the community to take lead since the fixes to their problems are literally in their own hands, and it would shave off time that you currently spend reviewing PRs.
I understand your fear about people messing up with your code base, but if i'm being honest, unless you give the community the benefit of the doubt, maintaining an open source project of this size is not going to be doable.
There are a lot of bright people here who would love to contribute if given the chance.

tareqdayya on 15 May 2020

👍8

So much complaints here.
Like TypeORM but not like how it grow?
Have a bright mind, free time and would like to implement some awesome features?
Then, there is an option. Create a fork, get all bright minds together and do own version.
Who knows, if results will be good, this repository will take some features that good enough and well implemented.
But, IMO, current topic already contains all opinions.

GitStorageOne on 15 May 2020

👎5 🚀1 ❤1 😕1 🎉1 👍1

Why don't we just create a group of contributors that can help label issues in accordance to this comment? Of course that's assuming there are enough developers that are familiar enough with the codebase and have the time. Once everything is labelled, you can prioritize bugs easier and there will be less work for you.

In the meantime, make it clear that issues should be for bugs and not questions. Questions should take place on Stackoverflow or a chat room that you can create (eg Discord). That's what nestjs does, and they seem to be managing very well (they do have other team members however).

sometimescool22 on 15 May 2020

👍6

Have you thought about changing over to a business model where usage is free for smaller companies, but bigger companies need to get a license from you? The money from licensing could then be used to finance development of the library.

dbartholomae on 19 May 2020

to expand on @dbartholomae suggestion, perhaps you could charge clients based on how many queries are issued by Typeorm functions in production. A fair system that is easy to implement. Most of us sign up for the pay-as-you-go modules without a second though since we know we'll never have to worry about their costs unless we have actual users.

tareqdayya on 19 May 2020

👎20

to expand on @dbartholomae suggestion, perhaps you could charge clients based on how many queries are issued by Typeorm functions in production. A fair system that is easy to implement. Most of us sign up for the pay-as-you-go modules without a second though since we know we'll never have to worry about their costs unless we have actual users.

How are you going to track queries?

Also, the ORM space is very competitive in the sense that there are many good ones. TypeORM would need to have a defining feature that makes it worth the money compared to something like Prisma which is building an entire suite of database applications.

sometimescool22 on 20 May 2020

👍3

Hi @pleerock,
We were moving a big chunk of our codebase at work to typescript and i was the one motivating everyone and even calling for more typescript hires at work.

I was looking at some frameworks and ORM to work with for the back-end, seeing typeorm as having data mapper pattern was lovely until i read this post (complaints i think) since 2018 (1 years and 6 months ago) which seems to hurt my heart(just my opinion).
I was thinking till the new hires get fully involved in day-to-day coding, we can make some financial contributions(1st will be a big chunk, then we do monthly donations) to help this project grow faster and maybe our main interest is to make some requests for some features we need but still in some open Issues...

I can understand your pleas and complaints, but you could just have keep on doing your thing then expect the contributions come in later as other(now big) frameworks do to create awareness; and i definitely understand everyone's not equal(!=) but seeing the project this way i think its almost dead, we could just spend some amount(to get external hires - freelancers, etc) on creating plugins that will fix those bugs and make necessary improvements we need.

Yet, that doesn't mean we won't donate to the project(expect them soon) coz we appreciate the big chunk of work put into this already...

I just thought of pouring out my heart since i saw this post last week and been following the typescript stack since last 3 months.

Nice work, though...

noobshow on 30 May 2020

👍8 ❤4

I just made a PR https://github.com/typeorm/typeorm/pull/6165, but I think it won't have a chance to be reviewed after seeing this discussion.
I know maintaining open source projects is a very very very tough work. I've made some in the past(see my profile).

I don't have any solution or suggestion to keep this project going. My only opinion is: don't use TypeORM, use Sequelize. (Sorry)
Sequelize may be more ugly to code, but as I've used it for more than 2 years and it supports millions of users in my service, it is actually almost bug-free and works as I expected. This aspect is much important which can save you tons of time.
TypeORM just sometimes works weirdly and lacks some common features.

oney on 3 Jun 2020

👀1

Have a bright mind, free time and would like to implement some awesome features?
Then, there is an option. Create a fork, get all bright minds together and do own version.

There is already an alternative called MikroORM (Introducing MikroORM, TypeScript data-mapper ORM with Identity Map). If you don't like TypeORM, use MikroORM. Nobody forces anyone to use TypeORM and act as if it's a commercial product with paid support package.

hakimio on 26 Jun 2020

👎3

I strongly recommend MikroORM. The owner is responsive, open minded and happy to accept almost every help.

murbanowicz on 26 Jun 2020

👍2 👀1

I also highly recommend MikroORM. It's much more similar to Doctrine (if you are coming from PHP world) than TyoeORM. It's based on Knex. Definitely take a look!

lukeeno on 27 Jun 2020

👍2

I've seen several good actionable suggestions in this thread, none of which seem to have been implemented, so I want to summarize some of them:

Financial

Easy to do; results may vary. These could be done __today__.

[ ] 1. Move the sponsorship section to near the top of the readme.
[ ] 2. Add a call-to-action for donating to the sponsorship section, including a monthly goal. E.g. ($5k/month, or $10k), and explain how that money will be used/distributed. (The total sponsorship section should be short though, so as to not crowd out the documentation).
[ ] 3. Sticky an issue that talks about how to donate, including a link to OpenCollective and something like issuehunt.
[ ] 4. Add a donation options blurb, including something like issuehunt, into the issue template. Make it prominent. Depending on how aggressive you want to be you could even suggest that questions or feature requests are unlikely to receive a response if there is no attached bounty - support isn't free.

Code

More difficult but will pay off.

There are just way too many issues for anyone to handle. Part of the problem is that these issues cover the core of TypeORM, and all of the databases. I would watch this repo in order to help answer questions about things I know about, but that would result in way too many notifications about things I don't know or care about (e.g., databases I don't use), and I would end up ignoring them. Spacemacs has this same issue (and I wish they too would break up into smaller repos, as they've discussed), but they also have way more contributors, so it isn't quite as big of a problem.

[ ] 1. Split the database support into plugins that have their own repo as suggested here. In my own opinion, it probably isn't worth bothering with new features or fixes until this is done.
[ ] 2. Move each issue to their relevant repo. For example, questions about postgres moved to the typeorm/postgres repo. Don't check if they are duplicated, or valid, or anything. Just blindly move them. This is way easier to do than trying to resolve them all, and will break the work up into manageable chunks that interested parties can help tackle - people who care about postgres will tackle the typeorm/postgres issues. After 1, This part could probably be done in a couple of days by one person, or even faster if there is help.
[ ] 3. Solicit some volunteers to manage issues in each of these repos. At this point people can review issues, mark duplicates, invalids, or promote issues to the typeorm/core. Eventually, some of those people could be given commit access without also having to burden them with the overwhelming responsibility of dealing with all the rest of TypeOrm too.

This will have a few advantages:

It will have the added benefit of defining a strict interface between databases and the Orm core.
Combined with 1, it will make everything easier to understand and maintain for new contributors and old.
As stated, It will reduce the amount of code a person has to pull in because they don't need the code for all of the databases they are not using.
It allows people to easily add support for databases without needing to involve the core project at all.
...which means the project can both support many different database backends, while also offloading more of that work to the people who care about those databases.
It will reduce the apparent number of active issues, which will give people more confidence in the project, and thus be more willing to contribute financially, and choose the TypeOrm for their projects.
If there are lots of bugs with a new database backend it won't make the whole project look shaky.
It will be easier to make changes piece-meal. Want to update to a typescript version with a breaking change? No problem. You can do it in core, and the plugins can update when they are ready.
It will be easier to merge changes because there won't be as many conflicts in any individual repo, and because a bad change in one backend won't be able to cause regressions in the rest of the project.
Npm download stats will help you know how much use each backend gets so that work can be prioritized.
It would allow you to focus more on the TypeOrm core, and when interface changes are made, other people could help implement them in the plugins, leaving you free to help the under-supported plugins.

In my opinion, if this part doesn't happen you will never feel like you are above water on this project, and it will always be stressful. An ORM is a big project and is worthy of being broken up.

Github

I'm not sure if this is possible with Github permissions...

After the code is broken up into different repositories remove the ability of the public to create issues in the TypeOrm core project, and direct them to the relevant plugin. That is: Only allow the public to comment on existing issues. Allow only committers of the TypeOrm Core and the committers/issue managers of the plugins to create new issues in the TypeOrm core. I suppose you could allow the public to make pull-requests to core, because then they have at least done the leg-work to understand the project.

But, how will people submit bug reports/feature requests!? They will submit them to the relevant plugin. Are they using typeorm/mssql? Then they submit it there. Let the maintainers raise issues to typeorm/core as necessary.

This way, there isn't a constant flow of people incorrectly reporting mssql issues to typeorm-core and someone having to manually move them or tell close those issues.

Alternatively

_This actually might be better because it would allow the public to create documentation issues in core._

The plugins could be the main installable packages with typeorm/core as a dependency or peer-dependency that exposes the TypeOrm interface from typeorm/core, which might lead people to report issues to the correct repo by default.

Final Thoughts

I think that this is a good project that a lot of people find useful. Many of those people can and want to help improve it but currently is not organized in a way that facilitates that. I think these changes would move the project in that direction.

nspaeth on 15 Jul 2020

👍37 👀7

I've seen several good actionable suggestions in this thread, none of which seem to have been implemented, so I want to summarize some of them:

Financial

_Easy to do; results may vary. These could be done today._

[ ] 1. Move the sponsorship section to near the top of the readme.

[ ] 2. Add a call-to-action for donating to the sponsorship section, including a monthly goal. E.g. ($5k/month, or $10k), and explain how that money will be used/distributed. (The total sponsorship section should be short though, so as to not crowd out the documentation).

[ ] 3. Sticky an issue that talks about how to donate, including a link to OpenCollective and something like issuehunt.

[ ] 4. Add a donation options blurb, including something like issuehunt, into the issue template. Make it prominent. Depending on how aggressive you want to be you could even suggest that questions or feature requests are unlikely to receive a response if there is no attached bounty - support isn't free.

Code

_More difficult but will pay off._

There are just way too many issues for anyone to handle. Part of the problem is that these issues cover the core of TypeORM, and all of the databases. I would watch this repo in order to help answer questions about things I know about, but that would result in way too many notifications about things I don't know or care about (e.g., databases I don't use), and I would end up ignoring them. Spacemacs has this same issue (and I wish they too would break up into smaller repos, as they've discussed), but they also have way more contributors, so it isn't quite as big of a problem.

[ ] 1. Split the database support into plugins that have their own repo as suggested here. In my own opinion, it probably isn't worth bothering with new features or fixes until this is done.

[ ] 2. Move each issue to their relevant repo. For example, questions about postgres moved to the typeorm/postgres repo. Don't check if they are duplicated, or valid, or anything. Just blindly move them. This is way easier to do than trying to resolve them all, and will break the work up into manageable chunks that interested parties can help tackle - people who care about postgres will tackle the typeorm/postgres issues. After 1, This part could probably be done in a couple of days by one person, or even faster if there is help.

[ ] 3. Solicit some volunteers to manage issues in each of these repos. At this point people can review issues, mark duplicates, invalids, or promote issues to the typeorm/core. Eventually, some of those people could be given commit access without also having to burden them with the overwhelming responsibility of dealing with all the rest of TypeOrm too.

This will have a few advantages:

It will have the added benefit of defining a strict interface between databases and the Orm core.

Combined with 1, it will make everything easier to understand and maintain for new contributors and old.

As stated, It will reduce the amount of code a person has to pull in because they don't need the code for all of the databases they are not using.

It allows people to easily add support for databases without needing to involve the core project at all.

...which means the project can both support many different database backends, while also offloading more of that work to the people who care about those databases.

It will reduce the apparent number of active issues, which will give people more confidence in the project, and thus be more willing to contribute financially, and choose the TypeOrm for their projects.

If there are lots of bugs with a new database backend it won't make the whole project look shaky.

It will be easier to make changes piece-meal. Want to update to a typescript version with a breaking change? No problem. You can do it in core, and the plugins can update when they are ready.

It will be easier to merge changes because there won't be as many conflicts in any individual repo, and because a bad change in one backend won't be able to cause regressions in the rest of the project.

Npm download stats will help you know how much use each backend gets so that work can be prioritized.

It would allow you to focus more on the TypeOrm core, and when interface changes are made, other people could help implement them in the plugins, leaving you free to help the under-supported plugins.

In my opinion, if this part doesn't happen you will never feel like you are above water on this project, and it will always be stressful. An ORM is a big project and is worthy of being broken up.

Github

_I'm not sure if this is possible with Github permissions..._

After the code is broken up into different repositories remove the ability of the public to create issues in the TypeOrm core project, and direct them to the relevant plugin. That is: Only allow the public to comment on existing issues. Allow only committers of the TypeOrm Core and the committers/issue managers of the plugins to create new issues in the TypeOrm core. I suppose you could allow the public to make pull-requests to core, because then they have at least done the leg-work to understand the project.

But, how will people submit bug reports/feature requests!? They will submit them to the relevant plugin. Are they using typeorm/mssql? Then they submit it there. Let the maintainers raise issues to typeorm/core as necessary.

This way, there isn't a constant flow of people incorrectly reporting mssql issues to typeorm-core and someone having to manually move them or tell close those issues.

Alternatively

_This actually might be better because it would allow the public to create documentation issues in core._

The plugins could be the main installable packages with typeorm/core as a dependency or peer-dependency that exposes the TypeOrm interface from typeorm/core, which might lead people to report issues to the correct repo by default.

Final Thoughts

I think that this is a good project that a lot of people find useful. Many of those people can and want to help improve it but currently is not organized in a way that facilitates that. I think these changes would move the project in that direction.

@pleerock I think these can be implemented, have a look

rubiin on 16 Jul 2020

@pleerock, Thanks for TypeORM. I'm just starting to build my startup and heavily depend on it. I have three suggestions to reduce the workload and raise money.

Add search on docs. It will help people find answers quickly.
Maintain a list of other open source projects using TypeORM, people can see examples if they are stuck. That's what many libraries do in the deep learning world (tensorflow, pytorch), they call it model zoo or similar.
Make all support paid, (which kind of already is unofficially because of burden), otherwise you'll have to always depend on people and if they helped willingly, you won't be in this situation. For example, I myself currently think that one day when my startup is successful, I'll donate and help out this project. Humans have short memories, so who knows if I would. If I have to bet, I will forget and won't.

I feel silly telling you all these things as I'm a nobody but it's an amazing thing you've created and I just want to say that don't let it die waiting for people to help. Take control and kill them all (bugs, not ungrateful humans who post stupid comments).

Dr-Phone on 17 Jul 2020

❤3 👍1

I don't think that people talking about MikroORM (including me) are spreading hate. It's good to show alternative in this situation. Pleorock has done a really great work on this library, but I feel like TypeORM has come to an end. It's almost two years of discussion and nothing has changed.

lukeeno on 17 Jul 2020

👍3

I would like to ask not to spam here. Thank you. If somebody prefer some alternative - try it, maybe it can better fit your needs. Nothing is perfect and there are always set cons and pros from every project you will use. Open source always lack of accountability, and if you are using some tool, try to support it if you can, because any author can end up switching to something else. It's just matter of time, or your support. So, try to support your favorite tools, no matter if thats TypeORM or MicroORM.

Thank you for all your suggestions and support.
I find many really good suggestions here, but the reason I don't implement them is because right now I'm able to implement only some of them, others would take too much time and efforts to do. But I think it wouldn't take a good effect to only implement some of them. That's why I'm waiting for a right time.

I just want to tell you that I already do have enough money to maintain this library for around 6 months without working on something else. So, I still plan to return back to it and put all my efforts to move it forward and apply all suggestions you have provided. I just need some time, because I took a big project under my responsibility and I can't leave until it's finished. Thanks for understanding. Right now I do my best (considering my business and health) to release new TypeORM versions very month or two to keep it updated with the most critical fixes.

pleerock on 17 Jul 2020

👍68 ❤36 🚀22 🎉18 👎2

@pleerock, Thanks for TypeORM. I'm just starting to build my startup and heavily depend on it. I have three suggestions to reduce the workload and raise money.

Add search on docs. It will help people find answers quickly.

Maintain a list of other open source projects using TypeORM, people can see examples if they are stuck. That's what many libraries do in the deep learning world (tensorflow, pytorch), they call it model zoo or similar.

Make all support paid, (which kind of already is unofficially because of burden), otherwise you'll have to always depend on people and if they helped willingly, you won't be in this situation. For example, I myself currently think that one day when my startup is successful, I'll donate and help out this project. Humans have short memories, so who knows if I would. If I have to bet, I will forget and won't.

I feel silly telling you all these things as I'm a nobody but it's an amazing thing you've created and I just want to say that don't let it die waiting for people to help. Take control and kill them all (bugs, not ungrateful humans who post stupid comments).

@pleerock, Found searchable docs here - https://orkhan.gitbook.io/typeorm/

Dr-Phone on 22 Aug 2020

@pleerock Please ask for two or three maintainers to volunteer. Give them recognition and make them committed by linking their profiles on the front page. Give them authority to cleanup outdated issues and merge PRs. You have hundreds of open PRs! Please don't waste that talent. There's a lot of people who'd love to contribute to your awesome library.

Please don't let it die.

Or at least endorse a friendly fork if you're really done with it.

elendirx on 25 Aug 2020

👍23 ❤9 🎉7 🚀3

@pleerock @AlexMesser Have you guys thought about charging large companies? The Lsos can help you set up everything. TypeORM is used at many large companies and you'd easily get enough money to work full-time on TypeORM.

brillout on 27 Aug 2020

👍3

@pleerock @AlexMesser Have you guys thought about charging large companies?

Not a viable business model for a MIT licensed library. Just forget about getting enough money from this. Others have tried. Not a chance.

But look at the number of PRs! Lot of us depend on this lib and we want to keep improving it for free. What we need are official maintainers and leadership.

elendirx on 27 Aug 2020

👍1

@elendirx

There are actually many projects who managed to commercialize their open source project. Ag-grid for example is now a company of 20+ employees.

What we need are official maintainers and leadership.

If it didn't it happen yet, it's probably because leading a project like TypeORM is hard work. There aren't many people out there willing to put the effort.

@pleerock is willing to do that - shouldn't he be compensated for that?

There is disconnect between the many companies that are more than willing to pay a small amount and the fact that TypeORM receives only 10k / year in donations.

At the Lsos, we help projects increase donation rate, but at some point the question ought to be asked whether leveraging other means to get to profitability would not be a win for everyone, including those who pay the fee.

If you were a 30 dev company, would you be willing to pay 30$ / month for TypeORM? I bet 99% would.

Obviously, everything should remain 100% free for hobbyists, small companies, and nonprofits. Price should never stop anyone from building stuff. I love building too much to ever compromise on that.

brillout on 29 Aug 2020

There aren't many people out there willing to put the effort

There aren't many people out there willing to put the effort because it doesn't pay off.

There is disconnect between the many companies that are more than willing to pay a small amount and the fact that TypeORM receives only 10k / year in donations.

What disconnect? All I see is misunderstanding of basic economics.

I don't want to call anyone naive, but I'm afraid you won't understand until you try to commercialize a lib. Donations are not sustainable long term. You can't sell trainings or certifications because ORM is too generic. You can't charge for new feature because ppl wait until someone else pays for it. At the same time you have constant influx of new issues and PRs. It's frustrating. You start to hate your own project.

If you were a 30 dev company, would you be willing to pay 30$ / month for TypeORM? I bet 99% would.

No, they wouldn't. It doesn't make sense. Why would my business pay for something that my competitor has for free? That's called charity. It can buy @pleerock a month or two but long term he'll suffer.

The only viable model is commercial licensing. Unfortunately it's nearly impossible to migrate from MIT to commercial. You'd have to build something new around the lib, something you can sell. No chance with typeORM, sorry.

Ag-grid for example

Exactly what I'm talking about. See their licensing: https://github.com/ag-grid/ag-grid/blob/master/LICENSE.txt.

elendirx on 29 Aug 2020

Shouldn't it be possible to just put the next version under a more restrictive license?

dbartholomae on 29 Aug 2020

it's nearly impossible to migrate from MIT to commercial

That's not true. Actually, if I remember correctly, ag-grid was MIT licensed before they went with the open-core model. There are many ways and many precedents of projects going from MIT to a commercial setup.

The only viable model is commercial licensing

We actually develop novel ways to commercialize and sell open source tools while sticking to the MIT license, which would actually work quite well with TypeORM. As always with the Lsos everything stays 100% free for individuals and small companies.

brillout on 29 Aug 2020

Shouldn't it be possible to just put the next version under a more restrictive license?

Assuming that were even possible (more on that later) the previous version would still remain MIT licensed. I could see this turning into a situation where forks like typeorm-plus from people in the community tired of waiting for features like SoftDelete happen making an entirely permissively licensed OSS fork of typeorm.

However realistically it's probably not possible. typeorm includes code written by many different people. You can argue that by contributing they gave permission for their contributions to be used under the project's current license. But because typeorm doesn't seem to have a CAA or specific variant of a CLA, all the contributors keep the copyright to the portions of typeorm they wrote.

The MIT license allows you to sublicense, but it does not allow you to remove and replace the license; even if you sublicense the MIT code still remains MIT. So the only way to replace the MIT license would be for everyone with copyright over the code to agree to change the license (to whatever GPL + commercial terms you need). However with copyright being held by so many different people, this may be unlikely.

dantman on 29 Aug 2020

The MIT license applies only on the current source code and not on future source code modifications.

For example, if I clone the TypeORM repo on my local machine and I make modifications, then I can choose to publish my modifications under any license I want. I completely own the copyrights of my modifications and the MIT license doesn't enforce anything on my modifications. That's why the MIT license is called permissive; non-permissive licenses such as the GPL have so-called copyleft clauses which enforce modifications to be published under the same license.

While the current version of TypeORM will remain available with the MIT license, future TypeORM versions can be published with any other license.

I've been following this thread since the beginning. It's been 2 years now and yet no solution has materialized; there doesn't seem to be a viable perfect solution. It seems to me that the least worst path is to bring large companies to pay a small amount, and if not taking any decisions leads to the death of TypeORM that would be the worst path.

I wouldn't be involved with the Lsos if I wouldn't believe that what we do is beneficial for the world, and what's of utmost importance to me personally is that 1. TypeORM remains forkable, and 2. everything remains free for individuals, small companies, and anyone who cannot afford to pay the small amount.

brillout on 31 Aug 2020

❤1

i'm so happy @imnotjames is doing stuff :D. Keep up the good work

PodaruDragos on 23 Sep 2020

👍28 ❤17 🎉9 🚀7

I appreciate the effort that the devs are doing. I would imagine a new updated call to arms of the community would help, unless I am missing one that exists. Donations or help is needed for this to exist and instead of the fallback that well if you don't we'll just be slow. The scope of the project is far too large for 2 people. Maybe dial back the scope and don't try to support everything. From reading this thread, it seems the repo is dying or there are just more people proposing reasons not to do something than do something. Is it dying?

stephtea on 10 Nov 2020

this issue is two years old, and someone who was thinking its dying two years old bite their nails now 😆 Stability isn't a synonym of dying. So no, it's not dying, we are pushing fixes and new small changes as we can and hope in a near future we'll have somebody working a full-time to do even more.

pleerock on 10 Nov 2020

🎉5 ❤4

@pleerock That's great to hear! I found this thread as the last update on the status/future of typeorm and the comments got more pessimistic recently and the last comment by a dev was that they were kind of busy with other things. Other forums reference this thread as well.

Per my original comment suggestion, it may help to have an updated status post or call to arms for assistance/donations if needed. I think other people than myself find this thread as the last update. I'm happy to donate myself, but it would be good to understand if there is momentum or not or if I'm just tossing money into the wind.

stephtea on 10 Nov 2020

🎉2 👍1

I have to agree with @stephtea here - I think the scope of this project is indeed far too large for 2 people. @pleerock while it is true that the fixes and small changes to maintain stability are keeping the project from dying, is this really sufficient for the modern Node.js/TypeScript ecosystem where rapid development is the norm?

Here are the latest statistics for TypeORM downloads on NPM, monthly/weekly follow a similar trend. (Although not directly relevant, it's worth noting that MikroORM has had just 90,000 downloads in all of 2020).

At a time when the projects popularity is exploding it is really a shame to see such a lack of progress. I appreciate that you have been busy and that the donations are still not representative of the amount of work necessary, but if the project is not dead I certainly wouldn't call it healthy.

Recently I began transferring my website stack to NestJS and TypeORM has become a crucial dependency for me. I had considered making donations to the project but I realized it would be a lot more efficient to offer my support directly by making contributions. I have already submitted a few of them here, and have plans to continue with many more, but I'm facing the roadblock that there is no discussion on them from other developers, and this project is complex enough that it is difficult to make decisions alone. I would love to build further on these contributions but it doesn't make sense for me to invest more time until I can have some confirmation that the original contributions will be merged.

When it comes to once off contributors, _if a pull request sees no activity for many days they will inevitably become discouraged and when the time for final review/merge eventually comes around they will be gone._

I don't agree with the mentality found on some old issues suggesting that pull requests need to be merged because so much time has passed, and in fact from viewing some of the suggested changes I am glad that you have been strict with what gets accepted, but an active two-sided dialogue is still needed. In many cases that dialogue is the needs of new users requesting new features vs. maintaining existing users and stability. This balance is important, but we can't let it stifle innovation. The current version of the project is 0.2.29, and according to Semantic Versioning 2.0:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Let's use that to our advantage and push forward as much as we can. You have already outlined a number of features that you plan to remove in 0.3 so I don't think any user can be particularly upset if there are some breaking changes that come out of it - after all the goal is to make the API easier to use and they will benefit long term. Looking at the download trends, every year of holding back changes for the sake of current users actually ends up disadvantaging more users in total. If there are corporate users who require permanent APIs and long term support then as mentioned previously in this thread they are free to contribute towards that or simply continue to use their current version.

You have mentioned that you would hope to have somebody working full time, why don't we begin that process now and try formally gather more developers to take part in the process? The great thing about this project is that anyone who is capable of integrating it into their own projects is also in theory capable of contributing, and among those 14 million downloads in 2020 there are bound to be some people with the knowledge and the will to do so. I'll be the first to volunteer myself, while I can't commit my full time permanently I would be happy to become a regular contributor for at least the next year or so.

Passing on the project to someone else entirely isn't the right solution, which is why I haven't just forked and gone my own way. You know TypeORM inside out and are in the best position to make big decisions - let's form a team around that, bounce ideas off eachother, fast track some changes (refactoring in particular) that are good to go, discuss and improve those that are not (a core developer chat would be great, free from the unfortunate end-user question spam that has plagued both GitHub and Slack). When the time is right and you are back to working on TypeORM full-time, you will still be at the center of it, but it will hopefully alleviate pressure both now and long term.

nebkat on 12 Nov 2020

👍15 ❤1

@nebkat I agree, if there were some more people on the core team, the PR merge will be quicker and more people would get inspired to do PR for issues. Also a single person handling a project is a lot for them to take in. In case of many opensource projects, the code contributions from other people are way more than the author himself so I think we should consider what @nebkat has suggested

rubiin on 13 Nov 2020

❤1 👍1

Typeorm: Future of TypeORM

Most helpful comment

All 135 comments

Regarding @CreateDateColumn and @UpdateDateColumn

Regarding @BeforeInsert()

Regarding my comment to @acepace

Misc

Financial

Code

Github

Alternatively

Final Thoughts

Financial

Code

Github

Alternatively

Final Thoughts

Related issues