Internationalization - do we have a plan?

We already have some non-native-English-speakers involved in the project. At some point in the evolution of Reprap, we'll want it to be useful to non-English-speakers.

How soon? When should we start work on the code to allow for a multi-lingual user interface? What about translating the Wiki documentation? Starting non-English forums, even?

Has anyone given thought to this yet? When we do it, it is likely to be significant work. Without it, Reprap won't be able to replicate unless aided by an *English-speaking* human... a restriction which is somewhat unfortunate, and one that will be hard to defend once the thing starts to replicate.

Some are finding Kicad awkward because of its French origins and lack of English-translated docs/parts/etc... that's how others will feel about Reprap if we don't do anything in this area.

Any thoughts? I hope I'm not opening *too* big a can of worms here!

Jonathan

That's a pretty big can of worms to open when we haven't even demonstrated that Darwin is working and useful yet.

Well, yes, perhaps it is a largish can (!), but the sooner some of the work gets done, the easier it is to deal with.

As the codebase grows, the size of the task of conversion to using text catalogues for all displayed text and menu items grows, and so it gets harder and harder to persuade anyone to start work on that... the number of contributors grows, so the codebase changes more rapidly, making it even harder... so the user community grows, but only includes English speakers... people get comfortable with that... and suddenly an international project has accidentally become very parochial. At that point, it is a *serious* pain to start doing I18N on a significant and widely-used codebase that wasn't written with it in mind!

I've lived on multiple continents, moved to a new country when I was 3 years old, have worked in several tens of countries, am married to a non-native-English-speaker, speak or read four or five languages (not really enough Russian to count, so four is safer) and am about to start learning another one... I did a bit of software internationalization/localization at HP in the mid-1980s. Given that sort of background, this kind of thinking about I18N and L10N perhaps seems more important to me than to some folks who have wandered the globe a bit less :-) However, that doesn't imply I am volunteering as internationalization coordinator for this project!

For me, it is inevitable: you say you want a globally replicable design? It has better be multi-lingual, and so had its documentation. A stated RepRap project goal is for worldwide replicability, so the need for I18N (and associated L10N) is a logical necessity. The question is therefore when, not if, this will be tackled. There is plenty of long-term thinking happening around here (PLA from corn, etc.) -- so it would be a bit surprising to me if no discussion of and planning for I18N has yet happened. That the work hasn't been *done* yet isn't a surprise!

It sounds as though the answer to my question is "no, we don't have a plan for internationalization of RepRap" -- am I right? And you are, I think, suggesting that we just leave Reprap completely English-only, text embedded in the source code, for v1.0? All the locale and message catalogue stuff is already right there in Java, see [java.sun.com] , so it's not as massive a task as it was in the 1980s, for the host software at least. That isn't to say it is going to be trivial!

Jonathan

P.S. For the uninitiated: I18N == internationalization. L10N == localization.

"It sounds as though the answer to my question is "no, we don't have a plan for internationalization of RepRap" -- am I right?"

To my knowledge, you are correct.

"And you are, I think, suggesting that we just leave Reprap completely English-only, text embedded in the source code, for v1.0?"

That is my opinion. I cherish that opinion for three reasons. First, the Darwin design is neither complete nor proven at this point, not that I doubt that it will be, but I suspect that from here on out the software and firmware is where most of the changes are going to occur, if my experience with Tommelise is any guide.

The second reason is that iirc the original point of this project was to get it into the third world so that people there could use the technology to create wealth without the massive pulses of initial capital required for conventional industrial development.

Keeping that in mind, which languages should we target and who among us are literate in such languages? Aside from hundreds of local languages you run across four major second languages in the third world, viz, English, French, Spanish and Portuguese. With people like Sebastien and others we might make a start on French, but I don't know of any Spanish or Portuguese speakers in RepRap just yet.

The third reason for me is that if you are going for third world internationalisation, your website and not your firmware/software is where you ought to start.

Again, that's just my opinion. I'm sure that there are several.

Edited 1 time(s). Last edit at 06/09/2007 09:19AM by Forrest Higgs.

Hi!

I reckon it's just a matter of recruiting continental RepRap-reps who would be willing to take on local tasks like translations or sourcing parts from local suppliers.

I reckon it's an essential can of worms, but on account of its chunkyness would be best opened after replication?

eD

"I reckon it's an essential can of worms, but on account of its chunkyness would be best opened after replication? "

That's my feeling down to the ground. It's pointless to spend a lot of time and trouble internationalising a new technology that we are (1) not sure will actually do what we want it to, viz, replicate, and (2) not sure will find a wide audience.

Forrest wrote:

> which languages should we target and who among us
> are literate in such languages?

The first task is to make it possible to target *any* language (or at minimum, any character based language whose characters fall within the Unicode character set)! Which languages we localize for first is, IMO, a very secondary consideration indeed.

With the framework set up, we can localize into one language (French is certainly a very reasonable choice, compared to starting with say Mandarin) as a sample, to test the capability. Then, as people show up who speak other languages as their native tongue, the hurdle for them to translate into their own tongue is a lot lower than it is right now. Sure, the first person (or first team) to attempt localization into a right to left language such as Arabic, or any of the CJK (Chinese/Japanese/Korean) group, will probably run into some issues with our insufficient internationalization, but the basic framework would be there to build on.

