davegaeddert

Hey! I'm the creator (fork-er?) of Plain. I have mixed feelings too — if all this does is help spur some new activity around Django, that would be a good outcome!

Lol, that's why I added the "or watch the video / read the Forge start page". 50% off right now though! Still thinking through some of these things. Not sure how to let people "try" it without basically giving away all of the value (code, which you can't take back).

> your promo material sucks

Well put.

Yeah I'm not 100% sure yet what level of Django experience is required to use (or at least appreciate) Forge? Should you have used Django at least once before on a project? Gone through the official Django tutorial maybe (https://docs.djangoproject.com/en/4.0/intro/tutorial01/)? At the moment, if you have not actually used Django before then I probably would recommend you go through their tutorial and THEN try Forge (or watch the video / read https://www.djangoforge.dev/docs/start/).

Some differences will immediately jump out — they'll tell you very (very) little about how to manage your dependencies, local environment, hosting/deploying, configuring settings with "secrets" for local vs production, the fact you'll probably want a custom AUTH_USER model later and it will be super hard to change, etc. But yeah, to sell those as differences, you do need to have a baseline familiarity or else I need to do a really thorough job of explaining and pointing them out ahead of time.

I think the gist, if you compared vanilla Django to Forge, would be that vanilla Django is almost completely open-ended. There are a lot of decisions you're going to have to make, and research you're probably going to have to do. Forge removes a lot of those decisions and makes them for you. Some are easy to spot up front, but others not until you're further down the road or have more experience...

> Can you make a video, where you show how to make a full fledged SaaS with django-forge and deploy it? How long would that video be?

Videos are absolutely the way to go. I'll try to do more and run through more of the parts and maybe a complete process. That first video I made stops short of deploying to Heroku, but it's maybe 5 minutes away from being deployed. Beyond that, basically every "topic" in the sidebar could use at least one video.

I haven't actually tried Pegasus, so I can't say exactly. In a lot of ways I'm sure they're similar. Some differences with Forge might be the removal of options: - Pegasus looks like it supports multiple CSS frameworks, Forge only comes with Tailwind - Pegasus talks about multiple deployment options, Forge focuses completely on Heroku - Pegasus talks about creating venvs or using virtualenvwrapper (+ pip-compile?), Forge uses Poetry

From what I understand, the update process for Pegasus is also a little bit more manual? Forge is intentionally set up to be a git remote, with directories and stuff named so that an update is essentially `git merge django-forge/main`.

Probably lots of little differences when you get into it — just different decisions from different people. Hoping to document more of Forge soon!

Yep. Don't know if this will become an issue or not, but it is unfortunate in retrospect.

Yeah I could see that argument too. Lots of hard decisions and interesting questions in terms of how to navigate what people want/need. Honestly I don't envy their situation. It has even made me think crazy things like what a Django fork would look like... the thing has some bloat that could stand to be removed too. And some legacy decisions that are super hard to change, but also need to be changed.

Kudos to czue and Pegasus! I haven't used it before, but if that's a better fit for what you want, go buy it!

Honestly I feel a little weird "competing" directly with something like this, but such is life. Thanks to everyone who has made something similar (in any ecosystem), which is part of what got me over the hump of thinking it was even possible. I'm glad Django is getting some options and new ideas!

All good ideas — thanks for taking the time. I've been thinking about some of these but not all.

On the 1 customer vs 100, I totally lean towards the 100. I have a blend of these with https://www.pullapprove.com/ and the higher the price, the more it feels like you just work for them. Pros and cons, but personally I don't want something that looks like freelance/consulting/employment.

Don't have any plans for Wagtail or hosting, but those are interesting questions. I'll have to give it some thought.

Good point. Still trying to figure out who is interested, but I'll probably add a student/educational discount too. (If anybody sees this and wants that, let me know.)

https://bullettrain.co/pricing is another example ($1450 one-time + $550/year).

> Maybe it’s more for people who are about to start a second revenue project.

I do think this is an interesting point that's come up a couple times now.

For what it's worth, I just added a 50% discount to the top of the page for the time being.

I have some regrets on this. I sort of landed on the name and then learned about Laravel Forge. But went with it anyway.

I could absolutely see the "borrow some code" angle. Especially if you have an existing/established project where it would be pretty hard to integrate everything anyway. $1000 is not much for a company looking for another "professional Django resource" (if that's what it is).

Would have no issue with some people paying for access, borrowing some stuff, and being a part of a "community" of people sharing variations of the ideas and occasionally factoring that in to the Forge code itself, copying it out, etc.

> Things like django-coookiecutter are great, but they only really cover the project structure.

This is an important point, for me anyway.

Yeah $1000 can be a lot for an individual (myself included), especially for a hobby/side project. For individuals, at this price, it's probably more of "I've built a small revenue generating project before, and I'm going to skip some steps this time + connect with some other people doing it in a similar way"?

Yeah I've been considering that. Probably more likely that I'll lower the price, learn some things, then ramp it up. Free feels hard to reverse and the difference between "I wouldn't pay at all" vs "I'd pay less than that, but something" is pretty big (and important to me unless I figure out another way for the project to get paid for).

Also this

> Things like django-coookiecutter are great, but they only really cover the project structure.

https://news.ycombinator.com/item?id=30781528

Thanks. Completely agree on the contrast to rails... This has been a super interesting process for myself in thinking through "what are the parts of Django that are either way too clunky, or just completely outdated?" I think there's more than a couple... There are a lot of things I realized I have just gotten used to, but people new to Django would find super odd (why aren't emails required to be unique on users by default?).

