[tony]

I think this makes sense. Ideas:

- Showcase your reciprocal contributions you make back to django community packages (e.g. Jazzband packages).

- Release a permissively licensed django package (with no catches) under your GH's org and brand name and have it take off. (e.g. django-forge-admin)

- The holy grail would be contributions to django itself. Example: Adding more CSS variables in django admin to font-size and font-family. Add rem, %, calc, flex, etc.

- Early startups funding: $5,000 for MVPs up into 6 figures. Your price point could be a bit higher. Email early founders and see what their reaction is. Use that feedback to tailor a business-friendly license to address the concerns of people with decision making powers. Commenters opinions matter, but they're not necessarily your clientele.

- Strike custom deals to make the sale.

- Add on custom development hours and add a clause to incorporate the work back into your product for reuse.

- Expect to be reaching out to founders often, using cold email introductions, both for advice, but also to show you're flexible. Be willing to hop on a zoom, demo it, etc.

- Find early startups to use your framework for testimonials and social proofing.

- I've personally set these up before many times in django at previous places. It takes weeks of effort to bootstrap, especially if you factor in billing. No it's not 8 hours. It's weeks of effort.

My only doubt is, I think you may ultimately make more money striking big deals to do development work. What's more efficient, a $100-$150k deal with one customer or being on the hook for 100 customers?

[davegaeddert]

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.

[systemvoltage]

I wonder if this creates more problems than it solves.

For example, imagine there are a bunch of startups trying their hardest to shoe-horn contributions in Django main branch. It puts a lot of load on core developers at Django to reject frivolous features and unnecessary bloat.

The end effect would be that we get features no one asks for and Django becomes even more bloated.

Django is already a very popular framework and has many contributors.

[tony]

I wouldn't limit django patches to just being new features. Ample room for incremental improvements.

There are some parts of django core that are stable, but fundamentally broke for non-trivial apps. Let's just take /admin:

- Can inline admin models be paginated? Searched? Both? Asynchronously?

- Use autocomplete_fields by default via ID/PK lookup / when `search_fields` exist. Right now related fields will load the whole table into a <select> box. This is an absurd default.

Other opportunities that'd be universal:

- Integrate channels into admin

- AJAX form validation

- Revision history that includes actual values / diffs / undo

[systemvoltage]

Good response, I agree that these changes would benefit Django.

[davegaeddert]

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.