MediaWiki has decent multi-lingual capability, including right-to-left. So when we switch the RepRap wiki to using MediaWiki (planned for sometime soon, I think??) we could and perhaps *should* set things up for multi-lingual use, rather than waiting until it is larger and lots of people already have bookmarks to pages within it, and *then* trying to reconfigure it so we can serve appropriate sets of pages based on browser-specified language preferences, etc.

Ed wrote:

> it's just a matter of recruiting continental RepRap-reps
> who would be willing to take on local tasks ...

Continental? As in, continental Chinese?? :-)

Well, only if new languages and regions can be easily added to both the software and its documentation. In other words, only if the basic internationalization is already there. Otherwise, what most likely happens (I can point to smallish FOSS projects I have been on the fringes of where this has happened) is that someone grabs a snapshot of the codebase and docs, goes away for two or three months, and then comes back with a (say) Korean-only version of the software and some of the docs, just by hacking on all the strings and tweaking the GUI so the fields are in their desired order on-screen... which is cool, but of course is totally obsolete by the time they get done, because meanwhile the official codebase has changed and grown and had numerous bugs fixed! So then they either give up, or have to try to stay on top of all codebase changes manually... a ton of unnecessary work.

Oh well, it looks like I am a lone voice crying in the wilderness on this one, at least for now. So I'll have to either just do it solo, out of sheer stubbornness(!), or wait for a few more like minds to emerge in the RepRap community.

I do think we should put this significant task *somewhere* into the "Future Plans" for the project, at least. Right now it seems to be missing entirely from the page at [reprap.org] . Can we at least internationalization of both documentation and the host software as a goal for v2.0 ?

Jonathan

Jonathan. I don't think that anybody disagrees that internationalisation wants doing for RepRap. I don't see it as a question of whether but rather one of when, viz, what priority should such an effort have given the present state of the RepRap technology.

There are a lot of things that want doing on RepRap to make it work at all. I just feel that working at all comes before telling everybody effectively.

Would having a few really bright and capable Chinese, Korean, Japanese, Russian, etc. etc. people coming on to the team in the next few months help us to get things "working at all"? I don't know. It might.

Anyway, for now, let's at least get internationalization on the "Future Plans" agenda.

Jonathan

There's no question that such people could help RepRap a LOT. The problem is that we have to find the initial ones of those people who are ESL because none of us speak those languages. I've been trying to get my son, who neither the time to invest in building a RepRap nor the space in his dorm room to actually build one.

You might want to poll the crowd that hangs around to see what languages we already have within the group. I can get along in both Swedish and Afrikaans, but anybody who speaks either of those who can hold a screwdriver also speaks English. IIRC you might know Tagalog but doesn't the same situation hold true there as well?

Sebastien, I think, is French fluent, so that might be a place to start. That would get you Francophone Africa and Oceania as well as Surinam and Quebec. There is an awful lot of the RepRap site that would want translating though, nevermind the software and firmware comments. All of that is also a serious moving target in that the technology is still being developed.

Well, I can't claim true fluency (except maybe in German), but once I mentally "switch gears", I'm able to read a newspaper and hold a more or less intelligent conversation in:

* French (5 yrs in high school, won poetry speaking contests as a teen),
* German (was very fluent at one point, dreaming in German etc.) and
* Tagalog (pretty decent for everyday conversation, I've even attempted public speaking in it).

I am also (hopefully - bureaucracy may yet intervene!) starting a college level Spanish course next week. And there are plenty of Latinos here in Southern California I can try to recruit to help fix a (probably very bad!) first attempt at a Spanish localization, if that is what it would take to get one started!!

I think making even some effort in this direction, in any language at all, is attractive to those from other linguistic backgrounds -- just as my very limited Russian won me smiles and friendships over there, just for trying. How absolutely correct the initial localization into any one language is doesn't matter as much as the fact that one exists at all. With a bad initial French (for example) localization in place, a native French speaker trying out the software will probably very quickly file bugs to point out the the mistakes. We can then respond (in our bad French) that we know our French is bad, and could they please help us improve the French localization and translated documentation :-)

One level up from this, a Portuguese speaker arriving and finding no Portuguese at all within the project, but existing (perhaps poor quality) localizations in French and Spanish, would at least know there was an internationalization framework in place and working, and so would be more likely to volunteer to start Portuguese localization than if what they see is no localizations at all.

The current situation, having no plans at all and no framework in place for any internationalization, makes the project look almost "Imperialist" and of a "everyone should just learn English" mindset, a bit like the tourists who speak louder and louder thinking that is what it takes for "foreigners" to understand them :-) I don't think that is how the project really *is*, at all, but if we want those other folks to join us, IMO we need to try and avoid that initial negative perception.

Looking at the web page statistics for the wiki would give a guide to priority pages to translate, just the top ten or twenty pages would be a useful step forward. Then as people need the others, they ask for translations, or (if they can) just write translations as they go! There is also Google Language Tools for (often really bad, but mostly understandable!) quick and dirty reading of web pages. It's a lot more inconvenient to use them for text in a programs user interface, though.

Comments in the software and firmware sources are probably best left in English. That seems to be "best current practice" from what I see in the FOSS world at the moment. That presents an unfortunate barrier to software developers, but not to end users. Even if you translated the comments, you'd still have English variable, method and class names... I don't know of a good solution for creating maintainable multi-lingual source code.

Jonathan

i agree with forrest (and you) on this one. internationalization is important. however, getting a working project is more important.

