handing over footage to a client

Jarred Land said:
Sorry man no.. there is only one aspect of that that is counted as development.. and guess which one it is? I'll give you a hint.. it has the word development in it.

Rent and Paying the people the non engineers that open the doors every morning is not development costs.

The a very large percentage of the CDB (cost of doing business) goes to non development expenses.
Click to expand...
I like using my own definition of development costs: if it requires a material to develop a product, I call it a development cost. If it requires a machine to develop a product, I call it a development cost. If it requires people to develop a product, I call them a development cost. If it requires a building to house the people that are required to develop a product, I call it a development cost. If it requires people to guard the building that houses the people that develop a product, I call them a development cost as well. I add up everything involved and related to the development of a product, and call it a development cost, because every piece is somehow related to the development process of the finished product. Maybe not directly, but somehow it'll factor in.

If there is an industry standard for the term "development cost", and I'm sure there probably is, feel free to let me know. And please let me know from which group you're referencing the definition; accounting, software development, systems analysis, manufacturing, etc.

I'll keep using my own definition until I'm confident that the industry standard definition is widely accepted and makes sense.
 
hey go ahead man.. you can use your definition if it makes you happy, i have no right to tell you otherwise.

I guess me just typing that was a dvxuser.com development cost. Good old me.. always thinking of the future ha ha ha.

Seriously though Lowkus.. I get what your trying to say and your not completely wrong.. but its just a very odd way of doing business.. and here in the US im sure the IRS would love to have a word with you if you try and deduct everything you spend money on as development costs, specialy under the newly revised qualified research credit.
 
Lowkus said:
No, sorry - right. If a software product is built correctly, modifications to the code are negligible after it is shipped. Bugs should not need to be fixed, because there will be no bugs, and features won't need to be added, because proper design would have addressed the needs of the user before release. Support is provided by help files that would have been properly written at the start. Training is handled by third parties or is not needed because people can open the help file and learn everything just by reading it. If the audience can't read, provide video files that they can watch.
Click to expand...
This is just wacky on so many levels. :)

"...because there will be no bugs"
"...and features won't need to be added."

Rule #1 - there are always bugs. Always.
Rule #2 - if you think there are no bugs, see rule #1.

And also, there is that weird, grey area between what is just really poor software behavior and what is a bug.

Features always need to be added. Let's assume that your product is perfect the day it ships. The next week, the industry will have advanced a bit, or a competitor will have shipped a new release, or a user will have discovered something that nobody on your team thought of. And a feature is born that needs to be included on the next rev.

"...Training is handled by third parties or is not needed because people can open the help file and learn everything just by reading it."

Hands up - who here reads all the manuals for the software they buy? Hmmm... not many hands. And who here has been in a session with a client over your shoulder and software starts crashing, and client starts freaking out. What do you do - open the manual or call support?

And who here has ever tried to launch a training DVD that doesn't launch because of the wrong OS, or software that needs to be downloaded, or bad manufacturing, or, or, or...

Lowkus - your statements are true in a theoretical sense. But they just don't reflect the reality of software development.

Lowkus said:
The makers of Final Cut Pro are not in the business of hardware... they make their money on software and so it is likely they will charge for every upgrade they ever make.
Click to expand...
Your statement in a later post about the FCP living and dying by their own means notwithstanding...

A group within a company set up as its own P&L is never truly independent. Marketing and advertising is usually not within the P&L but is typically handled by internal MarCom. You may have some sway over MarCom's priorities, but to a large extent that is determined way above the level of the individual P&Ls. And how important is marketing and advertising to your product? If you're FCP... it's everything. It's the Apple way of life.

Your statements are not "wrong" per se, but they just don't reflect the real world of software development, and the realities of how corporations operate.
 
IRS definitions can be pretty weird. I'll walk that line with extra caution if I ever get an income going.
 
luki said:
This is just wacky on so many levels. :)

"...because there will be no bugs"
"...and features won't need to be added."

Rule #1 - there are always bugs. Always.
Rule #2 - if you think there are no bugs, see rule #1.

And also, there is that weird, grey area between what is just really poor software behavior and what is a bug.

Features always need to be added. Let's assume that your product is perfect the day it ships. The next week, the industry will have advanced a bit, or a competitor will have shipped a new release, or a user will have discovered something that nobody on your team thought of. And a feature is born that needs to be included on the next rev.

"...Training is handled by third parties or is not needed because people can open the help file and learn everything just by reading it."

Hands up - who here reads all the manuals for the software they buy? Hmmm... not many hands. And who here has been in a session with a client over your shoulder and software starts crashing, and client starts freaking out. What do you do - open the manual or call support?

And who here has ever tried to launch a training DVD that doesn't launch because of the wrong OS, or software that needs to be downloaded, or bad manufacturing, or, or, or...

Lowkus - your statements are true in a theoretical sense. But they just don't reflect the reality of software development.


Your statement in a later post about the FCP living and dying by their own means notwithstanding...

A group within a company set up as its own P&L is never truly independent. Marketing and advertising is usually not within the P&L but is typically handled by internal MarCom. You may have some sway over MarCom's priorities, but to a large extent that is determined way above the level of the individual P&Ls. And how important is marketing and advertising to your product? If you're FCP... it's everything. It's the Apple way of life.

Your statements are not "wrong" per se, but they just don't reflect the real world of software development, and the realities of how corporations operate.
Click to expand...

