Poll: Would you buy a printed/packaged Ros-cd in support?

[Z98]

The guy seems to be missing the entire point of the GPL based on his arguments. Of course the BSD is more permissive than the GPL. The GPL was not intended to be permissive whereas the BSD was. As such, what is the relevance of the BSD being more permissive? If you want the permissiveness of the BSD, use the BSD. All of the restrictions that he mentions the GPL imposes that somehow make it less 'free' were intentional on the part of the GPL drafters. If you wish for your code to be under the restrictions of the GPL, use the GPL. The BSD is better at its intended goal while the GPL is better at its intended goal. When those two goals are so different, neither can be considered better than the other outside of your own personal views/opinions.

And check your inbox. I basically laid out the conditions and the basic reasoning behind them. Note that the level of oversight we would require is pretty much set in stone. The things that are negotiable are the design and the printer, insomuch as both sides would need to be happy before anything happens.

[Webunny]

The guy seems to be missing the entire point of the GPL based on his arguments. Of course the BSD is more permissive than the GPL. The GPL was not intended to be permissive whereas the BSD was. As such, what is the relevance of the BSD being more permissive? If you want the permissiveness of the BSD, use the BSD. All of the restrictions that he mentions the GPL imposes that somehow make it less 'free' were intentional on the part of the GPL drafters. If you wish for your code to be under the restrictions of the GPL, use the GPL. The BSD is better at its intended goal while the GPL is better at its intended goal. When those two goals are so different, neither can be considered better than the other outside of your own personal views/opinions.

And check your inbox. I basically laid out the conditions and the basic reasoning behind them. Note that the level of oversight we would require is pretty much set in stone. The things that are negotiable are the design and the printer, insomuch as both sides would need to be happy before anything happens.

Ah, yes, found it. It was in my spam-box, probably due to the nature of the title.

Edit: for people thinking this has sizzled out; this is not the case. We're still in discussion, and there seems to be no fundamental problem, so I'm fairly positive. It does go a bit slow, however, since the de facto communication seems to be 1 or 2 mails max per day. But better sure, albeit slow, than rushed but with miscommunication, I guess.

[swight]

Here is a thought if it doesn't further dilute the issue. Maybe call it "ReactOS Community Pre-Release Edition" or something similar.I would avoid using the ReactOS version numbers in the name as this could cause a lot of confusion. Leading to questions like "do you mean ReactOS 3.14 or Community PreRelease 3.14? Though it should still mention somewhere what trunk builds are used just in smaller print.

And also use a recent relatively stable trunk build rather than 3.14. Another way to make it special would be to do something like a multi-boot CD with current versions of the main branches included like arwinsys(hope I spelled that right). It would be an added value as not everyone knows how to make a multi-boot CD even assuming they had the software to pull it off. assuming of course this hasn't already been done as I have been gone awhile.

Semi-related Off topic rant:
This could also have the benefit of giving people a pseudo-release version that could be used as a reference point for testing. It would also kinda give an illusionary peace of mind to those that shy away from trunk builds. You could have it publicly noted on the site which trunk versions matched the CD so developers would know what they were testing against.


This could be done in such a way that these versions could be released after notable features are included without increasing the main version. This way newer features get more testing than they would otherwise before the next version is released. This should be just the trunk build it claims to be without hack/fixes after it is picked and have a disclaimer mentioning this. It should only be tested that it works at least as well as the previous version so people don't feel like they downgraded and that the new features/enhancements work with at least one program or maybe common piece of hardware(like in the case of USB) so they can be demonstrated as the reason for the release. This would allow for this to be generated without unduly holding up development as much and developers would know exactly what they are dealing with and not worry about hacks effecting the tests.

This type of set-up could possibly help PR as we can say (insert version) of ReactOS can now do (demonstrable reason for release). I doubt it works very well if you have to send who ever you are talking to to the trunk version which at any point in time could cease to function. And the definition of "get the Latest Trunk build" changes with time,you can get two completely different versions.Also it begs the question of "Why are you telling me about something you haven't found to be worthy of releasing on your front page?".

