Ever thought about making the whole empeg-software Open Source ?
It would be much easier to find/fix bugs and to develop external software for the empeg.

bobo

We've thought about it, yes, but the software is our competitive advantage. A big OEM could replicate the hardware, but without the software (which we've been working on for a long time) the unit isn't much fun.

Sorry, but hardware isn't really our business - it's software. The hardware just runs the cool stuff we come up with :)

Hugo

You should know, that lot's of your customers would be interested in your product,
because of the hack value it could bring. Think about all the slashdot nerds (me included:),
who just registered, because they not only want to hack their PCs, but also their car radios.

Take an example from other successful open source companies, who can survive,
because they provide the hacking platform, and care for the product.

Keep close to your customers!

Raphael Wegmann
wegmann@psi.co.at

It's not quite the same as people like RedHat, who open source their additions to linux. We're happy with people hacking the product, and are working on publishing APIs to talk to the player software - there's nothing to stop people writing their own open-source player if they want. Open-sourcing the player, however, would mean we'd leave ourselves very open to get trampled by larger manufacturers cloning our product (totally legally).

Hugo

This is exactly where the Open Source movement falls apart... for people to actually make a living with things like the empeg then it can't be totally open source...

Guys at Empeg... keep up the good work and grab the cash whilst it's flowing... good on you...



- Given two theories.... pick the one that sounds funniest -

RedHat Linux is theoretically more endangered to get "cloned" than your product, because all they really sell are CD boxes. You can still sell your hardware, if (which is very unlikely) someone else branches of a better player. Red Hat is actually pleased that people came up with Mandrake Linux, because under the GPL, Red Hat can incorporate the improvements.

Yes, there is something that stops prople writing their own player: The display API.
As soon as you release that, chances are high, that people WILL develop a better Open Source
player on their own. But by then you already have lost sympathy and people will try different players.

It's not the Licence that will protect your business, it's your support for open development.


Raphael Wegmann
wegmann@psi.co.at

The display API is already open, you just open /dev/display and memmap it (there's an ioctl to blat the image to the screen, this is in the kernel source which is rolled into the SA1100 patchset).

If someone writes a better open-source player - great, we'll use it ourselves. I don't think it's likely one will appear in the next 6-12 months though, it's not a small job.

Basically, hardware can be cloned in short periods of time and legally - especially if you've got money to throw into development. Software is much harder. Relying on hardware sales is dangerous, unless you're in a market where there simply isn't room for other companies to enter the market - things like scientific equipment, for example.

Remember, redhat make most of their money from support, not from product sales - people aren't really used to paying for support on a car radio (and we'd have to ship a LOT of hardware to make a living from support). We don't make a killing on the player hardware either, which suprises some people. The realities of custom design, low volumes (ie, we don't buy 100,000 ram chips at a time), and so on doesn't lend itself to making cute custom products, which is why you don't see a lot of people making low-volume things like this.

Hugo

Hmm ... the display API is open, but how can I quit the player and to run my own apps? Any way to program the buttons?

You don't fear a better Open Source player? I thought OEMs could clone your
hardware and you'd be out of business?

Don't get me wrong: I very much like your radio (hardware and software),
and I think that you guys deserve to get rich. Really. I believe you,
that commercial success is not easy, even with such a great device you developed.

But I'm sure you can gain market share, if you release the source of your software. Think about the OS your player runs on. Your software would develop much faster, so that nobody would ever buy an mpeg car radio from any different source. The areas one can use your device are nearly endless. In the future you could not only release your player, but a whole empeg application suite.


Raphael Wegmann
wegmann@psi.co.at

If you open /dev/ir you'll get button codes as well as IR - both get decoded. Read 4 bytes at a time, though.

We don't fear a better open source player because we believe we could stay significantly ahead - and time is of the essence with digital audio technology now: 12 months is an age in this market.

Basically, for reasons that shall become apparent in the near future, we don't belive it is in our best interests to open-source the player. As it is at the moment, our dedicated team can advance the quality and featureset of the player faster than it would happen outside - there's a very steep learning curve. It's useful to be able to make unilateral design changes as needed during this stage of development, something which is hard when the source is being worked on by many.

We're also in the position that we can't make the units fast enough as it is. We don't want to get even more people in line if we can help it. If it comes to pass that we believe we *can* gain market share by releasing the source, we'll definitely consider it.

Hugo

Hugo said....
> If you open /dev/ir you'll get button codes as well as IR

Hmmmm.... if /dev/ir was renamed by a custom application to something else and the application created a fifo in it's place, could the custom app read all codes, use the ones it wanted to, and pass the others through the fifo to the player?

Cheers,

Mark.

Hmmmm.... if /dev/ir was renamed by a custom application to something else and the application created a fifo in it's place, could the custom app read all codes, use the ones it wanted to, and pass the others through the fifo to the player?

Yes.

At least I can think of no reason why not.