if/when non-english speaking people get interested enough in the project to warrant a translation, it will happen. as forrest pointed out, its much more important to have a working machine than to have docs about it in 10 different languages.

also, didnt you just tell me via email that getting CNC'ed extruder / darwin parts would be too distracting to the developers? what do you think an internationalization effort would be?!?!

its really not that hard to do internationalization in software. it requires tracking down all the strings, replacing them with variables that are defined in a language specific file. this would probably take a week or two to get the structure in place (if one were so motivated) and then however long after that to actually translate it. the problem is that this is open source. people are going to work on what they're interested in. i'm interested in getting a real machine. if you want something done you have to recruit someone, or DIY.

the wiki would be harder, but if someone is desperate, theres always google translate, as well as the fact that our pictures are naturally multilingual.

Sounds like you are pretty well prepared to do this. As I see it Spanish and French are the other two imperial languages. A good cut at either or both would be very useful.

As for my own self, I think the thing to do is get the technology working after a fashion so that we have something worth having. Once we have that, the rest will, I suspect, follow without a lot of drama. As I have found, going from a working reprap machine to one which is able to print useful things is a bigger hurdle than designing and building the machine itself. There is a lot of know-how that we have yet to develop that deals with FDMing objects at ambient temperatures. That's where I'm putting my efforts.

> also, didnt you just tell me via email that getting CNC'ed extruder / darwin parts
> would be too distracting to the developers? what do you think an
> internationalization effort would be?!?!

CNCed parts are not a long term goal, just a side track aimed at solving a temporary parts shortage.

Internationalization *is* a long term goal (or should be!). Sure it takes a chunk of work by one (1) Java person, then the rest just need to know enough to use the framework when they add new strings or menu items to the codebase. Which is something they are going to have to learn anyway at some stage, if they don't already, as Java developers on a global project.

So the first is a side-road that is not on the project list of stated goals, and is not strictly needed to reach those goals. The second is a clearly needed long term capability if the project is to reach its stated goals. I don't see those two as being very comparable in terms of priority or level of distraction. Do you, really?

Let's just put internationalization as a "Future Plan" item for v2.0. If I get stubborn enough to just do it (in the Java code at least) one weekend before then... well, I'll do it. If not, we'll wait for 2.0.

Jonathan

of course i think getting part kits for the robot is more important than translating the docs!

how do you expect people to research a 3D printer that requires 3d printed parts when those 3d printed parts are not practically available? sure, after v1.0 when it can make its own parts, we'll be fine, but in the meantime, other than fabricating your own parts its impossible. that leaves the burden of research on people with access to FDM machines, or those brave enough like forrest to hack together their own machines.

i dont want to get into the whole CNC'ed parts debate... if you guys dont realize the importance of having standard parts to supply to researchers, well i dont know what i can say that will change your mind. i guess i'll just have to do it myself.

Okay guys, there are a lot of different people doing different things to advance the state of the art of the RepRap project. I've taken a lot of flak from people for working on the technologies, viz, encoder feedback gearmotors, which might go into the next generation Mendel instead of just concentrating on Darwin. I think what I'm doing is extremely important, though many, Zach included, have in the recent past voiced very different opinions on that.

The point is that it's very easy to get into pissing contests that take the form that "what I want to do on the RepRap project is far more important what you want to do", the implied result being that everybody ought to do what I am interested in doing and blow off what they're doing.

This is just silly. There is plenty of room in RepRap for people to contribute on all kinds of levels and in all kinds of areas.

Jonathan has, iirc, spent quality time as an expat in at least the Philippines and feels strongly about the need for internationalisation. I can understand that having spent 18 years as an expat in the developing world myself. Zach is very interested in facilitating the early diffusion of RepRap parts and technologies so that we can get a larger developer community going. Zach is pretty easy going about the means brought to bear to advance his goal. CNC'ing parts is one way of advancing it. Mind, both of those, imo, are TOTALLY laudable undertakings.

It's simple mischief, though, to potshot at the specifics of another's zones of interests as a means to advance ones own. I know that it is an easy game to get into, having done it myself. We should try to avoid it, however. Doing that sort of thing doesn't advance RepRap at all imo.

Edited 1 time(s). Last edit at 06/10/2007 10:58AM by Forrest Higgs.

I agree that it's very important to have a multilingual project, but I also agree that we don't have the time at the moment. Remember that everything is secondary to making a working replicating machine. Once we have done that, everything else will happen by - if necessary - others taking it and running with it.

However, this is an open-source project. I can see no harm in inviting anyone to make versions in any language they want now, and putting them anywhere they like on the web. We can be up-front and say explicitly that, if they do that, we'll copy the results right back so we can internationalize the project...

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Adrian,

I think you re confusing internationaling (making the system capable of displaying information in multiple languages and locales) and localizing (adding a single set of such information for any one language/locale).

My point is that until we internationalize, localizing in the way you suggest is wasteful, and is actually quite difficult to "copy the results right back" from.

I've added:

* Internationalize the software and localize into at least one non-English language.

as a new sub-goal for v2.0 on the FuturePlans page. I hope that's OK.

Jonathan

RepRap Forum Mailer wrote:

> I think you re confusing internationaling (making the system capable of displaying information in multiple languages and locales) and localizing (adding a single set of such information for any one language/locale).
>
> My point is that until we internationalize, localizing in the way you suggest is wasteful, and is actually quite difficult to "copy the results right back" from.

