This number ("one in three") is really ambiguous[0], as I haven't seen them state what they consider a farm to be. It could be the Ag Census data (~2.2 million farms), or along some subset (say non-family farms at ~90 thousand), or some farm type (I believe I've previously seen them say "row crop farms").
I'm sure it seems like an impressive stat to throw out there, but it's a lot like saying they're offering a million shares of options to new employees; without the total number of shares we don't know what that means.
Happy to clear that up. We don't count hobby farms as they aren't our typical users. We are focusing on the ~280k row crop farms in the US of which over 90k have started using FarmLogs. Most of our customers have between 600 and 10k acres of land each.
Thank you. I think that's a fair representation of your marketshare. When you say 'started', what exactly do you mean? Used trials versions, previously engaged, or full time active members?
Slightly off-topic but I am dumbstruck by the size of US farms. Where I live it's common for farmers to manage 10 hectares fields and these are considered big fields.
Every year we take on workmen/students normally from outside Australia, who need to spend time actually working on a farm to finish their agricultural degrees or similar. It's always interesting to see their reactions after they finish telling us about their "big" farms back home, when they realise we can fit their entire farm + change into a single paddock here.
I know in Canada, for the longest time (At least since the 1940s), a large family farm was a 1/2 section - or 320 acres . But nowadays, a large family farm ranges all the way up to 4 sections (1280 acres). 8x improvement in 70 years.
I suspect I'm missing something subtle here - are you proposing that a single family, (with a bit of extra help during harvest), being able to farm 8 times more land, isn't a good thing? And, based on what I've seen of the tractors these days (air conditioners, enclosed cabs, hell, little beer cooler to boot!) - the work, while hard, is also somewhat less backbreaking than it would have been in the 1940s as well.
No subtleties; "more" doesn't equal "better". It can, in some ways, but there's no generalized way to make them mean the same thing--it depends entirely on judging criteria for both.
E.g., "good" in what way? That there's less manual labor now? (Not a function of having more land.) "Good" in the sense that ag companies tend to make more money on larger farms? "Good" in the sense that yields are (generally) consistently up? (Also not related to having more land.)
To make "good" meaningful you must strictly define what's "good", realizing that there are almost always other (possibly contradictory) criteria, and that what might be "good" in one sense may be "bad" in another.
In any case, my point was that "improvement" has a solely positive connotation. You could have said "8x improvement in farmed acreage", which sort-of implies an increase in acreage is "good", but why not just be accurate in the first place, and call it precisely what it is, which is an increase in average acreage?
Ah, I see what you are getting at. I guess, you would also say, that storage density hasn't improved 1000x in the last 20 years, but "increased". And that the rate of death from automobile accidents per 1 million miles traveled since 1950 hasn't improved, but, "decreased".
I guess I wanted to combine both an objective and subjective assessment in a single word, which admittedly while not precisely accurate, got across my meaning.
I was actually hoping you were going to give me a traditional marxist response that we should not seek to decrease the amount of labor per unit of production, (that decreasing the amount of work per bushel of wheat is not an improvement) - I had an answer for that!
I actually would say increased/decreased in those situations, but I think most people (myself included) would also say those were improvements--they don't come with any significant costs, whereas large-scale ag does have associated, often negative, side-effects.
Tragically for our "argument" I believe doing less work for the same output is a good thing, at least in general. But even that has associated costs that aren't always "good" given current conditions :/
The question isn't how big the farms are. The question is how are those who are "using" Farmlogs, using FarmLogs. Are they active? Are they using just the basic functionality, or are they using more advanced features?
I'm still involved in farming, and the guys I know who are "using" it, just are using the basic functionality.
Unless they have partnerships, FarmLogs is going to have a difficult time competing with Deere, Case/IH, other equipment manufacturers who are developing their own built-in products with similar feature sets and deeper pockets. Not to mention the local cooperative monopolies, seed companies, etc who are also in the game.
Yeah, as a former farmer I'm a little bit skeptical. Last I checked the vast majority of farms out there aren't large operations, but incredibly small family-owned "hobby farms" or market gardens (what most of us would identify as a small vegetable farm).
Having known many farmers over the years, I can only think of one who would really have a use for this. The rest would probably just dismiss it without much thought.
In Australia we've seen nothing but farm getting larger over the last 15-20 years. It's also interesting to compare the size of farm he's talking about to what we have here. On our property we have single fields 2x the size of what they consider a small farm (600acres).
The economics of farming certainly do seem different in the US. Is land really that much cheaper/higher-yielding? Is that why hobby farms in the US can break-even on such small areas? Or is the difference just in the subsidies they get? Or is high/consistent-yielding farmland simply locked away from smaller operators in Australia nowadays? A combination of everything?
Land may be cheaper, but probably not higher yielding. When your buying land your essentially buying rainfall. We could easily find and buy xx'000 acres of really cheap land, but it if only gets 200-300mm of rain every year, your not going to be seeing serious yields. The other thing to remember is that irrigation is impossible for a lot of West Australian farmland.
What crops do you grow? Growing up near the Salinas Valley, I always associated row crops with produce and not grains, so a <600 acre "row crop" farm can generate pretty massive revenue.
This number of course applies to only their targeted market, farms of a certain size and then only those growing two or three specific crops, but that's a long ass headline.
Also worth noting that the Ag Census likely overstates the number of farms in the US, so it's not out of line for FarmLogs to come up with their own number for their target market.
A lot of people who really love it, and some people who dislike that their satellite-based rainfall gauge is just an estimate? Am I missing something here? Seems more positive then just "mixed reviews" would imply to me.
There are more than 2 million "farms" in the U.S. Snag "One in Three" of those as paying customers (at nearly $1k/year) and it's very unlikely you'd need to use TechCrunch as a marketing and PR platform.
I'd like to get a more comprehensive look at FarmLogs, hopefully they'll be more available in Australia soon. Although until then, after just browsing through the interface, I'd like to make a few points. I should point out I'm from a broad-acre farm of > 10'000acres, and we have single fields nearly 2.5x bigger than the 600acre size mentioned..
There's still seems to be to much of a focus on farmers having to manually enter data. Our machinery already records everything that happens in the paddock, there's no reason why we should have to sit down and manually enter everything we do. Farmlogs should connect to whichever machinery provider we use's API, and pull all the data straight from the machine. It's now possible to do that in real time, and it opens up far more interesting opportunities, (for example optimising variable rate maps in real time) as we can also push data back to the machines.
How do I connect and use my local weather station data within FarmLogs? One limitation of our current yield prediction software is that it's weather data feed comes from a BOM station nearly 30km away, that isn't nearly good enough, so we're seeing a transition to on farm weather stations. Ultimately we need to be able to collect weather info on a field by field basis, not only for crop modelling and yield prediction, but to better optimise harvesting/swathing schedules, and make more effective N applications (we can create better application maps based on the yield models + predicted weather).
Can I import my all my soil data? We've had extensive EM38 mapping, radio-metrics and soil testing done over the farm to better calibrate our yield models, and improve nutrient application, how do I put that data into FarmLogs? If I can, how do you use it? Can you generate my VR maps based on soil data + predicted weather information?
I'm also seeing some features that most farmers I know will never use. We don't need "another" calendar. We don't need to keep a record of all the grain we have stored in silos, or upload information about every piece of machinery we have on farm. What benefit does that give us? It seems like your almost trying to gameify farming with all the graphics..
I think tools like FarmLogs need to move away from just data collection/consolidation and much more towards yield prediction/modelling, and giving recommendations/optimising nutrient applications. We spend more than $500'000 a year on fert/chemicals, so if you can help me make a more precise variable rate map and save me 10% of that figure, thats something I'm going to use. Even if your charging me $5000/10'000/x'000 a year for it.
That's an excellent assessment, and we're actively developing our product in that direction. You can already upload your machine data files to create yield maps in FarmLogs, and this year we released the Flow, a hardware device that passively listens on the CANBus to create yield maps in real time on a FarmLogs account. We will be giving the same treatment to as-applied and as-planted data as well.
There are lot of challenges in this area. There are no open data standards and probably most farms in our target market do not have access to that type of equipment. Or if they do, they don't have great records of it. For them we offer a sort of progressive enhancement. We've licensed five years worth of satellite imagery to give us reasonable baselines of precision field performance history. And while we also need management decisions for our models, we can make use of manually entered data as well as machine generated precision data.
Over the summer, we piloted some products built from these models with great results, and will be announcing them soon. We're really excited about it.
I wonder what their stack is. I can't readily determine that, which might just be a function of working too hard today. I don't have time to search for the info. (I was specifically wondering if they use Hadoop.)
They did a StackShare blog post [0] and podcast in February talking about their stack, and it makes for a pretty good read. About Hadoop specifically, it doesn't show up on their StackShare page [1] anywhere.
They use Clojure and I believe ClojureScript on the frontend. (I'm not sure about Hadoop, when I had spoken with their devs before this didn't come up--but since they're already on the JVM such tools are a natural fit.)
They're one of the many success stories in the community of startups who have chosen Clojure as their primary weapon. (See also: Climate Corp, now owned by Monsanto.)
Lisp is having its victories, here and there, but notably in meaningful and economically real ways.
Edit: They DO NOT use ClojureScript, sadly. Unlike say, CircleCI or Prismatic, who both have very compelling stories with regard to using Clojure from the front to the backend.
I'm relatively new so I can't speak to the original rationale, but right now it fits our needs. I'd love to do some ClojureScript (or just ES2015 through Babel), but right now we're focusing on building stuff instead of playing with languages :)
> ...but right now we're focusing on building stuff instead of playing with languages
Which is exactly what's so compelling with regard to ClojureScript and say Om or any one of the React wrappers out there: you guys already use Clojure and ClojureScript and its libraries are incredibly pragmatic and designed for "real work". CoffeeScript would seem more like language play than ClojureScript, but of course I'm speaking as an outsider. :)
Also if you haven't already, take a look at David Nolen's recent talk on Om Next[1]. Personally if I were using Clojure on the backend, I'd be pushing hard for it on the frontend too.
Personally, I'm not a big fan of CoffeeScript and it's something I brought up when I started, but at the end of the day you can write good and bad code in any language. I've watched that talk and found it really compelling, but I'd sooner get rid of Backbone than change languages. I've been following Dan Abramov's stuff pretty closely, the refinements in Redux seem to take the best parts of Om and Flux.
Just want to point out that I personally don't think Babel/ES6/ES2015 is ready for production yet. I just wrote a small library with it and ran into several hiccups with continuous integration, which was fixed by specifying a specific node and npm version of which both were I think just the default linux packages. If I ran into problems scratching the surface I can only imagine what headaches a deeper usage could cause. I realize this is a bit off topic, and would be interested to hear from someone whose done it, but I wouldn't want anyone to jump in head first and hit the bottom of the pool..
Can you explain why you feel it's a shame? We write a lot of Clojure at FarmLogs but there is certainly a time and a place for it.
We handle iOS push notifications with Ruby, a lot of data and image processing with Python, and even run .NET/Mono in a few areas. Our stack is very diverse and we do a really great job considering what the best technology for a particular problem might be.
Clojurescript is certainly interesting, but I wouldn't consider it a shame that our front-end isn't built with it. I love programming but at the end of the day you gotta remember that code is really just a means to an end.
It seems pretty obvious: You're giving up using one (great) language, which you already know, end-to-end. I can't think of a good reason to do this, especially when an entire UI revolution is being led, right now, in ClojureScript.
What possible reasons could there be for giving that up?
Anecdotal but whenever I see a lot of diversity in a stack it usually means there are a lot of different preferences on the development team, or that the stack was developed over a longer period of time with many members (and their preferences) coming and going. While yea, any SE should be able to pick up and run with any language, it is quite possible their team no longer has the same experience in Clojure or alternatively has way more experience in their current front runner (Python, Ruby, whatever). If that's the case I think it's quite reasonable (at least from a business stand point) to use alternate tools.
Coffescript is a powerful language meant for beginners, but you really need some experience with it to understand its quirks and that a lot of it should be avoided.
So basically, it's JavaScript with a compile step that doesn't do static analysis.
But back in 2012 when the first lines of FarmLogs were written, it was pretty cool. And that's a lesson in itself about why it really doesn't matter what stack you use.
I can't remember seeing them looking for anything other than Postgres, which seems less like "big data" than... regular data. Maybe they don't put their heavy duty stuff in job listings?
Farming is often in the raster world as opposed to the line/row/text/vector world. Some of things in Postgres might be huge. Farm data sets could easily be only adding a few thousand rows a day, but the objects associated with each row could be several gigabytes. Meaning that the size of the data is bigger than so-called "big data" but the row analysis tool set looks more like your "regular data." However, there's a lot that goes into the raster analysis that's a whole different beast.
Huh. Thanks for taking the time to outline this, I don't know why it never occurred to me. I have to admit, I'm unfamiliar with "rasters" in the way you seem to be referencing them. It sounds, though, like the relational bits of the DB are really being used more as a file system than a database, if there are even really distinctions in the first place. If "a couple thousand rows" are basically being used as a metadata store for the rasters, is that an unusual use of the database, or is everybody doing this and I just never had enough data to care?
You'd be surprised at what you can do with PostgreSQL. Also, there are also some really exciting new ways to handle data pipelines using Docker and tiny applications (see Pachyderm) as opposed to classic approaches like HDFS and Hadoop.
Not everything needs to be in an enterprise grade multi-node C* cluster to be big data!
I did see a job listing that noted "familiarity with stuff like Hadoop" (paraphrasing). So it seemed to cast doubt on them using Hadoop, but it neither served to confirm nor deny.
1) The statistic is utter baloney 2) see "The Climate Corporation" for a real version of this. Founded 2006 by ex-Googlers, real tech, acquired by Monsanto for $1.1B, and best creepy-corp name ever.
I have been silently following FarmLogs for a long time, it is wonderful to see technology being merged with nature. I often thought about what it would be like working for them but the problem is that I'm from mid europe (Hungary).
The majority of our country is farmland, we even have a somewhat similar and quite successful startup here, SmartVineyard who do similar stuff but specifically for grapes. Is it possible for non-US developers to join FarmLogs without relocating?
Could you explain what FarmLogs does to someone that a) grew up on a deciduous fruit farm with some cattle, b) studied electronic engineering with computer science, c) works in embedded systems and d) doesn't come from the US?
I'm sure it seems like an impressive stat to throw out there, but it's a lot like saying they're offering a million shares of options to new employees; without the total number of shares we don't know what that means.
[0] http://www.epa.gov/agriculture/ag101/demographics.html