> In conversation with our investors and the board, we believed that the best way forward was to shut down the company, as it was clear that an 8 year old product with no traction was not going to attract new investment. In our discussions, we agreed that continuity of the product was in the best interest of the users and the community (and of both founders and investors, who do not enjoy being blamed for shutting down tools they can no longer afford to run), and we agreed that this could best be achieved by selling it to the employees.
Any other examples of that? I'm particularly interested in that for this kind of software product.
> Any other examples of that? I'm particularly interested in that for this kind of software product.
As far as I know, this pattern is not uncommon among traditional businesses. King Arthur Flour Company is the largest one that comes to my mind, but on a local level; grocery stores, restaurants, mechanic shops, plumbing businesses, etc very often "change ownership" this way.
In software, it's pretty common in informal OSS project to transition ownership this way when the original owner/author loses interest or is otherwise unable to maintain the project.
In terms of commercial sortware, something like SketchUp comes to mind, though it's not exact path. It was a startup, acquired by Google, then spun off again with its employees
They sold the company because they didn't see a future of growth, and the employees were notified of the sale of the company just a couple of days before.
The new owner then fired most of the employees, it's an Italian "tech company" (Bending Spoons) which already bough companies like Evernote, Brightcove or WeTransfer, and has nothing to do with the outdoors.
Komoot was the best outdoor-community app in Germany and very popular in Europe, made mostly for hiking and biking.
You can see in this really moving video, made by the employees after they got fired, how much they loved their team:
That seems like an exemplary way to handle a failed rocketship that nevertheless produced something useful to certain customers. Big thumbs up to those who made it happen.
> an 8 year old product with no traction ... and we agreed that this could best be achieved by selling it to the employees.
Can someone with more business sense than me explain this? Why would employees want to buy an 8 year old product with no traction? At face value this sounds like a "holding the bag" scenario, not?
They're not buying the product. They're buying the company so they can pivot and implement their vision.
Basically, the investors lost interest but the team is passionate and see a path to success. They won't be maintaining the old product, they're going in new direction.
Have you ever been to a great restaurant that happened to be on the wrong corner? Or been at a company where one change in execution made or broke the company? My guess: the founder lost interest but the employees still believed in the [impressive] tech. Because of the lack of traction: the cost of the tech wasn't prohibitive for the employees?
Only if they are buying it for what the investors had already put into it, which is not likely. They most likely discussed how much the investors values physical assets and trademarks the company holds (like how much they are likely to get back in a bankruptcy) plus whatever makes a deal fair and maintain a happy cordial relationship with said investors for future endeavors.
Was previously "source available" but is now Apache 2. Good choice IMHO!
Also looks like it required their cloud setup to run, you previously couldn't run it locally. Now you can, so I think it's moving in the right direction!
I guess darklang was too far ahead in their thinking in some areas and choose the wrong path for other. I really liked the deployless idea, but would have loved in even more on-premise. No way to get the data to stay in Europe.
Making hard connections between the editor and the lang was interesting also. Seems like they have moved away from that.
Hope there is a easy way to set it up locally, i was really intrigued when they first launched
Yes, the next version will be able to set up locally - you'll be able to install a single Darklang binary and run any darklang program without any further steps. See the explanations on https://darklang.com homepage.
The issue with the hard connection between the editor and language is that each change becomes a massive undertaking. Making a language improvement was much much much simpler than making the editor change to support it.
It was a bit hard to understand what is coming and what deprecated. As soon as i went into documentation I was send to "darklang classic".
How are the deployless senario now? Where you first serve only yourself then your team, then beta, then everyone... Or something similar to that. I really liked how that story was told and how much complexity it removed
> We're now building Darklang to run locally as a CLI
Dark's structure editor looked promising. I'm really disappointed that the project moved away from this because a hosted visual programming environment felt like the whole value proposition in the first place.
Was it the pivot to AI that killed this, was it issues with the design of the language or was the structure editor just not as useful as it seemed?
I've been following Dark since its inception and found the idea inspiring. I'm happy about today's announcements and look forward to seeing what comes next.
On a personal note, I'm curious around the move to F# as the implementing language and wonder if there will be ports to other languages now that it's open source.
I was following this since it started. I dislike modern code experiences because of many of the things, especially devops, they fixed. But it being not fully open source always held us back and we developed our own solution with common lisp and some typing sauce that keeps us free from all the modern dev and deploy crap. Everything runs easily on your laptop as well as in the cloud without any difference and, outside running a simple script to set up some vps or cloud hoster. Happy darklang went apache license and looking forward how their deployment looks now as not self hosting is just never ever an option: all companies become frauds in the end so we need to be able to move any time.
Epic's new language, Verse, is also well poised for the "immutable" future of AI agent coding. Verse uses an effects system, and the <transacts> effect is required for any function to change a mutable variable. These changes are transactional, so if you have a failure in your <transacts> function, any changes it made are rolled back at exit. Code still looks imperative-ish, but it's both safe and pure.
(Or, it works something like this. The documentation is hard to understand; I'm working mostly on memory from their keynote)
I’ve watched the demo video, and gone through the discussion here but I’m still not sure what the core use case for Darklang is. It feels like I'm missing something obvious.
Can someone explain the practical problems this is solving better than existing tools like Python or other backend stacks?
Also, genuine question: how was the team able to work on this for 2+ years without revenue or traction? Was there still funding left, or was this a side project during that time?
The theory is that because Dark offers a nice interactive environment when you have a request come in you can inspect the data, "fix up" your code, rerun it quite smoothly. Completely removing the deploy question. Really good for glue projects IMO. Think stuff like google scripts (though google scripts are much more miserable to ues)
Many moons ago I had tried to play with Dark and unfortunately the surrounding language stuff really didn't work out for me though. I really liked the concept but ultimately I think I would have preferred if they had just built out the environment on some other language.
Even just lua would work decently well for their use cases, if paired with a good "standard" library.
The UI was fun to use, in any case.
EDIT: to be clear I'm a bit of a type weenie but for the stuff Dark could be good with you really sometimes just want to look at the JSON and poke at it, and your type systems aren't going to be helping you _that much_
I don't understand. Hot code reloading on my dev laptop gets me this kind of quick iteration when I'm solving problems. But why do I want that in production?
Readit News
> In conversation with our investors and the board, we believed that the best way forward was to shut down the company, as it was clear that an 8 year old product with no traction was not going to attract new investment. In our discussions, we agreed that continuity of the product was in the best interest of the users and the community (and of both founders and investors, who do not enjoy being blamed for shutting down tools they can no longer afford to run), and we agreed that this could best be achieved by selling it to the employees.
Any other examples of that? I'm particularly interested in that for this kind of software product.
As far as I know, this pattern is not uncommon among traditional businesses. King Arthur Flour Company is the largest one that comes to my mind, but on a local level; grocery stores, restaurants, mechanic shops, plumbing businesses, etc very often "change ownership" this way.
In software, it's pretty common in informal OSS project to transition ownership this way when the original owner/author loses interest or is otherwise unable to maintain the project.
In terms of commercial sortware, something like SketchUp comes to mind, though it's not exact path. It was a startup, acquired by Google, then spun off again with its employees
They sold the company because they didn't see a future of growth, and the employees were notified of the sale of the company just a couple of days before.
The new owner then fired most of the employees, it's an Italian "tech company" (Bending Spoons) which already bough companies like Evernote, Brightcove or WeTransfer, and has nothing to do with the outdoors.
Komoot was the best outdoor-community app in Germany and very popular in Europe, made mostly for hiking and biking.
You can see in this really moving video, made by the employees after they got fired, how much they loved their team:
https://www.youtube.com/watch?v=qLJkK4Wn1HI
Can someone with more business sense than me explain this? Why would employees want to buy an 8 year old product with no traction? At face value this sounds like a "holding the bag" scenario, not?
Basically, the investors lost interest but the team is passionate and see a path to success. They won't be maintaining the old product, they're going in new direction.
Only if they are buying it for what the investors had already put into it, which is not likely. They most likely discussed how much the investors values physical assets and trademarks the company holds (like how much they are likely to get back in a bankruptcy) plus whatever makes a deal fair and maintain a happy cordial relationship with said investors for future endeavors.
Deleted Comment
Deleted Comment
Also looks like it required their cloud setup to run, you previously couldn't run it locally. Now you can, so I think it's moving in the right direction!
Making hard connections between the editor and the lang was interesting also. Seems like they have moved away from that.
Hope there is a easy way to set it up locally, i was really intrigued when they first launched
The issue with the hard connection between the editor and language is that each change becomes a massive undertaking. Making a language improvement was much much much simpler than making the editor change to support it.
How are the deployless senario now? Where you first serve only yourself then your team, then beta, then everyone... Or something similar to that. I really liked how that story was told and how much complexity it removed
Dark's structure editor looked promising. I'm really disappointed that the project moved away from this because a hosted visual programming environment felt like the whole value proposition in the first place.
Was it the pivot to AI that killed this, was it issues with the design of the language or was the structure editor just not as useful as it seemed?
On a personal note, I'm curious around the move to F# as the implementing language and wonder if there will be ports to other languages now that it's open source.
(Or, it works something like this. The documentation is hard to understand; I'm working mostly on memory from their keynote)
Can someone explain the practical problems this is solving better than existing tools like Python or other backend stacks?
Also, genuine question: how was the team able to work on this for 2+ years without revenue or traction? Was there still funding left, or was this a side project during that time?
Many moons ago I had tried to play with Dark and unfortunately the surrounding language stuff really didn't work out for me though. I really liked the concept but ultimately I think I would have preferred if they had just built out the environment on some other language.
Even just lua would work decently well for their use cases, if paired with a good "standard" library.
The UI was fun to use, in any case.
EDIT: to be clear I'm a bit of a type weenie but for the stuff Dark could be good with you really sometimes just want to look at the JSON and poke at it, and your type systems aren't going to be helping you _that much_