No - I understand the distinction, and I can see the slight wastage of
effort. I agree it's more efficient overall to do as you suggest. But
it's more efficient _for_the_initial_developers_ not to, and to leave
internationalizing to others. The total cost is greater if it happens
later in the project, but it is spread over many more people.

Meanwhile if other people do do non-English versions anyway that again
costs us nothing, and would be a free resource for subsequent
internationalization.

This touches on a more general point: divergence. In open-source
software in the past divergence has been seen as a bad thing: it has
been thought that a monoculture is best because it is most efficient.
Indeed it is, but it also puts all the eggs in one basket.

I think that the desire for a monoculture is almost always wrong, and
that divergence and speciation are a good thing. To be specific - if a
group in (say) India copied RepRap then started taking it in a different
and incompatible direction, I think that should be welcomed.

> I've added:
>
> * Internationalize the software and localize into at least one non-English language.
>
> as a new sub-goal for v2.0 on the FuturePlans page. I hope that's OK.

Absolutely - I have no problem with that. I think that the first two
languages we should go for are Chinese and Spanish.

--

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

> I think that the desire for a monoculture is almost always wrong, and
> that divergence and speciation are a good thing. To be specific - if a
> group in (say) India copied RepRap then started taking it in a different
> and incompatible direction, I think that should be welcomed.

I think I'm willing to buy this for hardware; I'm much less willing to do so for software.

Do you have any examples of FOSS software products which have diverged in this fashion, and the resulting divergence has brought clear positive benefits to the end user community (or communities) of those products? Every example I can think of has had clear negative impact, and some well-known examples (gcc/egcs comes to mind) have ended up "re-merging" at substantial cost in software developer time and effort. The GNU Emacs/Xemacs divergence is *still* annoying, after how many years!?

