Slashdot Mirror
Industry-Based ToDo Alliance Wants To Guide FOSS Development
jralls (537436) writes The New York Times broke a story [Monday] (paywalled if you look at more than 10 stories a month) about ToDo, "an open group of companies who run open source programs" who are seeking to "committed to working together in order to overcome" the challenges of using FOSS, "including ensuring high-quality and frequent releases, engaging with developer communities, and using and contributing back to other projects effectively." The more militant among us will read that as "It's not enough getting a free ride off of developers building great software, we want to shove our roadmap down their throats and get them to work harder for us — without having to pay for it, of course." That might be a bit harsh, but none of the companies on the page are exactly well known for cooperating with the projects they use, with Google being one of the worst offenders by forking both Linux and WebKit.
most OSS software is already developed by giant megacorps. all the routers, apple, google, red hat, oracle, IBM and others
the guy at home coding after work is a myth
30 companies, probably 150 agendas between them. Yeah, that'll work great.
OK, they published Android, but they didn't fork linux. Linux is a kernel, not an OS. And even if they forked linux, every distro has its own "fork" of the kernel.
Looks more like "We want to figure out how best to coordinate and share that portion of the work that the people whom we pay to develop software for us, do on free software." (Though they're not using that dangerous word "free", of course.)
"Free" or "open source" doesn't mean no one is getting paid to develop it.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Isn't this what just happened with the steaming pile of shit called systemd?
This is where these companies have figured out that they don't need to spend much on development. Nope, just form a consortium and have these people work for you, most of them for free.
Look, I love open source, but this was inevitable under the current system.
by centralization of cat food distribution.
Mice scurry at Slashdot.
I don't understand why people get upset when companies fork a code branch. That's the entire point of working with open code. If you like the idea of the project but don't like how it's working or how it's managed, you have the right to take the code and change it to suit your needs. There is nothing that says you have to contribute back. On the other hand, it's a major dick move for companies to *not* fork the code but instead demand more from the communities and developers who make a project possible. I can't read the original story at the moment, but if the summary is true, then fuck those companies.
The only way to direct a FOSS project is to contribute to it, whether it's time or money. It cannot be directed by force. It is an anarchy. There are no rulers to force anyone to do anything. If we could just get our governments to work the same way, we'd all be better off.
ayottesoftware.com
So the major players want to bring some order to the bazaar. So be it - they can try. There are small projects that will probably decide to cooperate, and will because they are a one- or two- person effort - but the projects that truly behave like a bazaar will remain as coordinated or uncoordinated as they still are.
I don't see this effort being capable of shoving an agenda down anybody's throats - if you don't care for the agenda, don't. Submit your code to the project as and when you see fit, and work on the bits you want to. If tomorrow they want to address what they see as glaring issues in GNU's netcat, they'll be able to throw resources at it collectively - but I doubt they'll be able to tap GNU's shoulder and say "hey, give us some of 'your' devs to fix this."
In the end, if the effort results in a pooled selection of developers, incentivized directly and collectively (read: employed) by the companies, to work on aspects of open source projects they have communal stake in, to common goals and specification, that is probably going to be a good thing.
If they fork any of the technologies that is fine too - that's exactly what GNU GPLv3 was meant to allow them to do. They just can't expect to fork the maintainers and community too.
If however there is a scenario in which volunteers can be coerced into their way or the highway, that scenario must be understood and countermeasures prepared by those who would stand to lose from it. Don't take it too seriously, but don't take it in any way lightly either.
-- "Simplicity is prerequisite for reliability." --Dijkstra
I gave up on working in two major open-source projects because they were already controlled by their corporate sponsors. Voting and online discussion is largely sham governance; all real issues are arranged out-of-band. It doesn't even take a majority if you're careful.
Further, projects run by their objectives, since people who disagree leave. So making time a primary factor selects compliant developers.
But since OS has evolved into a way of proving yourself capable and compliant so you can get a good job, it's a classic win-win!
Only some manager falling for some marketing thing would think more releases means better software. I can give them releases of my new FOSS TotallyUseless.exe/TotallyUseless.bin Programm - 3 times a day, no problem. 100$ per hour and you can have bucketloads of releases.
We suffer more in our imagination than in reality. - Seneca
EasyPeasy: *you* pay for it.
If you allow publication under a free license, I'm game for a rebate.
I'm up for hire!
The biggest issue with a lot of of the home grown Open Source Apps, is getting past the dreaded 80% complete mark.
This is the point in the program where all the interesting proof of concepts and interesting algorithms are all set. However that last 20% is a lot of the detail fine tuning that really puts all the pieces in play.
This last 20% mark when it no longer becomes fun, is where the project looses steam and sometimes dies off.
Having a company putting money towards development with management and direction and all those MBA Buzzwords basically means we push the developers to get that last 20% done.
But of course if they are pushing to get that set done, and are putting in resources to help that, it is going to be their vision of 20% not necessary yours.
I know a lot of the Open Source people have this Anti-Corporate everything mind set... However to make it in the world there needs other sources of motivation other then just feeling good.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Good point.
I've contributed to open source projects (mostly Drupal, in my case) for years. Virtually all of it has been while I was paid as an employee, contributing back things I developed for my employer (and with my employer's consent and encouragement). I don't send the bulk of my time working on projects just for the community. Most of my time is creating solutions for my employer's clients. But in the course of this, it is not uncommon that I create something useful to others, and then contribute it back.
Open source developers are a diverse group and I know my situation is radically different from many other people's. But it is easy to generalize, and good to keep in mind that developers and companies come at open source from different perspectives.
Visiting todogroup.org, I thought their slogan is "Take Openly, Develop Openly" instead of "Talk Openly, Develop Openly" for a few seconds.
If your objective is publicity, frequent releases are good. If you're writing useable software, frequent releases are bad.
The more militant among us will read that as "It's not enough getting a free ride off of developers building great software, we want to shove our roadmap down their throats and get them to work harder for us — without having to pay for it, of course." That might be a bit harsh, but none of the companies on the page are exactly well known for cooperating with the projects they use, with Google being one of the worst offenders by forking both Linux and WebKit.
This part of TFS is superfulous to the news item and actually degrades from the piece.
It steers the discussion away from the actual news and towards the submitter's pet peeves (notice how he made sure to mention Google by name).
jralls should really save his opinions for the comment section, or if not, the editors should've forced him to.
Now the entire comment section for this article will essentially be a huge subthread for that guy's inflamatory comments.
Yeah yeah, I know this is par for the course for /. and that's the part that really sucks.
in looking at why both apple and microsoft have been overwhelmingly successful i came to the conclusion that it is because both companies are using dynamic object-orientated paradigms that can allow components from disparate programming languages to be accessible at runtime. COM is the reason why, after 20 years, you can find a random Active-X component written two decades ago, plug it into a modern windows computer and it will *work*.
Objective-C is the OO concept taken to the extreme: it's actually built-in to the programming language. COM is a bit more sensible: it's a series of rules (based ultimately on the flattening of data structures into a stream that can be sent over a socket, or via shared memory) which may be implemented in userspace: the c++ implementation has some classes whilst the c implementation has macros, but ultimately you could implement COM in any programming language you cared to.
the first amazing thing about COM (which is based on MSRPC which in turn was originally the OpenGroup's BSD-licensed DCE/RPC source code) is that because it is on top of DCE/RPC (ok MSRPC) you have version-control at the interface layer. the second amazing thing is that they have "co-classes" meaning that an "object" may be "merged" with another (multiple inheritance). when you combine this with the version-control capabilities of DCERPC/MSRPC you get not only binary-interoperability between client and server regardless of how many revisions there are to an API but also you can use co-classes to create "optional parameters" (by combining a function with 3 parameters in one IDL file with another same-named function with 4 parameters in another IDL file, 5 in another and so on).
the thing is that:
a) to create such infrastructure in the first place takes a hell of a lot of vision, committment and guts.
b) to mandate the use of such infrastructure, for the good of the company, the users, and the developers, also takes a lot of committment and guts. when people actually knew what COM was it was *very* unpopular, but unfortunately at the time things like python-comtypes (which makes COM so transparent it has the *opposite* problem - that of being so easy that programmers go "what's all the fuss about???" and don't realise quite how powerful what they are doing really is)
both microsoft and apple were - are - companies where it was possible to make such top-down decisions and say "This Is The Way It's Gonna Go Down".
now let's take a look at the GNU/Linux community.
the GNU/Linux community does have XPIDL and XPCOM, written by the Mozilla Foundation. XPCOM is "based on" COM. XPCOM has a registry. it has the same API, the same macros, and it even has an IDL compiler (XPIDL). however what it *does not* have is co-classes. co-classes are the absolute, absolute bed-rock of COM and because XPCOM does not have co-classes there have been TEN YEARS of complaints from developers - mostly java developers but also c++ developers - attempting to use Mozilla technology (embedding Gecko is the usual one) and being driven UP THE F******G WALL by binary ABI incompatibility on pretty much every single damn release of the mozilla binaries. one single change to an IDL file results, sadly, in a broken system for these third party developers.
the GNU/Linux community does have CORBA, thanks to Olivetti Labs who released their implementation of CORBA some time back in 1997. CORBA was the competitor to COM, and it was nowhere near as good. Gnome adopted it... but nobody else did.
the GNU/Linux community does have an RPC mechanism in KDE. its first implementation is known famously for having been written in 20 minutes. not much more needs to be said.
the GNU/Linux community does have gobject. gobject is, after nearly fifteen years, beginning to get introspection, and this is beginning to bubble up to the dynamic programming languages such as python. gobject does not have interface revision control.
the GNU/Linux community does actually have a (near full) implem
"an open group of companies who run open source programs" who are seeking to "committed to working together in order to overcome" the challenges of using FOSS
If the megacorps want to get involved in the advancement of FOSS, they have an incredibly clear path to do so: Paid Development. They can fund it themselves, if they want to decide what gets built next. Or, to get a little creative, how about this: Put together some training materials for corporate legal departments explaining that companies can legally, safely, contribute code developed on company time back to FOSS projects. Put together a promotional campaign to convince corporate bean counters that contributing code back to FOSS is a worthwhile investement of company resources.
In short; help channel money into FOSS, either directly or by clearing the red tape that keeps us from creating and kicking back enhancements built for the benefit of our companies. Hey, maybe lobby congress for a tax write-off for code contributions to 501c3s.
Developers contribute to FOSS by giving of their greatest strength, development. If megacorps want to help, they should give of their greatest strengths; money and bureaucracy.
(and yes, I know, they think telling people what to do is their greatest strength, but they've got another think coming when it comes to telling FOSS developers what to do)
Stop-Prism.org: Opt Out of Surveillance
Self-selecting, too.
Dudes and gals who get their panties in a bunch about corporations "controlling" open source will steer clear, while people passionate about open source and looking for an employer might take a closer look.
How does forking something make google the worst offender. Isn't that one of the key benefits to OSS that something can be forked?
So these companies think they're going to herd the cats which make up the FOSS communities?
Good luck with that, you might cause more damage than you solve problems.
Lost at C:>. Found at C.
Let's hope this doesn't derail itself the same way the Yocto Project did. Yocto is massively company-sponsored and IMHO it's a sad joke. It's a huge, bloated cancer of a build system that is neither usable nor understandable.
If a train station is a place where a train stops, what's a workstation?
Companies: "You need to implement X"
Devs: "Nah, not interested"
Comps: "Do it anyway, or we'll lock you out"
Devs: FOAD
* Code is forked, everyone moves to the forked version and the original, corporate-controlled version dies on the vine *
Reference:
OpenOffice -> LibreOffice
Hudson -> Jenkins