There's an ioctl to make beeps too which I think may come in useful if my guess for why you want this is correct :-)

--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

Maybe you're right, and there will never be an equivalent Open Source replacement for your player, because lots of "techies" won't buy your player as long as you don't publish your source.

Please at least try to help us code our own stuff for the radio. Most of us won't want to replace the player, but develop other fancy stuff for their radio. Please publish ready built cross compilers and document the APIs in all details (with examples), as it will raise the value of your car radio.

If you'd publish the source for the player, you wouldn't compete with your coding customers;
as you'd be the undoubted maintainer of the player, which means that you can (and should) advertise your design goals and refuse patches you don't like.


Raphael Wegmann
wegmann@psi.co.at

I think you may be overestimating the percentage of purchasers (or would-be purchasers) of this product who would fall into the "techie" category. At this early stage in the development, I suspect the techie interest is relatively high - but once this product goes mainstream, so to speak, I would be surprised if one purchaser in a hundred was even remotely competent with basic Unix/Linux commands, much less capable of or interested in writing application software for his radio. I know that I'm not, and I am more computer-competent than most people I am personally acquainted with.

The market demographic that empeg is aiming for is NOT the computer geek - it is the audiophile. There are orders of magnitude more people out there wanting to buy a state of the art music player for their car than there are people who want a mobile computer that happens to play music.

That said -- thanks to both you and Hugo for putting up one of the most interesting, entertaining, and informative threads to date on this BBS.

tanstaafl.



"There Ain't No Such Thing As A Free Lunch"

Mike said....
>
> There's an ioctl to make beeps too which I think may come in useful
> if my guess for why you want this is correct :-)

You're probably right. :)

You don't happen to have a mkfifo binary anywhere that you could bung on the player do you please so that I can try out this approach?

Cheers,

Mark.

How many people would you have expected coding an OS?
Even if it's just a small percentage, if the sell rates go up, that percentage can become a huge number. Besides there are a lot Open Source apps out there, which just need a little porting and adaption. A lot of great ideas have been mentioned in this BBS.

I can't see a conflict in expanding the capabilities of your car radio and enjoying the music it plays.


Raphael Wegmann
wegmann@psi.co.at

Although the player isn't open source we're certainly *not* preventing you from writing other apps, or (when we document the APIs) adding to the player itself.

The empeg as-is will never sell to a huge market, so the developer percentage will remain small - real geeks don't like paying for hardware anyway :) Problem is, a mass-market empeg-style product would be quite cut down, and so would appeal to less geeks anyway :(

Hugo

You don't happen to have a mkfifo binary anywhere that you could bung on the player do you please so that I can try out this approach?

Attached. I've put it in the developer image ready for the next release. Some people may have noticed that the developer image in beta6 is quite a bit bigger - I've added all the tools from the tools package on the website.

Also, the IR codes are four bytes - you will not be able to read any less. I may change the way codes are sent so that the player knows if there has been a repeat code so only use the low sixteen bits for now :-)

--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

Mike,

What is the beep ioctl and device?

Cheers
Steve

I've sent the details to the maintainer of the "All Things empeg" website at http://www.empeg.mars.org/.

--
Mike Crowe
I may not be speaking on behalf of empeg above :-)

And I've sent a piece of code to make little beeps when you press buttons/use the remote also. Thanks for the help Mike.

Cheers
Steve

"We don't fear a better open source player because we believe we could stay significantly ahead"
Hmm... I'm not so sure IMHO.
There are roughly 20,000 Microsoft employees and there products are full of bugs, holes, security flaws and other issues. Anyone who wants to help improve any open source programs can (Linux). As soon as a bugs are found, they are squashed. The code is always improving due to the sheer number of people working on it, and this worries MS (see the Halloween documents).
Open you source code - let everyone in the world look at it, improve it, optomise it, debug it and send it back.
What you end up with is solid, fast, small, efficient, flexible, powerful code for your hardware.
Combine this with updates for registered users and you have a winner.
I would gladly pay more for a hardware that has software support like that.

The numbers are rather different for the empeg: we have fewer "developer-quality" owners and more consumers, and as has been mentioned before, we have other reasons for our software to stay closed source, like other customers.

We're also not microsoft :)

Hugo

At the risk of sounding biased, I should point out that consumers benefit from open source too. Even if most consumers have no intention of ever looking at the code, they still benefit from the fact that others have. "Given enough eyeballs, all bugs are shallow."

Not only do developers help you find and fix bugs, but they offer the potential of contributing new features.

Naturally, there is a cost associated with developing open-source style, namely documenting and answering questions about the code, managing all the incoming contributions, reviewing them and deciding which ones to apply to your baseline, and making regular snapshots available to the community. Maybe this additional work isn't in the best interest of Hugo, et al. at the present time.