[I shudder to think of how to adequately support a user showing up on a RepRap support forum asking for help, for whom the forum language may be their third or fourth language, and when that user may have a version of the software that many of those offering support do not have access to and have no experience with, and the end user may not even know how to tell them what specific version they have ("I got it from my friend Bill on a CD-R")... and all the menus and error messages are in Hindi (or Black Tai, or whatever). You'd quite possibly end up trying to decompile .class files just to help rediscover and re-fix a bug that was *already* fixed in the official codebase. Remote software support is hard enough without that kind of unnecessary self-inflicted difficulty, IMO.]

Divergence because of varying local conditions may be useful for hardware (Reprapping at 7000m above sea level where ambient daytime temp is say -10 Celsius?), or because of local pricing disparities or availability issues (maybe steel rods cost 10x more than brass rods somewhere... maybe there is a country where 16F series PICs can't be legally imported...). Fair enough. But in software, given a global Internet to move the bits around, tools like Subversion to manage a codebase being modified by multiple developers, and the use of a mostly-portable language like Java -- I don't think the advantages of such diversity are clear, nor are they (as far as I know) proven. And the disadvantages are pretty well documented. Many eyes *don't* make all bugs shallow, when each pair of eyes is looking at a different variation of the code and the bugs they see are not communicated back for the benefit of the wider user community. You'd be trading away the main benefits of the open source development model, for... what?

I'd be interested in hearing about software counter-examples you are aware of.

Jonathan

RepRap Forum Mailer wrote:

> I think I'm willing to buy this for hardware; I'm much less willing
> to do so for software.
>
> Do you have any examples of FOSS software products which have
> diverged in this fashion, and the resulting divergence has brought
> clear positive benefits to the end user community (or communities) of
> those products? Every example I can think of has had clear negative
> impact, and some well-known examples (gcc/egcs comes to mind) have
> ended up "re-merging" at substantial cost in software developer time
> and effort. The GNU Emacs/Xemacs divergence is *still* annoying,
> after how many years!?

Yes I agree. I too think that software divergence is a bit annoying and
unhelpful.

Annoying, that is, to people, but not to the software.

We find it convenient to make monocultures of wheat in one field, and
carrots in the next. No farmer would mix them, because of the
consequent tending and harvesting difficulties. But that is not what
the wheat and the carrots would do left to their own devices.

A diverse mix of species all jumbled up (Darwin's tangled bank) is often
an inconvenient nuisance to people at an immediate and local level -
weeds and mice... But it is indescribably more robust than a
monoculture as a self-sustaining system.

Software divergence, splits, and incompatibilities give strength
_to_the_software_, in just the same way as sexual reproduction gives
strength to the genes carried by a species by ensuring that they are not
all imprisoned in a vulnerable population of identical clones.

I am interested in making a stable self-replicating and self-sustaining
system that has a mutually-beneficial symbiotic relationship with
people. If one is going to do that, then one has to regard the two
replicators in the context of the evolutionary game theory that drives
them both, not just in the interests of one to the exclusion of the other.

That's why I favour both software and hardware divergence: it makes it
more, not less, likely that significant elements of the software and
hardware that get carried forward in both diverging populations will
survive. Emacs and Xemacs contain a lot of common code. There are four
possibilities:

1. Both survive.
2. Both go extinct.
3. Emacs survives, Xemacs goes extinct.
4. Xemacs survives, Emacs goes extinct.

Only in Option 2 does the common code die out, and that is less probable
than the alternatives considered together. It is also less probable
than the extinction of just, say, Emacs, had the two never diverged.

--

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

> Software divergence, splits, and incompatibilities give strength
> _to_the_software_, ...

This remains an unproven hypothesis (in the context of FOSS software in an Internet-connected community) unless you supply specific examples.

The "reproduction" of software is trivial, distance independent, and nearly instant and nearly free of cost of any kind. This is a situation very DIFFERENT from that of sexual reproduction, where reproduction is time consuming (9 months for us humans, plus parental attention for about 18 years thereafter), highly distance dependent (yes, you *can* ship frozen sperm or eggs or embryos around, but that is complex and unreliable and definitely not the norm for human sexual reproduction!), and has very high associated costs (18 years of housing, feeding and clothing, college bills, etc etc!).

In the digital realm, the significant costs are just Internet bandwidth and data storage space, and with Terabyte hard drives and multi-megabit Internet connections now available even at home on hobbyist budgets, the effective costs per software application are incredibly low, and becoming lower all the time.

I submit that a you may be making an oversimplified direct transfer of an idea from real-world biology into a digital ecosystem where things are very different indeed.

In today's Internet, humans will copy software (or modify and copy it) *only* when it is beneficial to them to do so. They have all the control over that process. Evidence so far in the Internet/FOSS environment seems to me to suggest that most successful (i.e. popular) software is copied because it is relatively bug-free and provides useful functionality to many humans (hence portability and I18N may be rather relevant). Extinction in this space comes only when a "better" (better for humans!) equivalent arrives and is so widely used and copied that noone uses the "old" software any longer. Even then, it often hangs around... how many people today know how to use 'ed', for example, the early Unix text editor -- but it exists in just about every Unix/Linux/*BSD distribution on the planet!

Where is the evidence *in* *this* *realm* (FOSS application software in an Internet-connected community) that monoculture leads to extinction and divergence leads to survival?

Jonathan

I provided multiple reasons why the parallels may not apply, or may be significantly less applicable, in my post, I think.

As for examples used in evidence for my own current position -- OK, let's look at this. Which FOSS application software products today have significant user mindshare and so are commonly copied and used:

(a) those which have forked many times from a single original codebase into multiple incompatible but diverse products which continue to be used, each with their own distinct features, bugs, developers, and support and user communities,

or

(b) those which have a single large user and developer community working with a common codebase?

Honestly, I can't even name *one* FOSS application in category (a) that has significant user mindshare today other than Emacs/XEmacs, and that is just two codebases, not "many", and it is only some very particular human social characteristics on the part of one set of developers (perhaps both sets?) that have (so far) prevented their re-unification. My prediction is that in another decade or two, one or other of the two codebases will have "won" and the other will be relegated to history, if they do not reunify.

By contrast, I can think of plenty of products in category (b), many of which, despite their source code level monoculture, are portable to and commonly used in many diverse hardware and OS environments in widely geographically dispersed locations and in different linguistic and cultural settings.

Here are a few familiar real examples, to get us started: Apache, Sendmail, BIND, OpenOffice, Postgresql, MySQL, Gnumeric, perhaps even Kicad and ArtOfIllusion :-)

The evidence appears to me to be considerable.

Any chance of a few counter-examples? Please?

Thanks,

Jonathan

Forrest,

I don't understand your response... all the examples I gave were (very intentionally) of applications, not operating systems. All of my example applications will run under other operating systems than Linux. Even including proprietary non-replicable OSes, such as Windows. Every single example application I listed was chosen in part because I know for sure it runs on Windows as well as on Linux and *BSD -- precisely to avoid this whole OS choice issue from clouding the debate!! So why did you still feel it necessary to switch to discussing the OS? I'm puzzled by that -- what did I miss?

I'm genuinely interested in whether Adrian's "a diverging codebase is good" hypothesis is valid in todays FOSS software *application* arena, and was very careful to specify that particular environment for this debate. Why suddenly start talking trash about an operating system? If you have issues with Linux, for whatever reason, that's fine, either use (or develop and then use) something that is better for your purposes (something that is FOSS and so is replicable, of course!). If you can't find a replicable OS that meets your needs, well, OK... the Plan 9 sources are out there if you want a starting point for a new one :-)

NOTE: The Reprap host software is an application, not an operating system.

Incidentally, I'll happily run that application software on any reasonably reliable underlying OS that I have some acceptable degree of control over (i.e. the OS needs to be FOSS or very nearly FOSS). Examples include FreeBSD, NetBSD, OpenBSD, Linux, maybe even OpenSolaris.

Further, I'll happily run that OS and application on any reasonably reliable and available computing hardware that has acceptable price/performance (Sun, SGI, HP, Apple, Intel, AMD, DEC Alpha even... all fine with me if reliability and price/performance is good). I've actually used all of those hardware platforms at some point, BTW. Not all as personal desktop systems, though!

Let's avoid being sidetracked into "my OS is better than your OS" fanboy stuff. This thread isn't about "Let's all be Linux zealots, because it's cool", or its converse! This is about a wider (and so much more interesting) question of whether, in practice, the hypothesis that a diverging FOSS software source code base is helpful to application reproduction and survival in today's Internet-connected world.

I posit that either (1) Adrian's hypothesis is untested in this arena, (2) it is tested and does not seem to match reality based on examples I have given, or (3) it is tested and counter-examples to those I supplied earlier exist which support it. Which of these is correct? :-)

Jonathan

Forrest,

> I freaked out months ago when RepRap put in a formal
> SVN system for it's firmware and software largely
> because I saw it as yet another hurdle that
> newcomers were going to have to clear before they
> could contribute their creativity to the idea of
> RepRap.

Which, of course, is a mistaken inference, as by now you probably realize! Today, with Subversion in place, anyone can make changes to a copy of the (publically available) Reprap codebase, and can then distribute diffs or complete sets of sources back to the forums, or to their friends by email, or whatever. Subversion does not prevent that kind of ad hoc codebase change, in any way!

Pretty GUI front ends like TortoiseSVN for Windows mean "learning" Subversion enough to get started is a matter of at most an hour skimming the (free online) docs and trying it out.

Even without either of those, it takes a whole 4 commands (which are the same in Linux, or Cygwin under Windows, or Mac OS X!), documented on the Wiki, to check out all of the Reprap codebase so you can creatively bend it to whatever new purposes you can creatively imagine. How is this in any sense a significant "hurdle"?

Further, as you know, I've been spending considerable energy in packaging the current Java codebase in ways that are "easier" for those on the edges of the community -- .zip files containing either binary runnable code, or a set of source code. Subversion does not prevent such packaging at all. It just helps a diverse group of software developers coordinate their work, when they choose to work together instead of independently.

[Real world example: I have in my email inbox right now a message from someone outside the core team, with attached zip files containing slightly modified Reprap Java code. That person has no Reprap subversion commit access. That has not prevented him from making a contribution.]

> You can imagine how my hair stands on end
> when people like yourself start talking about
> internationalisation of the website and code base.

Why? These enhancements don't affect 95% or more of current Reprap community members; adding new content to the Wiki in English will (should -- I am not the RepRap Wiki administrator!) remain as easy as it is now; modifying the Java code once internationalised may need a quick read of an intro to Java internationalization, or copying examples from elsewhere in the codebase if you lack the time even for that quick read. Neither of these enhancements are, in and of themselves, barriers to adoption by either future documentors or future Java coders. Both are (by definition!) necessary for the project to reach its stated goals of worldwide replication.

> The way I figure it is that if I do anything
> worthwhile on my rather fully diverged RepRap
> project others will take the good bits and
> incorporate them into the mainstream. If there
> aren't any good bits, my project will find
> deserved and proper extinction.

Quite so. And assuming there are "good bits" (which I strongly suspect there are already and will be more of as both Reprap and Tommelise develop), your project may still itself become extinct, just with some of its genes flowing in mutated form in future Reprap hardware (or software or firmware). Unless you publish very detailed build info for Tommelise hardware/firmware/software, and can create a community of Tommelise-builders around it, the chances of Tommelise itself replicating in any quantity are IMO rather low; you seem to effectively agree with that assessment in your statement I quote above.

> I see the addition of layer upon layer of specialist
> knowledge requirements on RepRap as pushing the
> technology more and more towards a central control
> strategy and exclusionary of much needed creating
> talent.

What constitutes "specialist knowledge" is very much dependent on your particular starting point. In many cultures, knowledge of the English language is decidedly "specialist" -- what percentage of mainland Chinese speak and read English today, for example? In others, knowledge of closed proprietary programming languages such as Visual BASIC (or whatever dialect of BASIC Oshonsoft uses) is "specialist", and indeed is often perceived as exclusionary because time spent learning the nuances of such languages does not lend itself to re-use on future projects in different arenas! In still others, soldering skills are decidedly rare! In some, woodworking skills may be similarly rare.

It would be very self-centered of anyone in this community to decide that everything *I* know is (or should be) common knowledge, and everything I *don't* know is specialist knowledge (that therefore shouldn't be needed), surely. Let's not fall into that trap.