[Webunny]

Here is a thought if it doesn't further dilute the issue. Maybe call it "ReactOS Community Pre-Release Edition" or something similar.I would avoid using the ReactOS version numbers in the name as this could cause a lot of confusion. Leading to questions like "do you mean ReactOS 3.14 or Community PreRelease 3.14? Though it should still mention somewhere what trunk builds are used just in smaller print.

And also use a recent relatively stable trunk build rather than 3.14. Another way to make it special would be to do something like a multi-boot CD with current versions of the main branches included like arwinsys(hope I spelled that right). It would be an added value as not everyone knows how to make a multi-boot CD even assuming they had the software to pull it off. assuming of course this hasn't already been done as I have been gone awhile.

Semi-related Off topic rant:
This could also have the benefit of giving people a pseudo-release version that could be used as a reference point for testing. It would also kinda give an illusionary peace of mind to those that shy away from trunk builds. You could have it publicly noted on the site which trunk versions matched the CD so developers would know what they were testing against.


This could be done in such a way that these versions could be released after notable features are included without increasing the main version. This way newer features get more testing than they would otherwise before the next version is released. This should be just the trunk build it claims to be without hack/fixes after it is picked and have a disclaimer mentioning this. It should only be tested that it works at least as well as the previous version so people don't feel like they downgraded and that the new features/enhancements work with at least one program or maybe common piece of hardware(like in the case of USB) so they can be demonstrated as the reason for the release. This would allow for this to be generated without unduly holding up development as much and developers would know exactly what they are dealing with and not worry about hacks effecting the tests.

This type of set-up could possibly help PR as we can say (insert version) of ReactOS can now do (demonstrable reason for release). I doubt it works very well if you have to send who ever you are talking to to the trunk version which at any point in time could cease to function. And the definition of "get the Latest Trunk build" changes with time,you can get two completely different versions.Also it begs the question of "Why are you telling me about something you haven't found to be worthy of releasing on your front page?".

Interesting thoughts, albeit I'm not too keen on selling trunk versions: there are way too many of them, and I'm only planning to print discs a few times a year, not every day. Thus, we need special releases, not just a run-of-the-mill trunk one. Those are the bigger version numbers, like 3.14, 3.15, etc. Now, saying 'alpha 3.14' and 'not ready for everyday use; but for testing purpose only' or something of the sort, will be enough to stem any confusion.

The argument about not going for 3.14: I've heard it many times before, now. And, on itself, I agree; it would be more useful if it was a 3.15 or later, BUT that's really not the point, here. First of all, I want a general repetition; to see how things pan out, on the chain of making it, selling it, distributing it, etc. That's why the small amount of CD's comes in handy; if anything goes wrong, let's say the thermal print is really subpar, and z98 and I decide not to use them, I'll be taking the losses, but it won't be gigantic (and we'll know not to use that printingservice in the future). For the 3.15, which will be a major new release, I plan on making 100 to maybe 500. If things THEN have to be ironed out and checked, it's going to be cumbersome and if things turn wrong, a lot worse.