I'm a wacky kind of guy. I can see where you're coming at, regarding my "hypothetically possible" solution. Though I personally get tired of rule #1 being spread as fact amongst the software industry. I know everyone says that bugs are inevitable, but really they can be prevented given time and proper programming practices. Most businesses just don't like to give their programmers as much time as they need to finish stuff up, and they don't unite the programmers with a clear direction of how it's all going to fit together. Using 3rd party components is also a pain, since that becomes a new source of dependence and buggery. It also frustrates me when businesses ship the programming work to the cheapest bidders, who aren't usually the programmers that create the most solid code. The last company I was at made me cringe at their total lack of good development practices. "Ship It!" Was their motto... I was so happy when I was out of there.

And I can see the case for upgrades and improvements. But on a really fundamental program, like something that handles RAW conversion from one codec to another, maybe with a handful of color-processing features, future-feature creep shouldn't be much of an issue. Definitely not a fast-paced new-idea technological arena, by the time Red-Two ships maybe the software would be casually ready for an update of some sort. The best solution to the software problem was made by someone earlier in this thread, or maybe it was another, when they suggested making the software open source.

Manuals... I know nobody reads them, but they should if they need help. Help files should start having little easter egg secrets in them so that more people read them. And you should always try to do a run-through before presenting something to a client - get to know the software before presenting it and all that. I think this common sense approach would become more prevalent if companies started cutting back on phone tech support. It would only take a few instances of pain before the users would become more cautious and prepare themselves more thoroughly. Plus, they wouldn't be as likely to risk buying buggy software: that would help drive the software industry to stop shipping beta versions as though they're final releases.
 
Back to the specific subject of software and codecs, I agree completely with the idea that the software should be open source. For all the reasons stated earlier in this thread, it will only help Red.

I see the software as simply being a technology enabler (not unlike a driver), that allows far more people to enjoy the quality and flexibility of the Red camera. Closing the software off to just those that purchase the hardware, or forcing others pay extra, is a flash back to the old Media 100 days (and we know where that lead...). Whereas opening it up only expands your awareness and eventually your profitability. IMO obscurity is the biggest hurdle to profitability.

And I'm speaking from the perspective of somebody who's pre-ordered and will get the software either way.

Jeremy
RED #63
(Long time lurker, first post.)
 
thats a tough call Jeremy.. great first post. I half agree with you.. I think the codec should be free.. but I dont think it needs to be open source. I love the Media 100 reference.
 
Lowkus said:
IRS definitions can be pretty weird. I'll walk that line with extra caution if I ever get an income going.
Click to expand...

well that pretty much answers whatever confusion was rolling around in my mind about where you were coming from... I wish i could go back to those days of not needing an income. Well maybe not.

Its clear though now why you want everything for free though...
 
Just posting to let the people on this thread know that I've been burning out my wrists from all the debating, so I'm going to stop posting anything for a while to avoid aggravating my tendonitus any further. If I don't respond to your posts, don't get offended or anything.

G'Night Everybody!
 
Thanks.

I think I still agree with Glenn. By going full open source, it allows others to learn from Red's efforts and build upon them, resulting in even better quality, better workflow options etc.

But then I suppose my opinions about open and free software are probably a bit different than the average filmmaker. As an example, I'm a big supporter of the concept of Creative Commons. We just released our first documentary and it was released under creative commons simultaneously commercially and as a legal bittorrent. ( www.donetheimpossible.com if you are curious. And for the record, our daily sales quadrupled after we released on Bittorrent. For the extra curious we shot our doc in HDV on Sony and JVC cameras, though I was wishing I had my Red camera...)

However, if not open source, then the API should be wide open. So that others can write software that works with the RAW data with or without Red's help.

Jeremy
RED #63
 
maybe i'm missing something here .. REDcine converts files into another file ( provided you have the codec ) so exactly how would open source apply to REDcine ?
 
True enough. Except at that point it's no longer RAW, and you've lost a big chunk of the image data. Allowing other software access to the RAW data is important in my book. (Personally I'd love to work with RAW files in After Effects) If I'm missing something here, please do tell, the workflow is still a tad fuzzy for me.

Jeremy
RED #63
 
maybe i'm missing something here .. REDcine converts files into another file ( provided you have the codec ) so exactly how would open source apply to REDcine ?

You could make one or all components (Redcine, the Redcode codec) open source. This is slightly different from making the spec available (making the source code open source implies making the spec available, although you can make the spec available without going open source).

By making the spec to Redcode available, 3rd party companies could sell better de-bayering codecs.
If you made Redcode open source, then you might get volunteers or other camera companies improving upon the code. It doesn't make that much sense for people to constantly re-invent the wheel. However, de-bayering methods may be somewhat specific to each camera since it depends on OLPF.

On the workflow tool side, making Redcine open source would really allow others to add innovations. NLE vendors for example could integrate their XML/EDL/AAF export for an efficient online/offline workflow. Because it always ends up happening that conforms don't work out precisely (XMLs, EDLs, AAFs rarely work perfectly).

On dvinfo.net, I was mentioning how a Red deck with SDI out and deck control is useful for high-end finishing work (because a lot of the highend systems run on Linux and may not necessarily have Redcode available). Perhaps a better solution would be to:

A- Use Redcine, spit out lower rez offline copies.
B- Finish offline.
C- Spit out EDL or AAF or XML.
D- Import that into Redcine.
E- Redcine exports an EDL/AAF/XML and two sets of still image sequences. Or whatever formats work best for the finishing system in question.

Things like AAF and XML can be vendor-specific, and these formats would ideally be implemented into Redcine.
 
You must log in or register to reply here.
Back
Top