We can't (yet!) avoid the need for soldering capability, but we can avoid the need for people to learn proprietary languages, and we can (in time) reduce or remove the need for English language too. So we should do those things, to allow worldwide replication. We can package the code in ways that permit easier downloading and installation of it, so we should do that (and indeed have already begun doing that).

So, OK, I'll take your implied challenge!

First, lets attempt some sort of working definition of specialist knowledge:

Given the several tens of hours it will take anyone to construct their first working Reprap/Repstrap at present, I suggest that *anything* that can be learned by reading freely available online documentation by a fairly intelligent English-speaking adult in an hour or two is not, IMO, worthy of the designation "specialist knowledge" in the RepRap context. The basics of Subversion use, and perhaps also Java internationalization, by that (admittedly very rough) definition, would not qualify as being "specialist knowledge" for software developers in this community.

Now, let's apply this definition to the Reprap project as a whole:

(1) Other than soldering and mechanical construction skills (and some way to make the RP-able parts!), and perhaps general systematic troubleshooting skills, what "specialist knowledge" is currently needed to build and use a Reprap Darwin v1.0 -like device today? What unnecessary "layers" of such knowledge have we accidentally introduced?

(2) Secondarily, but not unimportantly, what additional layers of such knowledge currently stand in the way of someone who wishes, not just to construct and use, but to then further develop, Reprap Darwin v1.0? Obviously all software development of any kind is going to need software development skills... that's pretty hard to eliminate as a requirement, by definition! So what else, that can't be learned in a couple of hours by an intelligent English-speaking adult with a computer and an Internet connection?

If you can provide us with such a list, then we can start work as a team on reducing its size and scope, minimizing any such problem, and maximizing Reprap's chances of successful replication worldwide.

> I don't view that as a healthy development vis a vis
> the prospects for success of Darwin and RepRap in general.

