If Soylent is supposed to be the software of food


#1

Someone commented on our latest Youtube vid about 1.4, and brought up a truly excellent point that I wish to relay and add to here.

Soylent is obviously being versioned like software, and is clearly being developed by (and even for) software engineer types. So why doesn’t it also get released like software?

I’m sure there would be all sorts of logistical challenges to this, but imagine if there was a “stable branch” (that would probably be 1.3 at this point), a “current branch” (1.4) and a “development branch” (possibly available in limited quantities and only for those who really want to be on the bleeding edge). You could choose what you wanted to order (maybe dev branch is only available to existing customers?) and subscribe to. For instance we would have a “stable branch subscription” and so would still be on 1.3 until and unless we chose to order some 1.4 to see if we like it.

Branches would not change until there was an overwhelming consensus from the community that the latest branch was worthy of being called “stable”. So for instance, 1.0 would have been stable (such as it can be for a first release), and 1.1 would have been latest. Consensus in the community was not good on 1.1, so 1.2 would have become latest, and 1.0 would have stayed stable. Consensus on 1.2 was certainly more positive than 1.1 and 1.0 and in fact I don’t think anyone who was fine with 1.0, had issue with 1.2. So 1.2 would have become the stable branch as soon as 1.3 came out as the new latest release. 1.3 proved itself very quickly and would have become the new stable branch and 1.4 would have been latest. Those of us for whom 1.4 is not working, wouldn’t have to worry about a thing since we’d be staying on 1.3. When 1.5 comes out it would be the latest and 1.3 would remain stable until and unless 1.5 proved itself within the community.

If this is truly going to be the software of food, I think it needs to really, truly, be handled like it… for all our sakes.

Thoughts?


#2

Nice idea, but very costly. Maintaining physical supplies for multiple versions would make the price skyrocket.


#3

Yeah that was exactly the reason I figured it’s not being done that way. Thought I should at least propose it anyway… sure would be great.


#4

Once they get their supply and production to the point where there is no back log I would like to see this. Assuming that offering this doesn’t cause a backlog itself.


#5

As a fellow software engineer, I love this idea.

But I agree – it is pretty impractical at this point. But someday once Soylent really gets going and gets the scale it needs, this is likely very possible to do.


#6

Yeah, this is an unfair comparison simply because you don’t have to grow software. Or manufacture it.

But also, and this is only half-facetious, but in the knowledge that most software is absolute shit, we should probably be wary of making Soylent like software. :-p


#7

Not to mention the chance for bugs


#8

I always imagine Rob & Pals have developed such an advanced form of soylent for themselves, it’s completely reformed their physical being and they’ve since transcended beyond the realm of mere mortals.

But that’s just silly!

…right?


#9

If you really want it to be handled like software:

  1. Initial development
  2. Beta testing
  3. User feedback > tweak design > repeat

That’s where we are now. Next:

  1. Garner much more widespread interest
  2. Larger company buys it out
  3. Developers push their own visions upon the users, regardless of feedback etc.

I’m out. :expressionless:


#10

Sigh. Indeed, that is usually how it goes… and personally I expect that Soylent will eventually see a buyout that the VCs will want to accept. Time will tell…


#11

You usually don’t put software into your mouth and stomach though.

Soylent already test their new formulas with a given number of people, right? Are you just saying they should test new formulas with more people before updating their shipping formula?


#12

lol, Soylent open beta. The bugtracker would look something like this:

id      desc

1001    farts
1002    farts
1003    farts
1004    farts
1005    farts
1006    farts

#13

True enough. And you usually don’t version number food either.

[quote=“pauldwaite, post:11, topic:19754, full:true”]Soylent already test their new formulas with a given number of people, right? Are you just saying they should test new formulas with more people before updating their shipping formula?
[/quote]

We actually don’t know how they test or with how many people under what circumstances. I’d love to hear more about that process actually.

All I was suggesting was what is already pretty typical in the open source software world - which Soylent is clearly modeled after. It’s really quite impractical with something that requires so much physical manufacturing of course, but I still think it would be really awesome for the customer.


#14

I keep seeing this here. But I don’t understand. There are lots of companies that produce more than one SKU and yet manage to keep costs reasonable. In fact, there are very few companies that have only one SKU in their factory.

Costs certainly wouldn’t “skyrocket”.

Eve


#15

I think the idea here is that each formulation would require potentially a completely different manufacturing line, due to the wildly different ingredients and processes in certain formulations (1.3 vs. 1.4 for example), and that at least for now anyway, it just wouldn’t be practical for Rosa Labs to maintain multiple totally separate manufacturing lines, ingredient suppliers, processing methods, etc.


#16

Except that I’ve worked in food manufacturing and it’s not like that. You have a mixer and clean it between batches. Then you put the next product in the mixer (more of the same or different depending on the quota). It’s not totally separate lines. In fact, it’s less complicated than what the competitors are doing routinely.

Eve


#17

Hmmmm well then maybe they could do this sooner than later. I’d sure love to see it.


#18

The product would have to be a lot more refined to make that work. There’d have to be a useful and well-defined definition of what Soylent A is before you could fork it and introduce a Soylent B that runs concurrently. It wouldn’t be like “Plain Soylent!” and “Sports Soylent!”, because Soylent customers expect a precise product with strict consistency. They wouldn’t (correction: [I]shouldn’t [/I]) be able to fundamentally change what Plain Soylent is, the way 1.3 turned into 1.4. They’d need to really nail it so that such changes in the future are released as Soylent C and Soylent D, unless the change is a fix to a critical error.

This comes from The Software Bible, a fantasy book existing only in my mind, where the phrase " well-defined" is repeated approximately one million times.


#19

I hope iterating incessantly like software isn’t a part of their long term strategy. When people make Soylent a staple in their diet, constant changes to the formula can cause serious disruptions to their lives. Software is digital, and users can often keep older versions running if need be. This is not the case with a food product.

I also think RL has to be careful to avoid developing tunnel vision. Constant iteration based on latest research is going to cause their formula to bounce around with the research. I think it’s great that they want to improve the formula as we learn more about nutrition, but I think they need to hit a base product that’s “good enough” and stick with it until more significant and conclusive nutrition information becomes available. There are already similar products popping up that have achieved what some perceive as a good enough base, to which they’re creating a variety of blends and flavors.

If RL is on a never ending quest for the perfect formula, the constant iteration is likely to throw people off when a version that’s unappealing to them hits. They’ll also never attain a consistent base from which to create various blends and flavors. This type of iteration may be good to nail down a base, but I do hope it doesn’t continue indefinitely. They could work on the R&D behind the scenes, and then only release a new version when they have something significant and stable.

I do think getting the oil in powdered form was a necessary step for widespread adoption, but I do hope they nail down a base soon that they can stick with for some time.


#20

Speak for yourself. I’m crunching on some open source MPEG encoders right now, and aside from the profuse gum bleeding, it’s working out great.