Rocket.Chat is an incredible product because we have an incredible developer community.
Over 200 contributors have made our platform a dynamic and innovative toolkit, from group messages and video calls to helpdesk killer features.
Our contributors are the reason we’re the best cross-platform open source chat solution available today.
Jesse Noller: Rackspace Open Source Developer
The Oracle-Google Case Will Decide the Future of Software
But since the appeals court has already ruled that APIs are subject to copyright, that could open a whole new frontier of lawsuits aimed at startups and open source projects that have copied APIs in order to ensure their products are compatible with popular commercial products.
For example, several companies have built open source software that works with various cloud services in an attempt to make it easier for customers to easily move their applications from, say, Amazon to their own data centers. Basho and SwiftStack, to name just two, each offer storage products that are compatible with Amazon’s cloud storage service S3. Since APIs are subject to copyright, Amazon could in theory go after both companies for copyright violations.
Meanwhile, many open source operating systems, such as FreeBSD and those based on Linux, use a standard API called POSIX, which is based on the API of AT&T’s Unix operating system. Under the appeals court’s ruling, AT&T could go after the makers of POSIX operating systems.
“Both of those scenarios are more likely after Oracle v. Google,
regardless of how the jury decides,” says Mitch Stoltz, a senior staff attorney at the Electronic Frontier Foundation... Many newer development platforms, including Google’s Go language and Apple’s Swift, are licensed under more liberal terms than Java and allow for-profit companies to use and modify them.
Proprietary Postgres Forks: Keeping Code Forks Current is Hard
If we look at the dates listed in the Wiki, Greenplum is listed as starting in 2005. They’re not kidding, and unfortunately it seems Pivotal executed a “fork it and forget it” maneuver. The documentation admits Greenplum is based on Postgres 8.2, with elements of functionality from 8.3.
Like Amazon’s Redshift, this immediately disqualifies Greenplum from consideration for anyone using a newer version. Our own databases are on 9.4 pending an upgrade plan; there’s no way we could justify such a massive downgrade, even for horizontal scaling improvements. EnterpriseDB had a similar problem when they started selling their version of 8.3; they were far behind for years before they managed to reduce their version lag by only a few months. Greenplum never even bothered.
This may be an amazing product, but we can’t use it to replace existing Postgres 9.4 databases that need scaling. Will Greenplum catch up now that it’s been open-sourced? I can’t say. It would definitely be cool, but I’m not holding my breath. Incidentally, this is one of the reasons all of those projects on the Wiki have definitive end dates. Keeping up with Postgres after forking is extremely difficult if you don’t merge your enhancements back into core. It’s all too easy to fall hopelessly behind and become nothing but an academic concern.