OK. Please provide the list, so we can work on reducing it.

Example: Making changes to Sendmail code is fairly esoteric work, needing a good understanding of computer networking, email protocols, and in some instances common mis-implementations of them, C programming skills, and cross-platform development background (I hacked on it a little in 1994 or so for internal use).

Does this "specialist knowledge" prevent Sendmail from being widely used on many many different computing platforms and serving a useful purpose? Not at all. Why is this? It is a fairly mature product, and can be configured to do most of what a large number of people expect of it without learning all those skills and hacking on its code. Similar arguments could be made for, say OpenOffice, which can be widely used on multiple platforms and OSes, and is useful to many people who have no programming skills at all.

Reprap ... isn't there yet! Give it time.

Meanwhile, it seems pretty unhelpful to twist an entertaining online debate about whether a diverging FOSS software codebase is practically useful to its survival into anything approaching an anti-Linux or anti-Subversion tirade.

Jonathan

OK, then it might help me understand why Subversion is such a significant stumbling block to development if you responded to the rest of my post, which included things like how simple it is to use, how today people are contributing without using it, and so on?

Jonathan

You are apparently choosing not to answer many of my direct questions. I tentatively conclude that either I am asking really bad or really irrelevant questions, or else I am asking some good questions that you have no good answers for? :-)

Forrest Higgs wrote:

> With Tommelise, I'm looking to draw in all those
> "bright 14 year-olds" many of whom have minds
> that are being allowed to rot, educationally, ...

Cool. If you are a good enough and motivated enough teacher and mentor that you can take a bunch of 14yo kids with no significant prior programming background, from all over the world, and have them be able to usefully contribute to a continuously changing team-developed and ever-growing codebase of (even now, in its infancy) over 25,000 non-comment lines of code... well, I think that will be very impressive indeed!

Have you begun to rewrite the host software in a (replicable) language that you feel is appropriate for such teaching/mentoring of non-programmers who you wish to see turned into Reprap/Tommelise software developers? Python, maybe? How far along is that parallel codebase? When will it be made public?

Even a 1,000 line program is pretty daunting to non-programmers. How to get a 25,000 line program to seem "manageable" to such folks, not just sufficient understanding to read it, but enough to participate in team development -- that is a really big problem you are tackling. Especially if their past experience with the education system means they are unwilling to tackle a fairly lengthy course on programming first :-) Have you published anything on your web site about your overall approach to doing this? If so, please provide a URL so I can read it.

My sense is that the sheer complexity of the task, in any appropriate programming language and using *any* appropriate tools for assisting teamwork among the software developers, mitigates against being able to rapidly or easily include such people (of any age, never mind 14yo) in the software development aspect of Reprap or Tommelise, in any significant numbers. I don't think Linux or Subversion or Java are likely to be the main obstacle here at all.

In fact, I'd think 14yo's with Battlebot experience are more likely (and better equipped) to contribute on the mechanical side of Reprap than the software one; it just seems a better fit. If BattleBot builders use CAD software to create their bots, they will already have many of the needed skills in that area. If not, then teaching them all some solid CAD skills is likely to present a far higher barrier to entry than Subversion use, surely!?

> ... by the high bars to participation that such
> skills requirements pose before they can do
> anything as rewarding as the RepRap project promises.

Is that "do" as in an end-user, "construct and use a Reprap"? Or "do" as in a developer, "develop and re-design and contribute back useful modifications to Reprap application source code (and electronics and firmware and mechanics)"? Those two roles have (IMO) very different skills requirements, and probably always will. End user vs developer is an important distinction in dealing with complex systems of all kinds. You can often design systems so as to reduce apparent complexity to the end user, but doing so usually increases the actual underlying system complexity and workload for the developers.

> Essentially, I see the approach that RepRap is
> taking as attracting more people like or similar
> to those already participating, viz, people just
> like us.

