1. 5

    free-as-in-beer unless you make more than $1m/yr, free-as-in-speech for everyone seems like a really good license to me. if anyone reading this thinks it’s a bad idea, could you explain the drawbacks?

    1. 3

      It doesn’t seem like a terrible idea, especially from the perspective of the authors, in the sense of “how do we monetize this code without creating barriers to entry and access”.

      However it does create a few additional items of overhead:

      • For users of the software, they and their finance teams now have additional planning and compliance overhead to factor in (roughly: if and when we are above this revenue threshold, we need to arrange payment and reporting of this line item and include that in our financial modeling)
      • For users and potential users, the presence of the threshold may add concern that the pricing and/or threshold could change in future
      • For the authors of the software, they may now need additional services and staffing to accept payments and chase down businesses of the software who they want to seek payment from

      Those are currently the reality of doing technology business in many situations. And as costs they are probably generally smaller than the overall value generated.

    1. 2

      Please feel free to borrow, re-use and remix anything from RecipeRadar that could be of help, bearing in mind the copyleft license terms. Software dietary diagnostics is something I’d really like to use and develop as well, so good luck - I’ll follow along, and contribute back if possible.

      1. 6

        Supporting dietary restrictions (kosher/halal, vegetarian, vegan, lactose intolerant, gluten intolerant) would help a heck of a lot of people.

        1. 2

          Even better would be ingredient substitutes, or optional ingredients (substitute of nothing), like removing the wine from tiramisu.

          1. 2

            Agreed; it should be possible to resolve a recipe to a normal form (in the sense of URL normalization, not in the sense of database normalization), and then re-expand that normal form to include variations, so that if someone has ingredient X and has an aversion to ingredient Y then recipe Z (that contains ingredient Y and not ingredient X, in normal form) can still be returned as a search result as long as suitable substitutions can be applied.

        1. 3

          neato! you may want to combine e.g. zucchini and courgette.

          1. 1

            Thanks - yep, synonyms and/or translations would be really good to handle. No decisions yet on how best to model that (per-language? simple global replacements? do queries accept any version of the ingredient name?).

          1. 2

            As a UI idea the ability to click on a grey ingredient in a suggested recipe and mark it as either “nearby” or “not available”. You can also mark an ingredient as both nearby and not available at the moment.

            1. 1

              Good suggestion - “inventory management”. How would dragging-and-dropping ingredients into an inventory and/or shopping list sound?

            1. 3

              Looks pretty neat. Seeing some oddities where it will pick out the word “ground” and ignore the rest of the ingredient. For example, if I tell it I have cheddar cheese and no sausage, it suggests a recipe involving ground sausage. Based on the highlighting, it thinks “Ground” is an ingredient and ignores the fact it’s sausage.

              1. 3

                Thanks!

                That’s puzzling, ground is explicitly called out as something that isn’t a stopword, but also shouldn’t be a valid product (ingredient) name.

                Now filed on GitHub as openculinary/knowledge-graph#64 if you’d like to follow resolution.

              1. 5

                Interesting. What’s the data model? Would it be possible to exclude groups of foods?

                For eg., I wanted to find all recipes involving ground meat, cream cheese and cream - but without plant foods (I don’t tolerate most of them). I had to manually list the individual plant foods (see example) - but it would be great if you can exclude the entire group en masse.

                1. 7

                  The data model is quite naive at the moment: each recipe contains multiple ingredients, each ingredient has a quantity and exactly one product, and a product (such as “ground beef”) has a few boolean properties (vegetarian, vegan, dairy, …).

                  Matching products against a food/nutrition ontology would be a step towards what you’re looking for; there is a notion of hierarchy between products (“soft tofu” is-a “tofu”) but it isn’t particularly well specified, and it doesn’t handle any other types of linkage or non-product concepts (such as “plant”).