Yet, the replacement for MatLab appears, at least to me, to be Python. The abundance of resources due to its general purposeness swamps Octave/MatLab's niche tailoring. Python is a mire flexible tool for STEM because it supports a broader array of applications.
My hope is to make Octave as obsolete as Matlab itself, but so far neither is. Matlab is huge and Python has not unthroned it. It will take a combined effort to do so. Octave is but another contributor to this effort.
Not quite. I am going try to to be the one doing that selling. I'm meeting someone today to discuss how to start that business.
Granted, I've only ever used it for school, but it is always incredibly painful to work with. I like Octave much better.
It was never "here's what it means to do X, and here's how to do X in matlab", it was "to do X, do this in matlab".
It seems like one of those tools that fosters such thinking.
Like, you know, pushing for the adoption of weird and tricky things like systemd before they're ready.
But neither is even close to matching Red Hat's sheer size, profitability, and reputation.
Last time I used any of SuSE's products was about seven years ago (when I was 14), when I couldn't install Linux on my mother's PC and played around with their LiveCD from a magazine.
SuSE seem to be much more popular in the parts of the linux community that do not have English as a first language.
Main issues I had came down to knowledge of the OS. Their default software repos don't seem to have nearly as many programs as Fedora/Ubuntu, but by adding a few external repos you'll get all that back.
If true it's concerning because RH has a huge influence on everything in the base repo, so that reverberates out to the greater open source community. Not cool when you think about the possibilities of influence the US Military could affect.
So far, many of the big names in FOSS, such as MySQL, have been using GPL to their advantage. By forcing competitors to release their modifications under the same license, GPL grants the copyright owner an effective monopoly on proprietary features. RMS probably isn't very happy with this situation, but it works.
GPL, however, is nearly useless in the cloud. You can add features to a GPL program and offer it as a proprietary service running on your servers. Since you're not distributing the program itself, you don't need to open-source your changes! AGPL was designed to prevent that, but hardly anyone uses AGPL.
Moving in the other direction are LGPL, BSD, MIT, and a bunch of other "permissive" licenses that are getting ever more popular among the cutting edge of the tech scene. In an ideal world, this should lead to even more freedom and better tools for everyone. But we don't live in an ideal world.
RMS has a knack of saying seemingly outrageous things that turn out to be highly relevant 10-20 years later, so I wonder what consequences the current proliferation of easy-to-convert-to-proprietary-software licenses will have on the tech scene of the next generation. Will all the good features get locked into walled gardens, or will companies continue to see value in releasing code under a permissive license?
Today's FOSS culture didn't arise on its own. It owes its existence to a dedicated group of people, such as RMS, ESR, Linus, Red Hat, MySQL, etc. who provided a large and stable copyleft core for the rest of the ecosystem to revolve around. But if the cloud makes the copyleft core largely irrelevant, how will the rest of the ecosystem adjust? Will it even survive? I don't know.
First, keeping your own private fork of a GPL library isn't all that easy an option if you also expect to be able to benefit from any further work done by the project's maintainers. By going that route you're committing to spending a lot of time and money on a lot of hairy merging.
Second, for most serious companies the open source libraries they rely on are not a part of their secret sauce. You're really not maintaining a whole lot of competitive advantage by closely holding that tweak to MySQL's query optimizer that lets your social office supply reviewing site respond to requests with 1% lower latency. Unless fractionally shorter response times is really what your company has going for it, of course. In which case it's probably doomed anyway.
I think these two factors in concert mean that it's generally much better for a business to contribute back than to try and maintain an internal fork.
Of course, businesses only contribute back to projects that they've decided to use in the first place. Using GPL code for your SASS product probably won't cause any immediate problems. It can still be a huge strategic misstep, though, because it does still limit your options for how you can pivot in the future. If you're a startup that could also mean a big drop in your value in the eyes of a potential suitor.
Yes, I think this explains the dearth of GPL contributions from recent startups.
I didn't mean to imply that GPL was ever the perfect way to license code that you also intend to use commercially. It's mediocre at best for that purpose, and intentionally so. After all, why would RMS want to facilitate production of proprietaty software?
What is undeniable is that the cloud and the startup scene are leading a new trend in FOSS licensing. The recent Github statistics show more MIT/BSD/Apache licensed projects than ever before. This shift will have far-reaching consequences on the FOSS ecosystem in the long term, and I'm just not sure whether those consequences will be good or bad. We've got too many idealists and too many VC-chasers in the same room here ;)
Only as a commercial weapon (which was never the intent) - for other readers, MySQL is dual licensedm and it's possible to use it already without being subject to the GPL, obviously. There wasn't much pickup for Affero, all told. In many ways, it's nicer, because people who are not distributing apps are more likely to use GPL applications (though if they understand linkage, they shouldn't fear it anyway). License choices are not that important.
There are definitely ways to build proprietary application components without requiring GPL. (i.e. solutions around a GPL application that don't require directly extending the core of it with proprietary bits). Numerous examples.
The other model is basically building something that is a software consultancy / helpdesk / services org. And that's a lot of what Red Hat is.
Today, it seems many more projects are actually going full Apache. Because it's easy to extend something, it's not declining. It's accelerating.
If you make your own extensions to something and don't get them upstream, you lose the advantage of being able to consume easily what happens upstream. And that upstream development is increasingly funded by people who work at companies using those solutions - or selling them.
Cloud just makes everything to deploy faster and on even larger scale; being able to host something behind a .com in pre-widescale-cloud days was still a thing.
Clearly Red Hat should buy GitLab and make it 100% open source. :)
This is a misunderstanding of how the development of Linux works. It's not a project in the conventional sense and never has been. Anyone can contribute as long as their code is good enough and solves a problem or adds a feature. But because the code is under the GPL, no-one can take others' work and make it proprietary. It creates a level playing field for customers because OS development is not their core business but rather just a cost of doing said business.
It's also a misunderstanding of the value Red Hat brought - and still brings - to enterprise software. A subscription buys you enterprise support, certification with third party vendors and the guarantee that Red Hat will distribute improvements to the kernel in a predictable way for you.
I'd hope that means you just get read access to their linux.git if you're paying them.
If you're not paying them, in order to get access to the Red Hat 7 kernel source, there's git repo that houses a reference to a xz-compressed tarball that you download from another site which you piece back together to get a .src.rpm - inside of which is a the raw kernel.org source and a monolithic patch file.
I would also call that predictable (and thus, thankfully scriptable) process, but it's pretty convoluted. Actual git access to kernel source would be preferable.
Anyone have more up to date numbers or other ways to characterize overall size or contribution to open source? Am also curious whether SUSE or Canonical do any public policy, perhaps just as a side effect of selling to governments. Red Hat apparently has a "Global Public Policy" department though there's little info about it on the web. In theory a larger entity can reap more benefits of policy activity including lobbying, so will do more of it.
There is no denying the size of Red Hat, and thus its influence. I'm just thankful there are other out there doing the good work as well.
In particular, I think Big Data and Open Networking are two of those areas.
Do they need to get as big as Red Hat is now? Defintely not.
Levine's (linked) comment that OSS companies can't execute on Product Management is incredibly short sighted, if done correctly, they have infinitely more data than their proprietary counterparts. But later on he seems to be saying that there can't be another people keeping it as "pure" ... well, no, Red Hat isn't really a product company. I'll get to that.
The first article itself doesn't seem to know what Red Hat really is either, saying "Red Hat has become a technology sommelier that selects the best of open source infrastructure and development software and organizes it into packages to solve enduring problems for enterprise computing.". It's more about support of base OS. Really. All the packaging stuff makes that possible, but the various products that Red Hat buys and sells are tiny in comparison.
Whether we like it or not, if you are building building-block software the expectation is now that these components be OSS. Proprietary software is generally viewed as acceptable in SaaS apps and end-user products, but is growing less acceptable in application substrates, programming languages, and the like.
Red Hat is doing well because of a lot of big (read: bank) customers needing expertise on kernel/hardware related issues, other companies will likely grow differently.
If people are asking for "another" Red Hat, what do they want? It's really a meaningless phrase in a way. I don't think they want Red Hat's various ancillary products, I think they mean something with the teeth of an operating system company.
Red Hat is great, and in many ways still is. There are many more interesting things to do instead. The comparison of thing-that-is-a-company-but-not-in-the-same-space with Red Hat is typical VC meaningless-ness question.
Maybe it's asking "can something get so big without being an OS company". I think it can, because the OS is largely a solved problem, and there is lots to be done is going to appear on top of it - but I'd also rather companies didn't try to get that big, and just concentrate on making one or two awesome things, and there being lots of awesome things.
If there's ever another breakout in enterprise open source, Red Hat will buy that firm, too.