Secondly, the 3.14 (and all alpha en even beta releases) are not meant to actually be able to do 'great things' on real-life hardware. The actual functionality is of lesser importance - which is rather normal, for alpha releases. In essence, the selling of printed CD's is still mostly a show of support and sponsoring, where you get something nice and shiny back, but it's not like you're doing it to actually be able to run it on your machine; if it's purely for that, one could as well burn it yourself on your own CD (like we're doing now).

[swight]

Just to be clear I never said anything about making CDs of ALL trunk releases, only those with user noticeable improvements that have been tested to make sure are indeed better than the previous release which aren't extremely common or if they are more common than I think the releases don't have to be after every new improvement. Though I admit this part of the idea could be done just as well without the CDs.

On the rest of it we have somewhat of a difference of opinion. While functionality may not be deemed important in an alpha/beta release I think relative functionality is. There is a difference. I also think part of the audience for CDs are those that may not know how to burn CDs(they do exist,especially if referring to the multi-boot CDs I mentioned before) but are interested in seeing what ReactOS can do after hearing about it from a third party.

Other possible purposes if my other thought was followed(not necessarily as CDs) is to provide a single more recent point on which newbie testers(who may not know about or fear the trunk) can focus and thus reduce reporting of bugs that have already been fixed.Saving developers time. It would provide PR something to work with. These would in theory be a selling point to the Foundation.

On the Multi-boot idea I do admit that it has limited time period for sales potential as there has been talk of something similar(both in a single boot iso with option to select) and it may just be a matter of time before that makes it irrelevant. To be honest that is how I thought of doing a multi-boot CD.

[Webunny]

Just to be clear I never said anything about making CDs of ALL trunk releases, only those with user noticeable improvements that have been tested to make sure are indeed better than the previous release which aren't extremely common or if they are more common than I think the releases don't have to be after every new improvement. Though I admit this part of the idea could be done just as well without the CDs.

On the rest of it we have somewhat of a difference of opinion. While functionality may not be deemed important in an alpha/beta release I think relative functionality is. There is a difference. I also think part of the audience for CDs are those that may not know how to burn CDs(they do exist,especially if referring to the multi-boot CDs I mentioned before) but are interested in seeing what ReactOS can do after hearing about it from a third party.

Other possible purposes if my other thought was followed(not necessarily as CDs) is to provide a single more recent point on which newbie testers(who may not know about or fear the trunk) can focus and thus reduce reporting of bugs that have already been fixed.Saving developers time. It would provide PR something to work with. These would in theory be a selling point to the Foundation.

On the Multi-boot idea I do admit that it has limited time period for sales potential as there has been talk of something similar(both in a single boot iso with option to select) and it may just be a matter of time before that makes it irrelevant. To be honest that is how I thought of doing a multi-boot CD.

People who can't even burn a CD are going to test Ros aplha-releases??!

That's really not the intended public, *certainly* not for this first limited 3.14 trial. I mean, let's face it: if they don't even know how to burn a CD, how are they ever going to get a VM like Virtualbox working, let alone connecting to Putty and all that? And on all alpha-releases, there is going to be clearly communicated it's not ready for prime time/daily use, and it's for testing purposes only. I doubt if they can't even burn a CD, they be testing Ros, so that's not the targeted audience. And it's obviously still not ready for out-of-the-mill hardware use; when I tried it, I had a successrate of 25% to get it working (meaning, 3 of the 4 PC's I tried it on, failed). Everyone should know it's not meant to run easily on real hardware, yet.

And while I understand your concerns, it seems to me they are largely unwarranted for this first batch. I'm only going to make 25 of them (3.14), as additional signs of support and sponsoring. We already have 22 people indicating they want to buy one. Now, I'm pretty sure at least HERE the Ros-fans and enthousiasts know perfectly well this is an earlier alpha release and not ready for prime time yet, and are perfectly capable of burning a CD as well of testing it. Thus, while the 3.14 will offer less functionality than trunk or the3.15 (obviously), for the targeted audience this really won't matter.

But anyway, I appreciate any input given on the matter. Feel free to give other suggestions or remarks if you have for this or future releases.

[milon]

I'm going to reiterate that I'd really like to see something more current than ROS 0.3.14 on the CD. If this is for testers only, then using a current build should not be a problem at all. The current trunk builds are far more stable & compatible than the last public release. Also, myself and some others voted Yes but indicated we're much more interested in something that's more usable than 0.3.14. You don't have to do this, of course, but I'm much more likely to support a current build than an old release. If you still want to go with an old release, could you explain why?

[swight]

while(addressing first paragraph and not applying to the trial run scenario)
{
while it may only work on 25% of PCs with each new release comes the question "Does it do what I need it to yet? " or "does it work on mine now? ". If we didn't have people asking these questions we wouldn't have anywhere near the same number of testers or users. If they aren't asking these questions they are either organized(testing/coding work assigned to them) or have given up on us(at least until certain arbitrary criteria are met).

A reason to use a trunk build instead of 3.14(of course 3.15 is better than both on this point,just can't tell how long till it is going to be released) is to have more users able to say yes to both of those questions. And as more people are able to say yes to those questions more will decide to stay with us and in the process provide us with more bug reports to help make the system even better so we get more yes's to the above questions perpetuating the cycle.

Also alpha means almost nothing in our situation. If someone decides they want to drop(as in I'm leaving and not coming back) Microsoft and they don't want to go to @pple they are left with two basic choices Linux or us. Linux with it's history even if they are better now have the stigma(which they have worked hard to eliminate) of being a hard to use geek only operating system. To put it simply to users that are new to Linux it will likely feel very alpha to them. Partially because it requires a different mindset to use. We offer a system that is not only compatible with many of their programs but also their mindset. So it basically becomes alpha vs alpha and alpha -alpha = 0 so basically no difference. Though I admit that this is a bit oversimplified. But suffice it to say we have a psychological advantage where people may not care that we have alpha status as long as the operating system can fulfill their needs.

Emulation is a moot point(on main releases) as we already have downloads already where users just have to double click a batch file to get it up and running. and the testing I am referring to definitely does not require Putty. Basically noting "hey this program doesn't work and it stops when I do this at approximately this point" and maybe include a screenshot if they are able to. From here your Putty experts can go in and verify it rather than randomly coming across it later if at all.
}//End While tempted to use semi-colons

//Bad(or good depending on your point of view) programming joke
//hopefully understood by non-programmers^^

(Here are some scenarios for a target audience that burns their own CDs)
(user only interested in releases)
3.14- user has probably already burned a copy by now(been out for a couple of years),but now he has a pretty duplicate.
3.14 trunk- useful and pretty til the next release.
3.15 -pretty and useful unless too impatient to wait for shipping in which case pretty duplicate.
(user who burns trunk builds)
3.14 -has the latest copy,but now he has a pretty copy that is outdated and will never be used.Might as well be blank.
3.14 trunk - pretty and might be useful for a little while until it gets too out of date
3.15 -pretty and might be useful for a little while until it gets too out of date

[Webunny]

I'm going to reiterate that I'd really like to see something more current than ROS 0.3.14 on the CD. If this is for testers only, then using a current build should not be a problem at all. The current trunk builds are far more stable & compatible than the last public release. Also, myself and some others voted Yes but indicated we're much more interested in something that's more usable than 0.3.14. You don't have to do this, of course, but I'm much more likely to support a current build than an old release. If you still want to go with an old release, could you explain why?

There is no discerning quality of a nameless trunk-build. You don't see any other open-source program being shipped with intermittent trunk- or nightly builds or whatever. Normally, only major releases are printed. Even when it's alpha, this remains true. And while it's also true - and I agree with you and other posters on this - the 3.14 is less good than trunk or, obviously, 3.15 will be, and thus its worth as a testing ground a bit obsolete, one should mainly regard it as a collectors' item, and an additional support for Ros. And as a general rehearsal, of course - though this can be accomplished by a trunk build too, I guess. I don't feel an anonymous trunkbuild is in any way a 'milestone' or point of reference, in the development of Ros, worthy of a CD-print of its own. There is coming out a new build in trunk every day; it's useless to consider one build a point of reference and the next one not. Even if one would go with the idea that it should be a build with important improvements, one has the next-to-impossible task of agreeing which 'feature' or 'bugfix' is important enough to be worth a print, and which not. And even if one would decide just to use 'the very latest'; by the time it's printed, there would be yet another dozen new builds, with no-doubt many improvements, which could be even far more important in comparison.

The point of it being 'less useful' in regard to newer builds, thus, is always true. As for being 'useful' in general, this is inherently subjective; for an alpha, I found even the 3.14 moderately useful on real hardware, and pretty useful on VM already.

And I also don't fancy the idea of placing a (in essence pretty plain) buildnumber on the CD that means very little ultimately, since such a number has far less broad appeal than the number of a major release. (If this was not true, we wouldn't get extra PR for major releases, but for every buildnumber; clearly, this is not the case). There is also no defined timeslot, then: there is no reason to print one trunk-buildnumber, and not the next, so instead of printing on clearly defined periods of times (when a new major release happens), I could as well be releasing 52 CD-print releases a year, with the same validity. But I am not planning to do that, and there is no discerning quality to pick one out of the numerous trunk-builds, contrary to major releases.


I'm not denying you and some other posters have very good points from a technical point of view (I largely agree with them), but in regard to marketingpurposes and PR (and common practise) in general, it's simply not done to have a random daily build make into a CD-print, and not a major release.

But look, I'm not forcing anyone. People should see it as a collectors' item and a way to support Ros, and not focus on the latest functionality for this first run. But those who do find the latest features of primordial importance, they can wait on the 3.15 version. Speaking of which: I would very much welcome any remarks or suggestions to improve upon the printing/selling/packaging/etc. of those that have bought a 3.14 version, so I can take this into account for the 3.15 release.

[milon]

I had forgotten this is also a "test run" for larger future CD prints. That's an excellent reason for going back to 0.3.14. And you're right about build numbers, too. I can see where you're coming from now, and that's exactly what I needed. If/when the details are all worked out, you can count on me to support ROS!

[Bblaauw]

Hm poll expired already and nowadays I don't visit the forums much anymore. Anyway, count me in for purchasing a disc, if you manage to sort out the requirements as set out by ReactOS representatives.

Curious about the formfactors and artwork though.

Formfactor:
1) DVD-case (quite strong plastic). Preferred I'd guess?
2) CD jewelcase (cracks easily)
3) cardboard envelope?

