Every time I come across these projects I think an easy to use web fronted for Docker would be amazingly useful.
Anyone could install it once and from then you just switch Docker containers in and out to try different projects, etc... and don't have to do the bulk of the server preparation that 99% of people don't know how to do properly or just can't bother with.
It will bring this amazing wealth of self-hosted projects to the every day user.
If it becomes popular projects will start providing Docker containers.
A registry can also be made so that you can search and install them without hassle right from the UI.
I have created a script to run tree.io in docker with a lightweight (25MB) postgresql instance. Simply install Docker then run this script https://gist.github.com/funkotron/6025664
What you're proposing are virtual appliances, a virtual machine image "intended to eliminate the installation, configuration and maintenance costs associated with running complex stacks of software" (to quote https://en.wikipedia.org/wiki/Virtual_appliance). It's not uncommon to see commercial software distributed this way, and I've seen some open source projects do it as well. There are multiple existing attempts to build a "registry", such as https://www.vmware.com/latam/appliances/ and http://www.turnkeylinux.org/
The problem with VMs is that they're not a practical vehicle for shipping software, because they're not portable. Developers will always have to deal with multiple incompatible VM formats, in addition to deployment targets which simply don't support VM deployment at all. What's missing is a "common ancestor" to all these different formats, which can be exported to a VM when necessary, but also run natively in places where VMs are not available. That's what docker containers are.
There's a standard format, OVF, that the relevant players seem to support. The number of deployment targets that support some kind of virtualization software will always be higher than the number that support docker.
Docker: A linux distribution with kernel 3.8 (released in 2013) or newer.
OVF: A linux distribution with kernel 2.6.20 (released in 2007) or newer, or Virtualbox, or Citrix XenServer, or the VMware products, or Microsoft's Hyper-V, etc...
For a "common ancestor", despite docker's awesomeness I don't see anything special it has to offer in this regard. What's appropriate is properly packaged software that lends itself to automated configuration. That can be used for installs on bare metal, generating docker images, and generating images for other platforms via tools like http://www.packer.io and http://en.opensuse.org/Portal:KIWI
> There's a standard format, OVF, that the relevant players seem to support
I'll just point to the elephant in the room: EC2 doesn't support it. Neither do the majority of IAAS players. Even those that are OVF-based under the hood often don't have a facility for loading your own OVFs, let alone sharing them, etc. And when they do, the first thing they implement is some proprietary extension.
> The number of deployment targets that support some kind of virtualization software will always be higher than the number that support docker.
I don't believe that is correct. But of course the burden is on me to prove you wrong :)
Keep in mind that:
1) Docker is 3 months old and artificially narrows its support window to keep moving fast. For example it doesn't yet support 32-bit architectures, or arm, or install on red hat - but it will.
2) When it does expand its support window, docker will run on 2.6 kernels. Dotcloud has been deploying lxc containers at large scale since 2010, all on 2.6.
3) In the future docker will support non-lxc backends such as openvz, bsd jails, solaris zones and plain old chroot. At the end of the day a docker container is just a tarball with metadata describing what the developer expects to happen when it's run.
4) Also keep in mind that on many systems, virtualization is supported but not available to the relevant party. A typical example is an IT shop with a shiny new openstack deployment which still requires developers to fill triplicate forms to provision machines.
Again, this is in addition to machines which are not configured to support virtualization - often because the overhead is too high.
So I stand by my statement. In the future docker containers will be deployable on more machines than any given VM. And VMs will be used primarily for flexible hardware and kernel allocation, which is what they are good at.
> What's appropriate is properly packaged software that lends itself to automated configuration.
That's just it: for a large and growing number of developers, there is no tool available to "properly package" their software, because they combine multiple languages and frameworks, and don't wish to be stuck with a single OS distribution. I won't list the alternatives here, but will gladly do so if you request it. Docker has the ambition to be that tool, and I believe it is qualified for the job:
* Automated build with 'docker build'
* Built-in versioning
* Facilities for sharing, discovery and distribution
* Incremental transfer for efficient distribution of upgrades
* Dependency management which puts the developer in control
* No out-of-band dependencies except for docker (a 5MB static binary) and the kernel
* Distro-agnostic: the developer and sysadmin are both free to choose their distro and system packager (if any).
* Config management-agnostic: the developer and sysadmin are both free to choose their config management (if any)
As you suggest, a docker container can be used for installs on bare metal, generating images for other platforms via tools like packer, etc.
I talked to Solomon during DotScale 2013 and submitted that the index could be transformed into an app-store. He didn't seemed opposed to the idea but said they want to focus on making the base stable. Just saying the idea is out there.
Apart from the app-store what's missing is more container metadata with an embedded security model and maybe signed binaries. The server-side also need a UI that is higher-level than the existing Docker UI [1] project. There's also some work missing on state handling.
I think the model might be a little bit misguided (having everything in one place is not necessarily a good thing, specialization and all) -- but open source and awesome? I'm down with that
Agreed, although there are more capable ERP systems out there of varying degrees of openness, I've found many of them suffer from one serious core flaw (for my needs):
Failure to integrate effectively with Quickbooks or QBO (the latter being more likely for most ERP-like systems these days). I understand that some businesses need fewer advanced financial features, but every promise of "integrated one-stop back-end" has left me with having to have multiple processes for the same task.
I wish more of these projects would integrate with common, effective, players in specialized areas rather than trying to "be everything to everyone" - a good ERP system these days would really be glue between the powerhouses moreso than replacements.
Alas, this project looks to be struggling - no blog posts since 2011, and minimal activity over 2013 in github.
I wouldn't say the other software are more capable, but rather more featureful. The problem with OpenBravo and SugarCRM is that it's really really difficult to use.
Every procedure depends on another procedure and you need a Book to get going. As a company that is a massive backshot when you have to teach existing employees.
I argue that simplicity in the UI and clear workflows going through the entire application are essential for success, well and marketing. And tree.io had no good marketing, I hope it gets some fresh wind thanks to HN on Github.
Tree.io is simple, which allows for customization and specialization. :)
I think you mistake all-in-one with complexity and non-adaptability. Centralization makes software vulnerable, that's right, but not this type of in-house centralization.
Correct me if I am wrong.
Even the best and most loosely coupled component-based software has one problem, it needs to be connected (glued if badly written) to other systems to make it useful. What this evolves to is a complex network of interlinked components. Similar to organic systems nature has invented. Ironic, that we humans create similarly working components that we're made out of.
I can definitely see the value in connecting the systems -- that's without a doubt very important (and a very good reason Microsoft has a corner on the market)
What I was more getting at was that by not focusing on interaction/dealing with centralization or supporting interaction between multiple services, teams usually move faster (less process, if no other gains -- no one has to check your outputs for compatability,etc), and get to do more feature-development.
But then again, as a lazy person who loves open source stuff, any attempt at something so ambitious is awesome I think. I feel like a lemming for saying anything bad about it.
[EDIT] - Taking another look at the tour -- It is pretty amazing. A lot of companies are charging for LESS functionality
Yeah, I also kind of find it funny when companies charge for very simple invoice tools, when they could opensource it, and focus on their next mini-project instead. They could built a suite of tools that way, but hey "instant profit" is seductive.
For those who doesn't want to have their data in the hands of a third party it makes sense having everything in one system, and because it's open source you can easily extend it if need be.
This is really awesome. The only thing that keeps me from using it right away is that it doesn't seem to have much activity. Anyone have the DL on the creators of the project and if they're maybe monetizing by doing support etc?
Would love to use this, just worried about getting stuck up the creek without a paddle. Many forum questions appear to have been lingering there for months without a response.
0 commits on master and 0 bugs fixed in 9 months, a handful of commits by a user who branched off of master a couple months ago (and no PRs)... I think it's safe to say that that the 'public' version has been dormant for 9 months.
Name seemed familiar, and in deed their blog has posts from 2011 when they were a SaaS. Anyone know what happened, did it simply fail and they open sourced it or is there something else in play here?
My guess is enterprises were scared of going the SaaS route; partly as this model is still relatively new, but mainly because companies like to keep their data in house (or at least need the option to easily get hold of a regular backup / with some way to quickly restore it should the vendor go under).
Infrastructure costs. We had too many users on the free tier (5 users for free) and our server costs went through the roof. We didn't know how to find investment and my business partner needed cash so took a contract job.
Can anyone get the install process to actually work? I got to 'python manage.py installdb' and it failed because that command doesn't exist in manage.py. I tried a bunch of the other commands from manage.py help as well and still nothing.
It's a Django project, so the command might be "syncdb" instead. If that doesn't do the trick, they'll have installed a custom management command that doesn't seem to get picked up. Grep the source code for installdb then.
Like all open source applications. I use OSS exclusively for development. I think the only OSS GUI app I use is Sequel Pro (which is actually quite good).
I'm not sure "ambitious" is even the right word to describe such a project. A demo would be nice. I'm guessing the project has 0 real users (download <> user).
I measured that +53 Stars have appeared on Github right after posting the link. It received 38 points until now, that means more people have interest in the software than people are upvoing on HN. That's really good to know, I feel sympathy with people who opensource their efforts to help the people of the world. (328 Stars pre HN)
Thanks X4, I put over a year of hard work and a lot of my own money into Tree.io. I'm happy that it's used around the world by companies and universities even though I don't get any money from it.
How about adding a viable business model that brings you some constant money in? I mean you are a really good startup, why don't you ask for VC funding or Enterprise Sponsors?
Maybe a solid and good marketed Kickstarter Campaign that will realize something that people would love to have (I don't know what that is though).
Or adding an integrated Marketplace like http://www.concrete5.org/marketplace/ that seamlessly integrates into everyones Tree.io so that devs can sell their addons to end-users directly within their own install + you get 11% for every sold license. End-users can point, click and pay.
Anyone could install it once and from then you just switch Docker containers in and out to try different projects, etc... and don't have to do the bulk of the server preparation that 99% of people don't know how to do properly or just can't bother with.
It will bring this amazing wealth of self-hosted projects to the every day user.
If it becomes popular projects will start providing Docker containers.
A registry can also be made so that you can search and install them without hassle right from the UI.
Or the command line, "docker-get install tree.io"
Take my idea and run with it! Run!