Would also recommend people listen to the first episode of https://www.frameworkfriends.com/ if they are thinking about these kinds of things.

Thanks! I found Reactive somehow yesterday — haven't looked closely at it yet but I will. Always cool to see more stuff in the ecosystem. But yeah, personally I feel like there are few things the Django community could learn (or at least try) from the Laravel (and Rails) communities. I love free software, but it has downsides too! (Like the fact that I can't justify spending all my time on it.)

Might be too high — not sure yet. It is partially based off of https://bullettrain.co/pricing#now (and I know they're making that work... but there are some differences).

> why would any business want this?

An existing business building a new product? A new business getting off the ground? Don't know exactly yet.

> Like others I also wonder who's the intended audience.

Me too — trying to figure that out!

> but that project needs to be basically non existent while also being somewhat serious

Super interesting point. I've helped integrate it into some existing projects and it is not fun.

> In what way is it more than an expensive cookiecutter repository?

I don't disagree with this. A couple differences in my mind are support (that you're paying for, and has an incentive to be as helpful as possible) and on-going updates (a cookiecutter won't help you integrate improvements over time, as far as I know).

Pricing is totally an experiment right now, and I shot high on purpose. Suggestions?

Wish I could figure out how to do a free trial. I've obviously considered whether the whole thing should be free and open-source in the first place, but getting paid to work on this stuff is the best way I know to make something high quality, where good support, improvements, fixes, etc. are all expectations.

Happy to give out some discounts if people are interested in that.

100%. Still working through it, but I think the question (or one of them) to me is whether you can lower the bar to where non-experts can get off the ground with some "expert" opinions (or at least experienced ones). Django itself just doesn't tell you, "hey Heroku + Stripe + Sentry + Tailwind + Poetry will get you off the ground if you don't even know where to start, and here's how to do it. And here's how you patch over some of our own idiosyncrasies... Revisit these things when you hit $X MRR or X users and know more about what you're doing."

Totally unproven yet, but I also think there could be an interesting community aspect. If everybody "in" Forge is essentially paying to be there, I think could have a really great place to ask questions and get help from people who are building stuff with a similar mindset to yourself.

Thanks. Yeah, I agree with that. I'm honestly still trying to figure out exactly who it's for and the whole free/paid/price equation. Individuals? Agencies? Beginners? People with a couple years Django experience?

I'm finding it super helpful for my own purposes if nothing else. There are some topics that Django (understandably) doesn't get into, but also some rough edges that could use smoothing over (in my opinion).

You might be interested in taking a look at PullApprove (https://pullapprove.com/) -- basically you put a YAML in your repo that defines what code review looks like for your team (who, when, how many need to approve, etc. -- http://docs.pullapprove.com/). Approval/rejection can then be triggered by PR comments and it uses the status API so you know when the PR has passed review.

Code review "rules" can get pretty complicated since everyone works a little differently...not sure if GitHub will ever try to tackle that or not but we've got a lot of customers who are happy with how PullApprove fills the gap.

Awesome! I actually contemplated going that route as well, but obviously decided not to. Cool use for Lambda though. Do you find that people are using that feature?

Thanks for the detail! My personal experience is generally in strategy 1 as you outlined, especially in being that lead person. I know a lot of people like the appeal of strategy 2 (myself included) but like you mentioned, there's a number of ways that critical code can fall through the cracks. It's great for a general "good work, I like the way you did that" or "what about doing it like this" kind of review but beyond that doesn't provide many safeguards. That being said, I've heard a number of complaints about the organizational/cultural aspect of strategy 1.

In full disclosure, part of the reason I'm asking is to do some research for a product of mine: https://pullapprove.com. Currently I feel as though it serves as a fairly flexible platform that can accommodate either (or both) of the strategies in various ways, and just want to make sure things are headed in the right direction. As you mentioned, the process for choosing reviewers could be handled several different ways and I wonder if there's room for some tools to assist in that. An interesting one to me (which PullApprove doesn't yet support) is automatically choosing reviewers based on git blame information (https://github.com/facebook/mention-bot) -- which could get at your last point.

I feel like there's a ton of value in doing code review that, I personally, drastically underestimated for a long time. I'm interested to hear more about the kinds of problems different groups have with code review and trying to figure out if/where/how a tool like PullApprove can alleviate some of the pain and make it an easier process to adopt.

Sorry if you got an email that felt unsolicited. The only email that was sent was to some users of Sibbell (https://sibbell.com) which is another GitHub-related service we built. We really weren't trying to spam people, but thought they might have a genuine interest in another tool based on GitHub.

Gotcha, so if three users have write access then when a PR is opened by one of them, one of the other 2 users has to approve it?

If your scenario only has two users (you and one other person) then this flow can already be accomplished (the two are both reviewers, and you set approval required by "everyone" -- so you approve your own PR and then the other user has to also). If you've got more than two users, that's something we'll have to add but it sounds like it's worth doing!

Forked repos is absolutely one way to accomplish preventing merge privileges (since it removes all push access). At least for us, our workflow and tooling is much simpler if all developers work on the same repository.

Even in the case of forked repos, I think PullApprove can still have some benefits. Ex. Someone forks and makes a pull request, but it needs to be reviewed by two key developers before it should be merged. PullApprove could help to formalize that process, requiring that both of those developers mark it as "approved"...

Does that example apply to your workflow? Or is there anything else about your process that a service like PullApprove could formalize? I'm looking forward to hearing more about how other teams deal with some of these issues...

Thanks for the feedback, I totally agree. I'll see if we can work something up that shows the whole flow -- from creating a pull request, to approving via PullApprove, to merging.