Packaging artwork:
* outside only?
* inside booklet?

Disc(s) artwork
* pressed CD (DVD? Bluray?) ?
* labeled CD?
* lightscribe/disktattoo/whatever?

Disc number
* only one disc containing installalion
* only one disc containing LiveCD
* only one disc containing both ( a la Linuxtag, added to 0.3.14 downloads at http://sourceforge.net/projects/reactos ... OS/0.3.14/ instead of separate entry. Drawback: most likely German locale specific)
* multiple discs, of which at least 1 installation and 1 LiveCD

This is a nice initiative. Next up, USB sticks?

[Webunny]

Hm poll expired already and nowadays I don't visit the forums much anymore. Anyway, count me in for purchasing a disc, if you manage to sort out the requirements as set out by ReactOS representatives.

Curious about the formfactors and artwork though.

Formfactor:
1) DVD-case (quite strong plastic). Preferred I'd guess?
2) CD jewelcase (cracks easily)
3) cardboard envelope?

Packaging artwork:
* outside only?
* inside booklet?

Disc(s) artwork
* pressed CD (DVD? Bluray?) ?
* labeled CD?
* lightscribe/disktattoo/whatever?

Disc number
* only one disc containing installalion
* only one disc containing LiveCD
* only one disc containing both ( a la Linuxtag, added to 0.3.14 downloads at http://sourceforge.net/projects/reactos ... OS/0.3.14/ instead of separate entry. Drawback: most likely German locale specific)
* multiple discs, of which at least 1 installation and 1 LiveCD

This is a nice initiative. Next up, USB sticks?

With the caveat that nothing definite has yet been decide, though negotiations are going well (but I can't proceed in this without a clear yes)... I'd like to answer some of these questions:

From the viewpoint of aesthetics, I prefer the cardboard sleeve. It's compact, can be readily printed in full colour, and I just think there's a ring to it. My preference is partially subjective, of course, but still, it's my personal, preferred first choice.

Alas, reality and pragmatism supersedes my own wish in this case. The fact is, cardboard sleeves are hugely expensive, in such small numbers. It only becomes competitive with other formfactors when it gets 100+ examples being printed.

My second preferred is, indeed, the DVD-case, for the reasons you correctly stated. Also, it's easy to make a full colour cover for it, and to add a booklet or flyer or something. And, it's far less expensive than a cardboard sleeve, even in small numbers.

So I would normally go with this one, but...the problem is: shipping. Some of our Rosfans here come, say, from the USA. The DVD box does not fit into a regular envelope. A special one, however, costs 3 times as much, and would bite a giant piece out of any profit for Ros, comparatively to the price of 10 euro's, which was the foreseen price-setting for a normal CD.

Another option would be, to go for a slim-line jewel-case. This would fit into a regular envelop, and it's cheap too. But I find it rather fragile and aesthetically far less appealing.


My thought, thus, go in two directions: either we make it a normal CD for 10 euro, is it in a slimline jewelcase without any flyer or booklet, just frontcover (no backside-cover neither, on a slimline jewelcase), or, we go for the more robust and prettier DVD-case, but make it a real 'collectors' item', with full-colour cover, and a lil booklet of minimum 4 pages, with a short description, some history, a thank-you, maybe some quotes from the devs, etc. and ask, say, 15 euro for it.

It's the bare-minimum approach with minimal profit for Ros - but at the price originally said, versus the more elaborate 'grand' view of making it more like a special item (it sure has the limited amount of printing/offer to be special ) for 15 euro, and more profit to Ros.

My personal feeling is, we should rather go with the 'collectors' item' approach, and flesh it out a bit more, and ask more too, then. But of course, the poll DID say '10 euro max', so I'm not sure all who showed interest in buying one for that price, would still buy it. On the other hand, there have been posters explicitly stating I should make a 'special collectors' item' CD, so maybe it would be popular enough after all. And heck, I was going to take a risk anyway, so... maybe I'll go for that. But I sure would like to hear the take of other fans on this.

As for the discs: for this first run, this will be only an install-CD, alas. A separate live-CD would require another master CD, and thus, a new and separate 25 burn&print job, effectively doubling the costs. And asking 30 euro's does seem a bit steep. I very much like the idea of a combined install-live CD, however. Obviously, it would combine the benefits of both, and yet only require one master-CD. But I don't believe there is a good one for the 3.14 version? If there is, or there is going to be made one (but that would require persuading the devs) I would use that. If not, I really, really hope the devs are going to make a combined one for the 3.15 version.

The artwork will be based on the excellent work of bntser, which you can find somewhere on this forum. There are still some changes to be made, which z98, I and bntser are discussing, but you can get a good idea from the examples he has already shown.

[Bblaauw]

What about CD case but also delivering the artwork for a DVD as sheets? That allows people to buy their own DVD case and insert the proper artwork themselves.
A slightly more expensive release (or additional version) likely isn't that big of a problem either.
Combined installer/liveCD is at http://sourceforge.net/projects/reactos ... z/download , but as said it might be configured for German settings (locale, keyboard settings, geography, time/date/currency, etc) as CLT was a German event. Plus maybe they'd like to keep it slightly exclusive to the attendees of that event.

[Aeneas]

I'd say, make it cheap.

You can "make up" on the creativity of the artwork. Make it BE cheap but not LOOK cheap.

A ReactOS CD is not jewelry and 0.3.14 is not all that impressive when compared to even old Linux. An item is "exclusive" not only because it is "rare", but because this rareness has been accepted as precious. It may be rare to find nicely visible bird shit on needle trees, but you still would not pay 15 EUR for it. You will find many old computers (486 boxes etc.) on the net that are dirt cheap though "rare".

That first run must be a full success, so make it cheap. 10 EUR max. The money is not important now - what counts is the general success of this first initiative. Just my opinion, of course.

[Webunny]

What about CD case but also delivering the artwork for a DVD as sheets? That allows people to buy their own DVD case and insert the proper artwork themselves.
A slightly more expensive release (or additional version) likely isn't that big of a problem either.
Combined installer/liveCD is at http://sourceforge.net/projects/reactos ... z/download , but as said it might be configured for German settings (locale, keyboard settings, geography, time/date/currency, etc) as CLT was a German event. Plus maybe they'd like to keep it slightly exclusive to the attendees of that event.

Tried it, but it's as you say; it's in German. At least it should (also) be in English. Is there any dev/(other knowledgebale person) who's willing to make it into an English (or bi-lingual) version? It would be really cool if we could ship a dual install/live 3.14 CD...