Well, maybe. I have essentially no woodworking or metalworking skills, so the mechanical construction aspects of Reprap seriously scare me (never mind my trying to design improvements to those mechanics or an alternative form of them!!). But, modesty aside, in general I can program pretty much anything that has a CPU, given a little time to adjust my mental model of it and learn a little of a few new software tools. For me, learning a new programming language is trivial compared to learning to use a lathe or a mill (or even a table saw -- software doesn't have the ability to take your fingers off!). In some ways our backgrounds and skill sets are pretty different! Yet the project has attracted both of us, even this early in its life. Perhaps the current set of Reprappers is not as homogenous as you suggest?

Developing a complex software/electronics/mechanics hybrid project (whether RepRap or Tommelise!) is *going* to require the ability to handle significant complexity, and to adapt what you already know to the particular project concerned. Nothing we can do regarding choosing Linux or Windows, or Java or Python or BASIC, or Subversion or CVS for host software tools ... none of that is going to affect that basic requirement very much at all. So motivated 14yo's with software skills can probably adapt fairly readily towards Reprap software and firmware development, motivated 14yos with electronics skills can probably adapt to the Reprap electronics development, and your putative motivated 14yo BattleBot builders can probably adapt to the mechanics development side of Reprap pretty well, and quite possibly the electronics development also. But people (of any age, including mine) are unlikely to turn into developers on a project of this complexity without some reasonable level of prior experience in whatever area or areas of the project they wish to develop.

> The demographic I'm looking for, otoh, is the sort of
> kids and young people who do things like build battle bots.

So in essence you're deliberately selecting young people with significant mechanical and perhaps some electronics background and aptitude, but with no software development background (and perhaps relatively little conventional discipline and social skills, and a distrust of or distaste for conventional classroom or structured learning?). As Reprap *users*, that could fit well, I'd think! For Reprap software developers, IMO, it's far less appropriate as a set of selection criteria. And nothing anyone can change regarding OS, language and teamwork tools will change that very much. So, to my mind, your criticism of using Linux and Subversion earlier in this thread still seems oddly out of place.

> I see the two development streams as complementary
> rather than antagonistic.

Sure. I'd really love to see a re-implementation of the host software in, say, Python (or Ruby, or even Haskell or LISP), at some stage. Perhaps one with a very different, but still useful, user interface. I think the resulting friendly "competition" between the two software development teams for users would drive up ease of use and feature set in both software products. Right now, I don't think our software developer community is large enough to sustain that.

OTOH, I doubt that any geographically diverse team of more than a very few individuals, working on software of this complexity, is likely to be able to work well together and grow the feature set and reduce bug count without using appropriate teamwork tools (software tools that work across a network and can track who did what when and can 'undo' changes when necessary -- CVS or Subversion for code, Wikis for web docs, for example).

A team like that, trying develop Reprap or Tommelise host software using (say) fifty 14yo non-programmers from perhaps 5 to 10 nations as software developers... wow! Such a team would, I suggest, disintegrate and fail quite rapidly if it did not adopt *some* kind of somewhat standard approach for committing changes into its shared codebase. Some of these young team members will face serious funding constraints, so buying commercial closed software (and upgrades for it yearly or so) becomes an issue, too, if the team is Windows-based. Replicability of the host software platform and tools could be key for these folks.

If a team is going to pick a portable and replicable language and a similarly portable and replicable teamwork tool appropriate for a dispersed team of developers... well, Java and Subversion are pretty reasonable choices at the moment.

I am unable to form a clear mental picture of how a dispersed multi-cultural team of (mostly? only? more than 33%??) 14yo non-programmer kids would function to create and enhance a 25K line source code product, especially without using some kind of software version control system. If you have a clear vision for how to make that work, and you can cause such a team come together around Tommelise, then go for it! And please document how you are going about it :-)

Jonathan (who should probably write less and solder more!)

P.S. Plenty of bright 14yo's are already running Linux, and many could read and understand the Subversion docs inside my "couple of hours" artifical time limit, too. These are not the kinds of obstacles you need to be focusing on, IMO!

> I guess we'll just have to see, nie?

Ja, inderdaad.

If you could let me (and the Internet public) "see" your plans for making a 25K line software codebase easily accessible to geographically dispersed 14yo non-programmers for ongoing development, and "see" the latest status report on how implementation of that plan is going, that would help me "see" much better. I don't yet see that kind of information on your site. I did look for it.

There seems to be nothing at all there about the whole "turn 14yo Battlebot builders into Tommelise developers" goal at all on the 3dreplicators.com site, in fact. Not even under "Why Tommelise?" in the FAQ, where one might reasonably expect it. Is there some reason you are making this (admirable) goal public only here on the Reprap forums, rather than on your own site?

Further, I can't find where to download the current Tommelise host code and its developer documentation, to see for myself how small and easy to use, understand and develop by non-programmer 14yo's it is. Did I miss it? It *is* published, and *is* released under an OSI-approved licence, for others to use and modify, whether they are 14yo or not, right?

I have no formal qualifications in educating 14yo kids (well, I'm a licenced foster parent, and both my own kids are now over 14, but that's not really a formal education qualification!). Nevertheless, my instinct is that making software development on a sizable codebase manageable for non-programmer 14yos is a bigger task than getting Reprap (or Tommelise) to replicate! And so far, neither your site nor your posts in this thread provide any evidence to suggest otherwise.

Jonathan

So yours is currently a closed development model, with code (whether 4K or 10K or 25K lines of actual code lines after you exclude the comments and blank lines really doesn't affect my basic argument much -- how many 14yo non-programmers will feel comfortable reading and enhancing 4K lines of code?) released only to a trusted few. Fair enough, it's your code, so its development model is clearly your choice.

[BTW, I didn't intend to suggest that the Reprap host code contains no comments -- merely that I tried to exclude blank and comment lines from my rough line count! Actually, it seems I made a mistake somewhere (possibly related to Windows vs Linux line ending conventions being different?)... sloccount [www.dwheeler.com] says Reprap has only 10740 SLOC of Java code. And sloccount under Linux is likely to be more reliable than my earlier find/grep/wc hacks under Cygwin. So 10K rather than 25K.]

When the Tommelise codebase and docs become publically available, I'm interested. When the associated plan for making about 4K SLOC (guessing about 1K lines of comments in there for a total of 5K lines to read) easily understandable and modifiable by a dispersed group of 14yo non-programmers without version control is made public, I'm interested in that, too.

I'm uninterested in any copies provided under "NDA"-type constraints such as "here it is for you to look at, but please don't make this public yet".

Jonathan

I can't resist:

> ... 5K fairly well commnented lines of VB.NET code ...

> I've always taken the position that software should be
> written to be as simple as possible ...

Is VB.NET really "as simple as possible"? :-) To me, VB.NET appears to be a very complex software product (or set of products) indeed. How much disk space does it occupy? By what measure is VB.NET "as simple as possible" :-)

Jonathan