|
|
| Author |
 Topic  |
|
|
JoeBorn
Neuros Audio Team
Administrator
783 Posts |
 Posted - 08/24/2005 : 11:14:35 AM
|
As we are starting to expand and signup international distributors, we are wondering what to do about international websites. We need to balance multiple language websites with the desire to resist splintering the community into multiple, smaller sites. Especially considering we'll have one codebase for development, etc. How do other companies handle this? What about other open source projects?
jborn (at) neurosaudio.com |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%)
|
|
|
Yono
Posting Mania
717 Posts |
Posted - 08/24/2005 : 3:28:08 PM
|
Big companies tend to have a seperate domained website for each country (.de, .au, .fr, etc). The only international "open-source-like" project is wikipedia and that goes by en.wikipedia.org, es.wikipedia.org, etc.
-- 'Microsoft Works is an Oxymoron' |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
 |
|
|
mgao
Neuros Audio Team
Posting is for Closers
91 Posts |
Posted - 08/24/2005 : 3:42:39 PM
|
| I'd also like to get thoughts on how we manage the code development, Neuros will host a Subversion server to provide public access. How should we manage the firmware release? is the odd/even version scheme of Linux Kernel appropriate here? What are the major concerns that may cause people decide to fork instead of working on one code base? |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
|
Gomo
Just Posting
3 Posts |
Posted - 09/16/2005 : 1:08:14 PM
|
I put my great knowledge of Spanish to the service of the neuros community.
Some people will ask, Where this guy learn to write in Spanish?
The answer is: My mother make live in Colombia the first 21 years of my live !!!!!
So, I have not idea what do you want to do with our website, but I know, it have to have a Spanish site. So, If you need me, just ask. |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
|
FJ
Posting Profoundly
206 Posts |
Posted - 09/16/2005 : 1:12:58 PM
|
quote:
Originally posted by Gomo
I put my great knowledge of Spanish to the service of the neuros community.
Some people will ask, Where this guy learn to write in Spanish?
The answer is: My mother make live in Colombia the first 21 years of my live !!!!!
So, I have not idea what do you want to do with our website, but I know, it have to have a Spanish site. So, If you need me, just ask.
Thanks Gomo-
We truly appreciate the offer and will definitely contact you in the future.
Johan
Neuros
FJ |
Edited by - FJ on 09/16/2005 1:45:30 PM |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
|
Eythian
Posting is for Closers
51 Posts |
Posted - 09/21/2005 : 03:28:21 AM
|
quote:
Originally posted by mgao
I'd also like to get thoughts on how we manage the code development, Neuros will host a Subversion server to provide public access. How should we manage the firmware release? is the odd/even version scheme of Linux Kernel appropriate here?
Wow, that sounds good. My suggestions (which are based only on working on a handful of open source products, nothing really that makes me qualified)...I think for releases, it would be sufficient to get the source being worked on to a stable point, and split off a stable tag (within the repository). Perhaps give it a version number, say 1.2.0. After that point, only critical and tested fixes go into that (which then get released as, say, 1.2.1). All the while, people continue working on the code trunk, which is perhaps regularly (weekly/monthly) released as a beta or development release. This is labelled simply with a date stamp (say, 20052109, or maybe 1.2-20052109 to show what it's based on).
When this development version is considered good enough for a new release (perhaps after a feature-freeze), split off a new stable tag (1.3.0). Lather, rinse, repeat.
This seems to be to be the most sensible, and many parts of it can be automated (such as the weekly/monthly snapshots). So if someone who isn't willing to poke into the subversion repository wants firmware, they have the choice of the stable (labelled with just a normal version number) or the unstable (labelled with a date).
(An aside for those who don't follow software development quite as much as me, stable doesn't mean 'won't crash' (although ideally it won't), and unstable doesn't mean 'will crash'. Instead, stable means 'won't change', and unstable means 'will change'. So if you stick with the 1.2.x series, you shouldn't gain or lose features. However, if you keep up-to-date with the unstable firmware, you might find that a feature that worked one way last week works a different way now. Perhaps 'unstable' should instead be called 'development' to avoid people's perception of the word)
quote:
What are the major concerns that may cause people decide to fork instead of working on one code base?
Subversion to an extent allows branching, but if you create a branch, you may end up spending quite some time keeping it up-to-date (unless everyone uses a UNIX-like, and uses symlinks, but that's probably too much to hope for). However if it can be made that running a branch is easy enough (through using heavily modular code), people will hopefully be encouraged to not fork, and versions with differences that don't end up being in the main trunk will exist, but without a significant forking of effort (really, the best way is to use a distributed SCM, but I think that's raising the entry barrier significantly).
With this, I think the only thing that would cause people to really split off a fork is a) if the licensing changes (witness XFree86 vs. X.org) or b) if they totally disagree with the direction the codebase is going.
In the case of a), hopefully that doesn't happen and everything is kept as GPL/LGPL/some other acceptable license (a question: if, say, I write a sizable chunk of code that goes into it, would I be expected to give copyright sublicensing rights over, or would I hold the copyright on my bit? The former makes it more flexible for the company, but means you could all of a sudden close it up which may scare of devs, the latter makes it more complex legally for the company, but less so for the devs)
In the case of b) there isn't much that can be done, and I also don't think it's anything to worry about provided an environment of sharing and code-exchange can be maintained ("oh! they have a shiny feature, we can copy that")
Hmm, that turned into more of an essay than I intended...hope some of it is useful. |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
|
K-Man666
Posting Profoundly
156 Posts |
Posted - 09/26/2005 : 10:35:42 AM
|
I'd volunteer to care about the german part of the website etc.
Kaspar (The German Guy) |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
|
JoeBorn
Neuros Audio Team
Administrator
783 Posts |
Posted - 09/26/2005 : 8:52:10 PM
|
"a question: if, say, I write a sizable chunk of code that goes into it, would I be expected to give copyright sublicensing rights over, or would I hold the copyright on my bit? The former makes it more flexible for the company, but means you could all of a sudden close it up which may scare of devs, the latter makes it more complex legally for the company, but less so for the devs"
can you expand on that question. I was just under the impression (I guess mistakenly) that if you submitted code to a GPL or LGPL project, your code would automatically be subject to that license. Maybe you can expand a little more on this one?
jborn (at) neurosaudio.com |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
|
Eythian
Posting is for Closers
51 Posts |
Posted - 09/26/2005 : 9:20:05 PM
|
quote:
Originally posted by JoeBorn
can you expand on that question. I was just under the impression (I guess mistakenly) that if you submitted code to a GPL or LGPL project, your code would automatically be subject to that license. Maybe you can expand a little more on this one?
While that is correct in and of itself, there is more than one dimension to it.
If I write some software, and (L)GPL it, then people are free to distribute it according to the structures of the license. However, as I still hold the copyright to the code (assuming that it is all mine), and so it is still totally legal for me to take that code and make a closed-source product from it. It doesn't revoke the GPL on the already-released code of course, but the GPL doesn't apply to the closed-source version that I created. After all, if I hold the copyright, then I can relicense it to myself quite freely and automatically.
Now, 90% of the time this is no issue. The more community driven projects tend to have such a mish-mash of peoples code in there that it is pretty much forced to remain GPLed. To change it would require a) getting in touch with all the contributors and b) them permitting their code to be relicensed. However, in the more company-driven open source projects, they often require that either the copyright of the code be given to the company (not legal in some places, e.g. apparently Europe), or that sublicensing rights be provided (more generally legal). What this means is that, while the GPLed code will always be GPLed, the company that holds the copyrights/sublicensing agreements can do things like create a closed-source version, sell the code to a third party, or whatever.
So it ends up being something of a trade-off between the developers: on one hand, the company can request copyright assignment/sublicensing from the contributors, thereby reserving for itself the ability to do as it will with the code in the future. On the other, each contributor keeps their copyright, and is assured that their code will only be used under the conditions they specify.
This isn't a huge issue, but something that came up recently in another, somewhat similar, situation (A company supporting open source work around its product), so I was curious. Also, I'm not a lawyer, nor do I play one on TV, so don't treat the above as any kind of fact :) |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
| |
Topic |
|
|
|
| Neuros Forums |
|
|
|
|
|
International websites/forums/communities?