As long as I'm making my bias known I might as well say I'm not convinced the empeg's best market advantage will be its closed source software. Sure, anyone could duplicate the hardware (after some significant effort, I'm certain) and produce something to compete, but if that competitor makes the software open source, guess which unit I'm more likely to want to have? I'm not just speaking as a developer, but as someone who understands the real benefits of open source. Now, if the empeg's software were made open source today, it would have an immediate advantage over any future competitor because of the time investment developers will make in it.

That's enough soapbox for today; I'll go back to hacking on my empeg.

The point is, hardware effort is low when compared to software. Few potential competitors, looking towards the large consumer electronics companies at least, are likely to open-source the software on what is, essentially, a consumer product - there aren't a lot of open-sourced video recorders for example.

What I'm trying to say is that our software (and the software/hardware package) is our key IP package for potential licencees. If we give away the software, licencees could just take the software, copy the hardware and with their superior manufacturing experience and expertise blow us totally out of the water: we are *not* primarily hardware manufacturers, and when it comes to shifting boxes we'd lose against a big player.

However, we *do* produce good software and reference designs, and it's in this area that we expect the future to lie - this isn't to say we're not continuing to develop the empeg unit, as this has more I/O, cpu power and twiddly bits on it than any OEM would be happy to put on a mass-market box (and it's a great showcase for the flashest stuff we come up with) :)

Open source just isn't really viable when there are any number of hugely-larger hardware manufacturers who could clone the design and remove any income from the prime developer: we'd starve. Selling support isn't an issue on a consumer product - unlike businesses, consumers don't feel the need to pay for support (especially non-mission critical support).

Hugo

It's a pity there aren't any open source video recorders - I might be able to program mine if I knew how it worked :)
If the software was released under the GPL the OEM's would be legally required to ship the source code with the unit. Any improvements people make to that code could be collected by you for inclusion into your product (I doubt if OEM's would go down that road).
IMHO you are not in competition with the big players anyway, certainly not at the moment. In the future the large Japanese firms will start producing mainstream MP3 players - they've already started. The only thing differentiating you from any of them will be features and quality. Quality is an easy one - you only produce small numbers of units and I am sure (from what I have seen) that quality control is high. The best wasy to make the software better is to get all those who want to be involved the chance to be involved - open source.
In Australia, there is a local manufacturer of amplifiers branded ME. They are a small company in Sydney producing small numbers. Every until that goes out the door is personally signed by the owner. The quality, finish and performance is outstanding and as a consequence they have trouble producing enough for the demand. I was lucky to get one. The point here is that they are not competing with the large players and found their market. It's not hard to pull apart an amp to copy the internals - but no one has done it and probably never will. Besides, I doubt if any manufacturer would be interested in tackling the potentially large amount of support needed for such an esoteric item.
But far be it of me to suggest how you should run your company - I'm on the other side of the world !! :)

The fact that the OEMs would have to ship source if they used an open-source player is beside the point: the point is that we wouldn't get any recompense for our efforts (and hence would have no reason to continue developing the player).

Given the choice between an open source player and a closed source one, an OEM is likely to choose the closed source variant as it could give them an advantage over their competitors. Shipping an open source version would mean that they instantly lose any lead they have: open source levels the playing field to being a fight over hardware, and small companies don't (because they can't) fight over hardware. It works for linux because the hardware became commoditized a long time ago.

A small company making amps is not a good example: amps (as with a lot of high-end gear) are a matter of taste - in cambridge we're surrounded by esoteric hi-fi manufacturers like Arcam, Cambridge Audio, Tag-F1, etc. The reason why they're not cloned by large volume manufacturers is that the components they use are specially selected, probably hugely expensive, and so on: if their lead in the market was a no-cost software upgrade that could be applied by any volume competitor to their product and result in the same sound they *would* be dead. Why pay the money for a low-volume high-cost system when a mass-produced low-cost one gives exactly the same results (tonal quality, balance, soundstaging, whatever)?

Hugo

I have a simple solution. Why not NDA people who are interested in doing development?

I don't think this is so much a licensing issue as one where people want access to the code to make improvements or bug fixes. If they're NDAed, they can get the source and hack all they want, but they can only share the changes with you guys, who can then integrate it into release images.

Or, have a seperate "Open" image, which the NDAed people can hack away on. You could then continue development of your internal software and the budding developers could have a seperate source stream to work on amongst themselves. No software gets out to the general public - you're happy. The hackers who agree to the NDA get source - they're happy.

Everyone's happy!

My final comment ....
http://www.opensource.org/open-jobs.html

...a bit circular, the thread started with that and I explained why it doesn't work well for us, a unique hardware vendor.

Hugo

But you yourselves make the claim that your hardware isn't unique.

What I think is really the issue here is *credit*. If you open up the software, even in the method I described before, you'd dilute the credit you'd receive for developing the product.

Using NDAs, you have nothing to lose, yet you still remain staunchly against sharing the code. I personally don't care - I couldn't program my way out of a paper bag - but I've seen how open source makes for quality code in short periods of time, so the "credit" thing is all I can see as a reason.