Date: Tue, 17 Jan 2012 14:46:37 -0700 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Julian Elischer <julian@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <1326836797.1669.234.camel@revolution.hippie.lan> In-Reply-To: <4F15C44F.1030208@freebsd.org> References: <alpine.BSF.2.00.1112211415580.19710@kozubik.com> <op.v78i3yxi34t2sn@tech304> <4F15C44F.1030208@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2012-01-17 at 10:56 -0800, Julian Elischer wrote: > If it came to that maybe all the people who are currently saying they > need better > support of the 8.x branch could get together and together, support > someone > to do that job for them..would 1/5th of a person be too expensive > for > them? > > if not, what is a reasonable cost? Is it worth 1/20 th of a person? > > > Julian > I've got to say, this strikes me as the most interesting idea floated so far in this conversation. I've heard of many instances of sponsored projects; they almost always involve major new features or support for new hardware or technologies; paying someone for a specific small focused fix is also common. A sponsored branch is... well... just an interesting concept to me. Unlike most developers, I have little interest in creating new code from scratch to implement the fad of the week. (There's that whole other opensource OS if fad of the week technology is your thing.) I live to find and fix bugs. Sometimes that means days of frustration to generate a one-line patch. Sometimes you find the problem in minutes but the fix means a painful redesign that touches 342 files and has the potential to ruin everyone's day when you get it wrong. But, for me at least, it's much more challenging and thus more rewarding when you get it right. Despite being a developer myself, I understand completely where John is coming from in opening this conversation, and I'm firmly in the "me too" camp because I'm also an end user of FreeBSD. I work at a company that creates embedded systems products with FreeBSD as our OS. In July we started the process of converting our products from 6.2 to 8.2. Out of sheer emergency necessity we shipped a product using 8.2 in October -- 6.2 was panicking and the customer was screaming, we had no choice; we've had to do several fix releases since then. It's only within the past couple weeks that I think we're finally ready to deploy 8.2 for all new products. More testing is needed before updating existing products in the field. It takes a long time for a business to vet a major release of an OS and deploy it. It costs a lot. Now, before we're even really completely up and running on 8.2 at work, 9.0 hits the street, and developers have moved on to working in the 10.0 world. What are the chances that any of the patches I've submitted for bugs we fixed in 8.x are ever going to get commited now that 8 is well on its way to becoming ancient history in developers' minds? So back to where I started this rambling... that concept of a sponsored branch, or maybe something along the lines of a long-lived stable branch supported by a co-op of interested users. Some co-op members may be able to provide developers or other engineering-related resources, some may just pay cash to help acquire those resources for various short-term or targeted needs along the way. I think it could work, and I think businesses that need such stability might find it easier to contribute something to a co-op than the current situation that requires a company such as ours to become, in effect, our own little "FreeBSD Project Lite" (if you think FreeBSD lacks manpower to do release engineering, imagine how hard it is for a small or medium sized business). -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1326836797.1669.234.camel>