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.

Comments

not like megacorps don't control OSS already

[alen]

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

Re:not like megacorps don't control OSS already

[mwvdlee]

It's not a complete myth, they still exist but, IMHO, they mostly focus on developing the new, exciting, risky and often hopeless ideas.
I'm perfectly happy with corporations focussing on stability, testing, documentation and all the other stuff that goes into actually finishing a project.

Re:not like megacorps don't control OSS already

[Xest]

That, and frankly, the FOSS community needs to make a choice - if they want the year of Linux on the desktop to stop being a joke and start being a reality there has to be a move towards this sort of professionality that gives corporations the confidence they need to roll it out onto the desktop - they need to know it will be supported for x number of years, they need to know there will be frequent updates to keep it competitive and so on.

There are a non-negligible number of participants in the FOSS community that want both global domination for their software, but just want to continue to developing in a laissez faire attitude - avoiding the responsibilities of creating something genuinely competitive and reliable enough to become dominant such as decent planning, professional efforts on documentation, design and UX stuff whilst also complaining that it doesn't get the attention they want.

IMO there are two choices developers have when working on FOSS projects:

1) Do it for fun and don't give a shit who or how many people use it, don't care how they use it, when they use it, just develop it because you like developing and because it's a good opportunity to showcase your skills and keep them sharp.

2) Care about how people use it, how successful it is, how widespread it is, but accept that there is a cost to this - the cost being that you have to expend effort doing the non-fun parts of software development like offering support, quashing bugs in a pre-agreed timeframe, providing documentation and so on and so forth.

Those who want the success and want to crush proprietary software without wanting to put in the effort of doing the boring stuff that makes proprietary software so successful in so many cases are living in fantasy land. Personally I have respect for people whatever decision they make above, what I don't have respect for are those who want to achieve the political agenda of 2) but simultaneously demand the lack of responsibilities of 1) - that's not realistic.

Google forked Linux?

[NotInHere]

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.

Re:Google forked Linux?

[nine-times]

Well, and who decides if a fork is good or bad? I thought the ability to fork has always been held as a strength of FOSS, as long as they release the code back to the public according to the licensing terms. X.org forked from XFree86, and it was considered a good thing. What about LibreOffice forking from OpenOffice? Webkit itself was a fork of KHTML, IIRC.

It often seems like the attitude of the FOSS community is something like, "You think you can do a better job on this project? Fork it and let's see what you got!" And then some company does it, and everyone whines and complains that they should be working within the community.

companies pay workers to develop software

[Mr. Slippery]

"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."

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.

Coercion Free

[Flammon]

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.

OS infected long ago - win-win!

[odds10-1]

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!

More releases? No problem.

[Qbertino]

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.

Re:More releases? No problem.

[bluefoxlucid]

It depends, really. It's relatively easy to estimate schedule, if you know what you're doing; project managers can balance constraints for repeated projects in a program by reducing the scope of individual projects, adjusting the schedule to meet a release schedule.

With Git, you can begin on the next release while performing QA on the current code base to be released next month--increasing cost risk (every adjustment to the code base requires merging those changes back into the next branch), but not a lot when you consider the nature of mostly-stable code (and bug fixes) along with Git's high-quality merge features. Thus it's possible to have a 6-month or 3-month release schedule, but start work on the next release a month in advance (or even earlier); of course, you need the resources to do so--when you go into QA, your main programmers might suddenly be 99% idle in favor of specialist quality testers, and thus free to move on to the next project.

Open Source Software development is run like a poorly-planned adaptive agile project: people throw a few features down, but largely just work. Adaptive projects chunk off a budget, a time frame (6 months, 5 years, etc.), and a large strategy (create a Web browser), and modify the project plan continuously. This is expensive--it produces a lot of work, rework, unplanned work, etc.--and only viable for very specific cases. Mostly people like the adaptive approach because either they can't see the inefficiency or they don't have the capacity to plan. The second group usually involves staffing support projects: you have $15 million to supply 120 employees for a Government agency over 5 years for the various positions supporting a certain group of operational functions, but the requirements (jobs open, job descriptions, length of employment for temps) will change wildly along that timeline. Notice this looks more like operations than a project.

A plan-driven project uses an approach like Waterfall to fully plan a project before beginning. This is the most efficient, but also relatively high risk. A plan-driven project doesn't account for changes; they always happen, but there's lacking effort in minimizing impact. Instead, effort goes into controlling risk (as always) and minimizing everything else--cost, schedule drift, risk of change.

Most open source products--indeed, most software projects and most projects in general--would benefit from an iterative or incremental agile approach.

In an incremental approach, the project manager arranges the project schedule to focus work on discrete, immediately-useful deliverables: something 100% complete and ready for release is produced as quickly as possible at each step. As each deliverable is released, it is evaluated by the customer (e.g. all Firefox users, all Ubuntu users), and the state of the whole product is accounted for and used to re-plan the next deliverables. In essence, you see how it's fitting together, and can adjust further features to work best with what you've delivered so far, or perform defect repair to improve the product if it's shaping up shitty.

In an iterative approach, a broad framework is lain and then built upon. For example, you would lay out the class structure and APIs for a large Python application; then build on that to provide the basic interface; then work on top of that to refine all the basic features into something workable; then build upon that to flesh out the features. This strategy reduces risk by first producing a broad platform to build upon, allowing for greater knowledge when planning further iterations.

Compound approaches are also viable: you can build the main platform iteratively, and start building incremental deliverables (i.e. features) on top of that. It doesn't make strict sense to iterate every single feature--and besides, if it did, every independent feature would be an incrementally-deliverable iteration, and thus the only cost of delivering them incrementally is management overhead. With unlimited resou

Writing code isn't always fun.

[jellomizer]

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.

companies pay workers to develop software

[Anonymous Coward]

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.

Stop posting opinions in TFS!

[Zebedeu]

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.

COM (MSRPC), Objective-C/J and Software Libre

[lkcl]

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

You Want to Help? Paid Development

[Bob9113]

"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)

Forking is Evil now?

[CrashNBrn]

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.

How does forking something make google the worst offender. Isn't that one of the key benefits to OSS that something can be forked?