Tree.io – Open Source Business Management Software
tree.io
tree.io
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!
"docker pull borplk/tres.io"?
You can search at http://index.docker.io
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.
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
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.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 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.
There's no consensus about which one is the best form of cash bonfire.
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.
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
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.
I'm only asking because the bottom of http://tree.io/en/jobs mentions it. :)
> © 2011 Giteso Ltd. All rights reserved. > Registered in England. Company No. 07416236
Cool project either way though :)
export PYTHONPATH=$PYTHONPATH:/path/to/treeio:/path/to/
(ie add the project path and its parent to PYTHONPATH), then try manage.py installdb again.
NB This is guesswork based on prior django experience, I haven't actually tried installing it.
IntegrityError: (1452, 'Cannot add or update a child row: a foreign key constraint fails (`treeiodb`.`core_user`, CONSTRAINT `user_id_refs_id_4bf8d20` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`))')Just run: mysql -u username -p -D database < sql/mysql-treeio-current.sql
http://www.youtube.com/watch?v=ORKhxzwO43k&list=UUBWJQIUhDQz...
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.