I thought I would make some suggestions in a separate comment.
a. DOS attacks
1. We could make DOS attacks very much more difficult if we used more secure systems. Perhaps the law could be used to mandate a particular level of OS security. 2. We could make them very much more difficult if there was a Trusted Computing. However, for this to be accepted it would have to be an open system. 3. We could make DOS attacks more difficult if ISPs used profiling software to try to determine if a DDOS was happening with outgoing packets from their network. Such software would block suspected DOS packets.
b. DNS
1. A decentralised system would be harder to DDOS, but it's also hard to see how a heirarchical system can also be decentralised; we want one namespace, but we want each subspace to be multihomed, but we don't want clashes. Perhaps this is possible if naming is delegated and crypto checkable, to see who is genuine and who is fake. 2. Run lots more caching.
What other ideas? And are there people taking these forward already?
I class this attack as very serious because an attacker proved that in 1 hour they could take out enough root servers for us to believe that they could do it again, probably for a longer period, and take out all the root servers. And from there there is no reason that they couldn't think about the next layer down. Kill enough and the internet effectively breaks for most people.
So I ask a question: What changes can we make to the infrastructure to: a. Make DOS attacks very much more difficult? b. DNS to make it much more robust to attack?
Ditto - I experienced unusual problems at that time too, and they were related to DNS. It obviously did affect some ordinary people. 10 mins later no problems. And it's very unusual for me to see DNS problems.
If you are travelling cheap then you get to stay in hostels. Wherever you go, if you spend the morning cutting hair for people in the hostel at $5 a shot, you'll have enough to keep yourself in food and bed for the day.
Buy a round-the-world ticket before you go, there are some brilliant bargains to be had at the moment. Tip: choose your travel agency carefully - the good ones will be prepared to change your ticket even though you are the other side of the planet, and will organise a local agent to issue them. Then before you arrive at each country that you are planning on visiting buy a open-ended train ticket - there are great deals for young tourists. That way you can see as much of the country as you like.
Also remember to pack your tent. It's a cheap way to travel. 10 years ago 2 of us went on a circular trip around the edge of the US - 4 months at $3000 in total. And we probably spent $1000 of those in NY.
Perhaps the time has come for some sort of legal recognition of common access rights for some technologies...
- You don't have a conversation quota that you can't exceed. - You aren't blocked from using the roads - there is open access to everyone.
That's because these are commons.
Perhaps, at some penetration point, there needs to be recognition that a technology forms a cultural commons and should be open to all without barriers.
In the same way that monopolies are regulated as a special case, perhaps it would be sensible to have a body of law governing the use of commons. I would think it would need to: - Guarantee access - Prevent enclosure - Promote innovation - Provide for the designation of new commons
Lawrence Lessig are you reading this?
(Bozo's big thought for the day. Now back to work...)
ToonTalk is a non-text representational programming language. You program by 'physically' manipulating things in a cartoon world in the first person. It's a full, sophisticated language with features like parallel-executing functions and the ability to output your program into Java.
At the moment it's sold as a kids toy, but it clearly represents an entirely different programming paradigm.
I think it's one of the most stunning achievements of the last 10 years in software. It's the work of one person. Go Ken go!
Richard Stallman has been thinking about freedom and software for a long time. He's made documented speeches. When I searched in Google for the notes I know someone made of one that I heard in Cambridge, UK, with "cambridge software patent richard stallman" as the search, I found this page http://lpf.ai.mit.edu/Patents/patents.html which has just about everything you need to construct your defence.
It would probably be a fine idea to put your collation online, so that other people can use it too.
Yet , to my knowledge, no project has arisen from the community to mold the next such game.
Do Counter-Strike or Day of Defeat mods count?
Personally I think both are better than Half-Life because they have real-people and I've been addicted to them for the last 8 months.
For/. readers who have no idea what a Zimbabwe is...
Zimbabwe is a country towards the bottom tip of Africa. It's above South Africa which is the Southern most country.
Nominally it's a democracy - a long and vicious war was fought against the colonial-style white dominated government to gain democracy. However the winners, lead by Robert Mugabe, crushed any opposition soon after independence in a terror campaign involving at least tens of thousands of murders.
In recent years another generation of oppostion has arisen. Mugabe is still president; he recently won an election that was marred by intimidation, the large-scale use of terror as a political weapon and the persecution of the opposition. Despite this, and huge electoral fraud, the opposition hold a significant number of seats in parliment.
One of Mugabe's chief tactics in the recent election was to support land reform. Even after more than 20 years of indepence, white people still own most the farmland in Zimbabwe. Mugabe supported a campaign to drive farmers and their workers off their land, and the government has passed laws to seize farms from their owners which are now taking effect. Many of the farms seized have been re-distributed to members of the government. (Corruption is rife; amazingly president Mugabe was the winner of the first lottery!) As a consequence, Zimbabwe which previously had an agricultural surplus (agricultural produce was one of their major exports), now has a huge deficit.
Whilst the drought is a regional problem, a huge amount of blame can be laid directly on Mugabe. His farm policies and use of terror have hugely exacerbated the problem, his war in a neighbouring country has wiped out the Zim dollar and made it impossible for Zimbabwe to afford to import food. In a saner world he would be standing trial on many counts.
Readers should take the claims of not wanting to use genetically modified wheat because of contimination with a whole shipload of salt. Nothing that he or the Zimbabwe government says can taken at face value; you can only judge by his actions, which speak nothing about caring for his nation.
I consider myself journeyman; I've done this a few times on projects with 8 people * 4 months and 8 people * 2 years, and several projects of 2 people * 1~2 months, on projects that produced commercial shrinkwrap software, custom software for external clients, and software used internally.
1. Don't think of this as a cost cutting exercise. You may end up spending more money than you would have. Consider it a quality raising exercise; in many parts of the world you can get better people for the same price than you can where you are.
2. Pick your partners with extreme care.
Typically you won't meet these people before you agree a deal. Look at a lot of teams, and look very carefully. Follow up their references. Examine their work. Build up a scoresheet. You will be at least 1/3 through the project before you can validate your decision.
Choose people you like. You need to be able to work together - sometimes more closely than if you were in the same room.
Try to choose on the basis of having a long-term relationship. If your project succeeds then you probably will have one.
You need to budget a significant amount of time to do this. Budget proportional to the overall size and potential loss if the project fails. The rule-of-thumb is that you should expect to spend 1 month for each 4 months of project time. That is, for a project scheduled to last a year, you shouldn't be surprised to have to spend 3 months finding your partners.
3. To succeed, the team leader on your side needs a *really* good understanding of different cultures. This is critical.
In different countries, the average person behaves differently in the same circumstances. Unless you understand the cultural cues that people are giving, you won't understand what is really happening. You need to make sure that you are picking up on these cues or your picture will diverge from reality.
For instance - things to watch out for: - Are you, or some of your team, women? Are your counterparts comfortable with being told what to do by a woman. In some parts of the world this can be a real issue. - Do you understand and have sympathy for the religious beliefs of your counterparts. If you hire people who have a Muslim background, for instance, you should schedule meetings so that they are free at prayer time. - Are there political tensions you need to consider? If you are working for a major corporate client, and your counterparts have access to potentially embarrassing documents, servers, sites or whatever, could this be a problem? - What are the language barriers? - Politics part 2. You also need to be aware of this on a wider scale - depending on where your partners are, it's quite possible that a war could interrupt your work. - UI design is culturally intensive work. - And much more.
Look for team-leaders/contact points that have experience of more than 2 cultures.
3. It's not the culture that matters it's the people.
Yes, the cultural thing matters a huge amount, but the individual people matter even more. You need to spend time developing personal relationships. You need to budget for this. This is even more important in light of the point 4.
There is an area of potential difficulty here... the nature of the jobs change. The people on your team are there to manage a process now, not to do the process. If you have a team of developers, then you may have a big problem; they are not going to be doing development. They are going to be contributing towards managing a development process. Do the people on your team have the necessary skills and aptitudes? Are they going to be bored and leave during the life of the project? What can you do to militate against the danger?
4. Contract and recourse. You should work through a process of establishing a contract. But don't think that this is worth the paper it's written on. Its purpose is to establish a level of trust. If the project fails you have no practical recourse - it's a risk you take.
In my experience, once you have a contract you should be permissive about behaviour; the contract is usually fixed, but the nature of the task usually changes.
For instance, the contract will usually depend on a specification. It is very unusual for your spec to be complete. And it's likely that you will change items in the spec. Your contract should allow for these variations. It's a healthy situation to have give and take.
Do not enter an agreement where you talk to one person, but you never get to talk to the team.
4. Use a designated point-of-contact on either side. This is pretty much a full-time job for both these people. This relationship is critical.
You should assume nothing. You should be explicit about anything you want. You should repeatedly check that your counterpart understands in the same way that you do by asking for feedback.
You need to trust these people deeply (on both sides). If you feel that you don't, then kill the project, and do it early.
This is a difficult job. Externally this person needs to represent your point-of-view. Internally this person needs to represent the pov of your partners. Your internal team, and especially management, needs to understand that this is the job of this person. This is most important in a conflict situation.
5. Communication.
Establish several threads of conversation and explicitly mark them...
You will need a meta thread to discuss the project as a whole. You will need a thread to discuss schedule. You will need a day-to-day thread. You will need a thread for handling the formal changes - for instance if you want a new feature, you should discuss the possibilities in the day-to-day thread, but your partners should understand that they should only initiate action on this discussion once you have made a formal request.
You may need other threads too, depending on your circumstances.
5. Working practices (closely related to communication).
You need to set up fixed processes and working practices, and have well-defined areas of responsibility. You can't be woolly about any of this or it won't happen.
Set up a way to track issues so that they either have a resolution. This could be a spreadsheet, a web site. Keep the tracking mechanism separate from the mechanism you use to discuss the issue (probably email). Make sure that your partners follow this issue list. They should have power over it too.
Set up a code transfer mechanism, and standards - for instance is it a pre-requisite that the daily build is working?
You should definitely use a code versioning tool on any project larger than a month, or with more than 2 people. Establish firm rules for where the master lives.
Set up regular checkpoints. You need to establish these well ahead of time, and list the things that are important to meet the checkpoint. Of course these may be in conflict with the software design; some of the targets are likely to be there because of political pressure. That's why you need someone on your team who has an understanding of the design of the software. You need to ask for things that are sensible. Not impossible. Your partners may want to demo the software to you at the checkpoints. Or you may want to run a gamut of formal tests and report on the results.
6. Expect to have a separate Q+A person on your side.
In many cases, when you work on a team that's internal to your company, you don't need a Q+A person. When you are dealing with external developers you MUST have a Q+A thread and person. It's your way of measuring the health of the project.
Your Q+A person should have a good understanding of software development so that they can find the issues of concern... there's no point in complaining about the font size when the fundamental framework of the app is broken.
You should build test packs. Your partners should have access to these. Depending on the complexity of the app, and its purpose, you should consider building an automatic regression test framework into the code.
7. Payment.
This is your leverage, but you need to be very sensitive to the needs of your partner.
There can be problems getting payments to people. Set up the mechanism and test it with a small payment. You and your partners need to understand the lead times involved. These are often of the order of two to three weeks.
Once you make a payment, you should provide some documentary proof to your partners.
8. Close
When the project is finished then you should celebrate. It's very difficult to do this with people that are far away. Send gifts. Say thank you. Don't just kill the relationship - these people can be your friends.
For readers not in the UK: there is a cultural bias in the UK towards headbutting. Go to an Accident & Emergency on a Friday or Saturday night and you will find someone with a broken nose who has been in a fight at closing time. (That's when pubs and bars have to close by law.)
The PG is warranted because in the UK we believe there's a link between watching and doing. (Please don't even bother arguing about this - think of adverts before you press a single key.)
And we think it's a good idea not to do things that encourage violence by depicting realistic scenes or glamourising it.
I used OS/2 for some time. I wrote software for it and on it and did systems integration with it. I am agnostic abou platform.
1. Spending a bucket load of money doesn't mean that you will gain users. It's a network econmony dummy - it has to be safe for users to test and migrate before they can migrate.
2. Don't make an OS with some really good features but forget the fundamentals that have shaped computing... the file system sounded great in concept, but proved to be difficult because it used different paradigms from the ones that users were used to.
3. It matters how things look. It matters a *lot*. Windows 95 and later just looked much better.
4. It matters that the applications that you are used to work flawlessly (and with no work on the part of the user) on the new OS. Otherwise people won't transition.
5. Speed matters. OS/2 sometimes felt slow slow slow. I used a dual boot machine. Windows at the time felt faster.
6. Don't sell the OS as something that doesn't crash when it does.
7. Support a huge range of hardware. It makes it difficult to switch if you have to buy new hardware. By contrast Windows pretty much worked on most hardware.
Mr Mundie is telling the truth; the GPL makes it impossible for anyone to monopolise software and derivatives. From the point of view of a company, this is a bad thing because it reduces the power that you have over your consumers. Where software is distributed under the GPL, the price of the software must fall to zero or close on zero because the supply is infinite regardless of the demand. That's because *anyone* can re-distribute GPLed software, and in fact is required to. So, it is quite true that it is probably impossible to make extremely high margins on GPLed software. It is also true that if those margins are not available then there is very little incentive (as a software company) to spend large amounts of money when there is no way for them to protect that investment, and reoup it together with profits.
The companies like IBM who may be spending money on GPLed software are doing it because they are making money on hardware.
I give you two amusing web pages: Need To Know and Naked News (Click through for the news page and start the sample). Which page is best Grasshopper? Weigh the thought most carefully in your head - is the page with almost only text best because it loads quickly? Or does the page with graphics make you feel better? Is a functional page better than an experimental art page? Feel your way around the categories that the question generates.
Ahaa Grasshopper!, you have discovered that it depends on your audience. There is no single answer to your question - sometimes wonderful graphics are good, and sometimes plain is good.
A wiser question perhaps is - What are the the underlying rules of good design? Sadly Grasshopper we cannot tell you, for it is akin to sculpture - the masters of the art take many years to come to an understanding. We can only show you the tools, you must learn yourself by doing.
Learn like the masters. Study the web pages you meet, compare and contrast them to help you gain an understanding of how they work and the degree of success. Most learning will show you what not to do. Buy some books on design and think how you could apply the ideas that they propose. Remember that those that profess themselves to be masters are often people who can no longer learn. Be wary of their advice. Think of your web pages in various ways - grids, spirals, concentric circles and other patterns - examine the possible layouts and feels that these generate. Consider whether dynamic or fixed sizing will be best for your audience. Consider your web page as your clay and mould it so that it feels good to you. Then ask some ordinary users how you can improve it.
Here is a crumb I can offer to help you down the difficult path you have chosen to follow... http://www.tangledtime.com/article.php3?sid=200012 01184155 for some ideas. Disclosure: I wrote that and much of it has become outdated as the design language of the web has evolved.
But don't throw stones if you live in glass houses. Americans are guilty of genocide against the native Americans, a fair proportion of the country believes that the wrong side won a war that was fought (in part) to end slavery. (Do these people then still believe that perhaps a bit of slavery would be good now?) The English as a nation are responsible for the deaths of millions during the Irish potato famine, the effects of which are still felt hundreds of years later. The Belgiums let their King run amock in the Congo; chopping off hands isn't a new African tradition. In Africa a few years ago we allowed the UN to withdraw from the developing genocide in Rwanda - subsequently more than a million people were hacked to death. In Bosnia we promised the people of a UN safe haven that we would not let them come to harm, and then sat by while the haven was overrun, and then denied culpability when 16,000 (?) men and boys were lined up and machine gunned. During World War 2 almost all western countries denied that the holocaust was happening; some denied access to Jews.
And in each of these, and many many more cases, I am absolutely certain that good, ordinary people sat by and either were not goaded into action, or were too scared, or couldn't understand what was happening.
Lesson: Not all French collaborated. A few did. Others were too scared or confused to resist.
Well folks, it's been just lovely to see the racism on display. (For those of you who have little understanding of the previous sentence - this is sarcasm.)
So much for the internet promoting tolerance and understanding between people and nations.
Nazism is abhorrent. The law in France forbids the glorification of Nazism. Which is entirely justifiable considering what happened in Europe just 50 years ago.
The French are a democratic nation. This means that they (and their judges) are can make whatever law they wish to, and we should support them because laws applied in France to French residents are entirely reasonable. In this sense, a law requiring Yahoo employees to balance boiled eggs on their noses, to display Yahoo pages in green type in French when displaying those pages to people in France, or to perform any other action is ENTIRELY REASONABLE. (Yes, I meant to shout.)
There may be a problem implementing the decision. You may be living in the USA where you don't have the first clue about the effects of Nazism. But nothing at all can excuse the frankly vile racist commentary that this issue is generating.
From the outside since I'm not an American, and don't live there.
It's not the voting system that counts - almost all voting systems have in-built bias. If you have a fairish *voting* system then you are probably democratic, as long as someone can't manipulate the vote.
However - I don't know how anyone could argue that the best person out of America's 280(?) million citizens to be president is likely to be the son of an ex-president. That's statistically unlikely. Therefore if Bush is elected, your electoral system can be manipulated. I suspect by using money. And if he is elected you will have demonstrated to the world that you do not have a democratic system.
I've outsourced a great deal of work; I worked for a software company that worked along the lines of a publisher. My job involved co-ordinating many outsourced projects. Developer by background. Here's a list of some important things to remember.
1. Cultural issues. The person managing has to have a very clear understanding of cultural sensitivities. Ideally they will have travelled widely and lived in several countries so that they understand why and how other people behave. Having a grip on this is probably the most important problem to solve because it alters how you behave.
2. Don't bother for small assignments. The overhead of managing is larger than it is worth. Only outsource large developments where the cost savings can be huge. Plan on having a long-term relationship.
3. Find developers who are in the top 5%. Do not work with anyone who is not excellent. You will be wasting your time and money.
4. Be prepared to devote one person full-time to managing the project. You will only get what you want with clear specification. But as we all know initial specifications are never right. You overcome the problem with continuous feedback. Talk several times a day.
5. Be prepared to visit quarterly for a week or two.
6. Pay on goals achieved and not time worked. Be flexible on the first few payments - you need to set up a metric so that you are paying regularly for goals achieved. Always always always budget for slippage. Despite paying on goals remember that people need to eat. If they fail to hit a goal you need a system worked out to make sure that you are not starving them of income. You do not have to tell them about the system though. You do not want them to have to take on other work because your project will come 2nd place.
7. Try very hard to set the mood. When you have in-house developers you can respond instantly to despondency. It's so much harder when people are far away. Remember that people are people - do the things that you would do if they were sitting next to you. Have the company pay for the team to go to dinner. Arrange for flowers. Judging the mood is another reason for point 1.
8. Don't micro-manage. For instance, let them take all the architectural design decisions. But do keep a constant check on the state of things. Ask questions about the internals.
9. Be prepared to bring in outside expertise. Make sure that the team understands this and understands that this is not any sort of insult. For instance - user interfaces have quite deep cultural influences. If your UI is designed by someone without an understanding of the culture it is designed for then the final item is likely to be unappealing. For instance - imagine developing a mail program. If you put a US style mailbox on a button then it will not be recognised in Europe. If you use Indian colour mixes Westerners may find the interface garish. If you the interface involves scenes then the scenes may be alien - a program teaching kids about money set in the gun fighting Old West will have zero appeal to teachers in Germany. Especially when the key character (a talking gunfighter dollar sign) appears. You may have guessed that these are real world examples.
10. Be prepared to work odd hours. Asynchronous communication slows things doooooooowwwwwwwwwwwnnnnnn.
11. Empathise.
12. Watch the budget like a snake watching a mouse. When you outsource you give up direct controls - but you do still control money flow.
13. Be prepared to kill the project. Have clauses in the contract that allow escape routes. Have your fallback position planned. The first project with a new team is the riskiest.
14. Have a good contract. Make sure that you explain the contract in clear normal language and not legalese. Double check that they understand what they are agreeing to do. Triple check. Spend more time than you have to. Develop trust. Make very sure that everyone understands what belongs to who when and what the deliverables are. And what belongs to who if things go badly. Then forget the contract - it pretty worthless as a piece of paper. If things go badly you can pretty much kiss your investment goodbye - trying to sue across borders is not worth your time, effort, money. The value of spending time on the contract is that you make sure that everyone knows what they are supposed to do. Be prepared to negotiate contract addendums as the project continues. Nothing ever matches plans. Ever. You will need to change the terms. Be prepared to be flexible.
15. If it's possible test the people concerned with a small project before diving in the deep end. Remember: the first project is the riskiest.
If you need help - I do consultancy.
Jeff Veit
http://www.tanasity.com/ - Tanasity develops software and net applications
http://www.tangledtime.com/ - New! Discussion about the net, software and business - come and contribute
I don't know enough about C# to judge yet, but it's clear that you aren't taking a thinking-persons stance here.
Let's deal with your points 1 by 1.
1: It's been shown a few times that incremental languages are successful and revolutionary ones aren't. C++ was incremental on C. Eiffel was revolutionary. Which is in greater use. Leave the revolutionary stuff to experimental languages but be clear that ideas extracted from those languages and implemented in a incremental way are ideas that are successful.
2: Schizo Gerbil. Jeeze - get a grip. Does C++ keep all semantics the same as C? Nope. Does Java?
3. Non-open runtime. Really you don't know because the language is not ready for use yet. However Anders has said that the lnguage and all the other MS languages will compile down to run on top of the.Net runtime engine. He has also said that the language will be submittes to ECMA, so you can reasonably expect runtimes to exist for other platforms.
4. No real standard. They have said they will submit to ECMA.
You are facing a very similar dilemma to the one I face. I've come to the conclusion that for the stuff I am working on Open Source is a lovely idea, but impractical.
Firstly - the GPL is designed in such a way to guarantee that if you try to sell your software as a product, and are making good profit margins, that someone will undercut you, using your own work; it removes barriers to entry.
Secondly - there are very very very few OS companies whose primary product is a software package that are making money. If you know of one, tell me so that I can offer their software at a cheaper price than they do.
It seems that if you are a software developer hoping to make money by selling a product that you are dead in the water.
The standard suggestion is that you offer services rather than the software. For you that's an option, since you are selling into a 9's situation. For small or medium sized packages software designed for ease-of-use this does not seem to offer much hope.
(However I do think that packages with very small and larger scale user base can benefit by going OS. So Zope works because it has a large enough user base to generate service needs. Of course if there is a sinificant amount of code the demand for the original author increases.
There are a bunch of other models - I don't see many of them offering much hope...
Personalisation. Performance. Sponsorship. Last version is Open. Non-Open, with access to Source.
My advice - the Closed Source model has a history of making money, be cautious and stay with it unless there very very good financial reasons (not warm fuzziness) for going Open.
Slashdot Mirror
I thought I would make some suggestions in a separate comment.
a. DOS attacks
1. We could make DOS attacks very much more difficult if we used more secure systems. Perhaps the law could be used to mandate a particular level of OS security.
2. We could make them very much more difficult if there was a Trusted Computing. However, for this to be accepted it would have to be an open system.
3. We could make DOS attacks more difficult if ISPs used profiling software to try to determine if a DDOS was happening with outgoing packets from their network. Such software would block suspected DOS packets.
b. DNS
1. A decentralised system would be harder to DDOS, but it's also hard to see how a heirarchical system can also be decentralised; we want one namespace, but we want each subspace to be multihomed, but we don't want clashes. Perhaps this is possible if naming is delegated and crypto checkable, to see who is genuine and who is fake.
2. Run lots more caching.
What other ideas? And are there people taking these forward already?
Jeff Veit
I class this attack as very serious because an attacker proved that in 1 hour they could take out enough root servers for us to believe that they could do it again, probably for a longer period, and take out all the root servers. And from there there is no reason that they couldn't think about the next layer down. Kill enough and the internet effectively breaks for most people.
So I ask a question: What changes can we make to the infrastructure to:
a. Make DOS attacks very much more difficult?
b. DNS to make it much more robust to attack?
Ditto - I experienced unusual problems at that time too, and they were related to DNS. It obviously did affect some ordinary people. 10 mins later no problems. And it's very unusual for me to see DNS problems.
If you are travelling cheap then you get to stay in hostels. Wherever you go, if you spend the morning cutting hair for people in the hostel at $5 a shot, you'll have enough to keep yourself in food and bed for the day.
Buy a round-the-world ticket before you go, there are some brilliant bargains to be had at the moment. Tip: choose your travel agency carefully - the good ones will be prepared to change your ticket even though you are the other side of the planet, and will organise a local agent to issue them. Then before you arrive at each country that you are planning on visiting buy a open-ended train ticket - there are great deals for young tourists. That way you can see as much of the country as you like.
Also remember to pack your tent. It's a cheap way to travel. 10 years ago 2 of us went on a circular trip around the edge of the US - 4 months at $3000 in total. And we probably spent $1000 of those in NY.
Perhaps the time has come for some sort of legal recognition of common access rights for some technologies...
- You don't have a conversation quota that you can't exceed.
- You aren't blocked from using the roads - there is open access to everyone.
That's because these are commons.
Perhaps, at some penetration point, there needs to be recognition that a technology forms a cultural commons and should be open to all without barriers.
In the same way that monopolies are regulated as a special case, perhaps it would be sensible to have a body of law governing the use of commons.
I would think it would need to:
- Guarantee access
- Prevent enclosure
- Promote innovation
- Provide for the designation of new commons
Lawrence Lessig are you reading this?
(Bozo's big thought for the day. Now back to work...)
Thank you.
ToonTalk is a non-text representational programming language. You program by 'physically' manipulating things in a cartoon world in the first person. It's a full, sophisticated language with features like parallel-executing functions and the ability to output your program into Java.
At the moment it's sold as a kids toy, but it clearly represents an entirely different programming paradigm.
I think it's one of the most stunning achievements of the last 10 years in software. It's the work of one person. Go Ken go!
If you have kids, let them try it.
http://www.toontalk.com/
Richard Stallman has been thinking about freedom and software for a long time. He's made documented speeches. When I searched in Google for the notes I know someone made of one that I heard in Cambridge, UK, with "cambridge software patent richard stallman" as the search, I found this page http://lpf.ai.mit.edu/Patents/patents.html which has just about everything you need to construct your defence.
It would probably be a fine idea to put your collation online, so that other people can use it too.
Regards,
Jeff Veit
Do Counter-Strike or Day of Defeat mods count? Personally I think both are better than Half-Life because they have real-people and I've been addicted to them for the last 8 months.
Jeff
Zimbabwe is a country towards the bottom tip of Africa. It's above South Africa which is the Southern most country.
Nominally it's a democracy - a long and vicious war was fought against the colonial-style white dominated government to gain democracy. However the winners, lead by Robert Mugabe, crushed any opposition soon after independence in a terror campaign involving at least tens of thousands of murders.
In recent years another generation of oppostion has arisen. Mugabe is still president; he recently won an election that was marred by intimidation, the large-scale use of terror as a political weapon and the persecution of the opposition. Despite this, and huge electoral fraud, the opposition hold a significant number of seats in parliment.
One of Mugabe's chief tactics in the recent election was to support land reform. Even after more than 20 years of indepence, white people still own most the farmland in Zimbabwe. Mugabe supported a campaign to drive farmers and their workers off their land, and the government has passed laws to seize farms from their owners which are now taking effect. Many of the farms seized have been re-distributed to members of the government. (Corruption is rife; amazingly president Mugabe was the winner of the first lottery!) As a consequence, Zimbabwe which previously had an agricultural surplus (agricultural produce was one of their major exports), now has a huge deficit.
Whilst the drought is a regional problem, a huge amount of blame can be laid directly on Mugabe. His farm policies and use of terror have hugely exacerbated the problem, his war in a neighbouring country has wiped out the Zim dollar and made it impossible for Zimbabwe to afford to import food. In a saner world he would be standing trial on many counts.
Readers should take the claims of not wanting to use genetically modified wheat because of contimination with a whole shipload of salt. Nothing that he or the Zimbabwe government says can taken at face value; you can only judge by his actions, which speak nothing about caring for his nation.
Delicious with Spaghetti Code.
Jeff
I'm not very keen on the marketing half-truths in the MS document. (Disclosure - I use Windows mostly and Linux occasionally.)
The obvious thing for the Linux community to do is to build a point-by-point rebuttal and counter argument to the MS document.
Does anyone have some Wiki space that they would like to donate?
Regards,
Jeff Veit
Definitely.
I consider myself journeyman; I've done this a few times on projects with 8 people * 4 months and 8 people * 2 years, and several projects of 2 people * 1~2 months, on projects that produced commercial shrinkwrap software, custom software for external clients, and software used internally.
1. Don't think of this as a cost cutting exercise. You may end up spending more money than you would have. Consider it a quality raising exercise; in many parts of the world you can get better people for the same price than you can where you are.
2. Pick your partners with extreme care.
Typically you won't meet these people before you agree a deal. Look at a lot of teams, and look very carefully. Follow up their references. Examine their work. Build up a scoresheet. You will be at least 1/3 through the project before you can validate your decision.
Choose people you like. You need to be able to work together - sometimes more closely than if you were in the same room.
Try to choose on the basis of having a long-term relationship. If your project succeeds then you probably will have one.
You need to budget a significant amount of time to do this. Budget proportional to the overall size and potential loss if the project fails. The rule-of-thumb is that you should expect to spend 1 month for each 4 months of project time. That is, for a project scheduled to last a year, you shouldn't be surprised to have to spend 3 months finding your partners.
3. To succeed, the team leader on your side needs a *really* good understanding of different cultures. This is critical.
In different countries, the average person behaves differently in the same circumstances. Unless you understand the cultural cues that people are giving, you won't understand what is really happening. You need to make sure that you are picking up on these cues or your picture will diverge from reality.
For instance - things to watch out for:
- Are you, or some of your team, women? Are your counterparts comfortable with being told what to do by a woman. In some parts of the world this can be a real issue.
- Do you understand and have sympathy for the religious beliefs of your counterparts. If you hire people who have a Muslim background, for instance, you should schedule meetings so that they are free at prayer time.
- Are there political tensions you need to consider? If you are working for a major corporate client, and your counterparts have access to potentially embarrassing documents, servers, sites or whatever, could this be a problem?
- What are the language barriers?
- Politics part 2. You also need to be aware of this on a wider scale - depending on where your partners are, it's quite possible that a war could interrupt your work.
- UI design is culturally intensive work.
- And much more.
Look for team-leaders/contact points that have experience of more than 2 cultures.
3. It's not the culture that matters it's the people.
Yes, the cultural thing matters a huge amount, but the individual people matter even more. You need to spend time developing personal relationships. You need to budget for this. This is even more important in light of the point 4.
There is an area of potential difficulty here... the nature of the jobs change. The people on your team are there to manage a process now, not to do the process. If you have a team of developers, then you may have a big problem; they are not going to be doing development. They are going to be contributing towards managing a development process. Do the people on your team have the necessary skills and aptitudes? Are they going to be bored and leave during the life of the project? What can you do to militate against the danger?
4. Contract and recourse.
You should work through a process of establishing a contract. But don't think that this is worth the paper it's written on. Its purpose is to establish a level of trust. If the project fails you have no practical recourse - it's a risk you take.
In my experience, once you have a contract you should be permissive about behaviour; the contract is usually fixed, but the nature of the task usually changes.
For instance, the contract will usually depend on a specification. It is very unusual for your spec to be complete. And it's likely that you will change items in the spec. Your contract should allow for these variations. It's a healthy situation to have give and take.
Do not enter an agreement where you talk to one person, but you never get to talk to the team.
4. Use a designated point-of-contact on either side. This is pretty much a full-time job for both these people. This relationship is critical.
You should assume nothing. You should be explicit about anything you want. You should repeatedly check that your counterpart understands in the same way that you do by asking for feedback.
You need to trust these people deeply (on both sides). If you feel that you don't, then kill the project, and do it early.
This is a difficult job. Externally this person needs to represent your point-of-view. Internally this person needs to represent the pov of your partners. Your internal team, and especially management, needs to understand that this is the job of this person. This is most important in a conflict situation.
5. Communication.
Establish several threads of conversation and explicitly mark them...
You will need a meta thread to discuss the project as a whole. You will need a thread to discuss schedule. You will need a day-to-day thread. You will need a thread for handling the formal changes - for instance if you want a new feature, you should discuss the possibilities in the day-to-day thread, but your partners should understand that they should only initiate action on this discussion once you have made a formal request.
You may need other threads too, depending on your circumstances.
5. Working practices (closely related to communication).
You need to set up fixed processes and working practices, and have well-defined areas of responsibility. You can't be woolly about any of this or it won't happen.
Set up a way to track issues so that they either have a resolution. This could be a spreadsheet, a web site. Keep the tracking mechanism separate from the mechanism you use to discuss the issue (probably email). Make sure that your partners follow this issue list. They should have power over it too.
Set up a code transfer mechanism, and standards - for instance is it a pre-requisite that the daily build is working?
You should definitely use a code versioning tool on any project larger than a month, or with more than 2 people. Establish firm rules for where the master lives.
Set up regular checkpoints. You need to establish these well ahead of time, and list the things that are important to meet the checkpoint. Of course these may be in conflict with the software design; some of the targets are likely to be there because of political pressure. That's why you need someone on your team who has an understanding of the design of the software. You need to ask for things that are sensible. Not impossible. Your partners may want to demo the software to you at the checkpoints. Or you may want to run a gamut of formal tests and report on the results.
6. Expect to have a separate Q+A person on your side.
In many cases, when you work on a team that's internal to your company, you don't need a Q+A person. When you are dealing with external developers you MUST have a Q+A thread and person. It's your way of measuring the health of the project.
Your Q+A person should have a good understanding of software development so that they can find the issues of concern... there's no point in complaining about the font size when the fundamental framework of the app is broken.
You should build test packs. Your partners should have access to these. Depending on the complexity of the app, and its purpose, you should consider building an automatic regression test framework into the code.
7. Payment.
This is your leverage, but you need to be very sensitive to the needs of your partner.
There can be problems getting payments to people. Set up the mechanism and test it with a small payment. You and your partners need to understand the lead times involved. These are often of the order of two to three weeks.
Once you make a payment, you should provide some documentary proof to your partners.
8. Close
When the project is finished then you should celebrate. It's very difficult to do this with people that are far away. Send gifts. Say thank you. Don't just kill the relationship - these people can be your friends.
Good luck!
For readers not in the UK: there is a cultural bias in the UK towards headbutting. Go to an Accident & Emergency on a Friday or Saturday night and you will find someone with a broken nose who has been in a fight at closing time. (That's when pubs and bars have to close by law.)
The PG is warranted because in the UK we believe there's a link between watching and doing. (Please don't even bother arguing about this - think of adverts before you press a single key.)
And we think it's a good idea not to do things that encourage violence by depicting realistic scenes or glamourising it.
I used OS/2 for some time. I wrote software for it and on it and did systems integration with it. I am agnostic abou platform.
1. Spending a bucket load of money doesn't mean that you will gain users. It's a network econmony dummy - it has to be safe for users to test and migrate before they can migrate.
2. Don't make an OS with some really good features but forget the fundamentals that have shaped computing... the file system sounded great in concept, but proved to be difficult because it used different paradigms from the ones that users were used to.
3. It matters how things look. It matters a *lot*. Windows 95 and later just looked much better.
4. It matters that the applications that you are used to work flawlessly (and with no work on the part of the user) on the new OS. Otherwise people won't transition.
5. Speed matters. OS/2 sometimes felt slow slow slow. I used a dual boot machine. Windows at the time felt faster.
6. Don't sell the OS as something that doesn't crash when it does.
7. Support a huge range of hardware. It makes it difficult to switch if you have to buy new hardware. By contrast Windows pretty much worked on most hardware.
Mr Mundie is telling the truth; the GPL makes it impossible for anyone to monopolise software and derivatives. From the point of view of a company, this is a bad thing because it reduces the power that you have over your consumers. Where software is distributed under the GPL, the price of the software must fall to zero or close on zero because the supply is infinite regardless of the demand. That's because *anyone* can re-distribute GPLed software, and in fact is required to. So, it is quite true that it is probably impossible to make extremely high margins on GPLed software. It is also true that if those margins are not available then there is very little incentive (as a software company) to spend large amounts of money when there is no way for them to protect that investment, and reoup it together with profits.
The companies like IBM who may be spending money on GPLed software are doing it because they are making money on hardware.
I give you two amusing web pages: Need To Know and Naked News (Click through for the news page and start the sample). Which page is best Grasshopper? Weigh the thought most carefully in your head - is the page with almost only text best because it loads quickly? Or does the page with graphics make you feel better? Is a functional page better than an experimental art page? Feel your way around the categories that the question generates.
Ahaa Grasshopper!, you have discovered that it depends on your audience. There is no single answer to your question - sometimes wonderful graphics are good, and sometimes plain is good.
A wiser question perhaps is - What are the the underlying rules of good design? Sadly Grasshopper we cannot tell you, for it is akin to sculpture - the masters of the art take many years to come to an understanding. We can only show you the tools, you must learn yourself by doing.
Learn like the masters. Study the web pages you meet, compare and contrast them to help you gain an understanding of how they work and the degree of success. Most learning will show you what not to do. Buy some books on design and think how you could apply the ideas that they propose. Remember that those that profess themselves to be masters are often people who can no longer learn. Be wary of their advice. Think of your web pages in various ways - grids, spirals, concentric circles and other patterns - examine the possible layouts and feels that these generate. Consider whether dynamic or fixed sizing will be best for your audience. Consider your web page as your clay and mould it so that it feels good to you. Then ask some ordinary users how you can improve it.
Here is a crumb I can offer to help you down the difficult path you have chosen to follow... http://www.tangledtime.com/article.php3?sid=200012 01184155 for some ideas. Disclosure: I wrote that and much of it has become outdated as the design language of the web has evolved.
Yes, that's absolutely true.
But don't throw stones if you live in glass houses. Americans are guilty of genocide against the native Americans, a fair proportion of the country believes that the wrong side won a war that was fought (in part) to end slavery. (Do these people then still believe that perhaps a bit of slavery would be good now?) The English as a nation are responsible for the deaths of millions during the Irish potato famine, the effects of which are still felt hundreds of years later. The Belgiums let their King run amock in the Congo; chopping off hands isn't a new African tradition. In Africa a few years ago we allowed the UN to withdraw from the developing genocide in Rwanda - subsequently more than a million people were hacked to death. In Bosnia we promised the people of a UN safe haven that we would not let them come to harm, and then sat by while the haven was overrun, and then denied culpability when 16,000 (?) men and boys were lined up and machine gunned. During World War 2 almost all western countries denied that the holocaust was happening; some denied access to Jews.
And in each of these, and many many more cases, I am absolutely certain that good, ordinary people sat by and either were not goaded into action, or were too scared, or couldn't understand what was happening.
Lesson: Not all French collaborated. A few did. Others were too scared or confused to resist.
Jeff
Well folks, it's been just lovely to see the racism on display. (For those of you who have little understanding of the previous sentence - this is sarcasm.)
So much for the internet promoting tolerance and understanding between people and nations.
Nazism is abhorrent. The law in France forbids the glorification of Nazism. Which is entirely justifiable considering what happened in Europe just 50 years ago.
The French are a democratic nation. This means that they (and their judges) are can make whatever law they wish to, and we should support them because laws applied in France to French residents are entirely reasonable. In this sense, a law requiring Yahoo employees to balance boiled eggs on their noses, to display Yahoo pages in green type in French when displaying those pages to people in France, or to perform any other action is ENTIRELY REASONABLE. (Yes, I meant to shout.)
There may be a problem implementing the decision. You may be living in the USA where you don't have the first clue about the effects of Nazism. But nothing at all can excuse the frankly vile racist commentary that this issue is generating.
From the outside since I'm not an American, and don't live there.
It's not the voting system that counts - almost all voting systems have in-built bias. If you have a fairish *voting* system then you are probably democratic, as long as someone can't manipulate the vote.
However - I don't know how anyone could argue that the best person out of America's 280(?) million citizens to be president is likely to be the son of an ex-president. That's statistically unlikely. Therefore if Bush is elected, your electoral system can be manipulated. I suspect by using money. And if he is elected you will have demonstrated to the world that you do not have a democratic system.
I've outsourced a great deal of work; I worked for a software company that worked along the lines of a publisher. My job involved co-ordinating many outsourced projects. Developer by background. Here's a list of some important things to remember.
1. Cultural issues. The person managing has to have a very clear understanding of cultural sensitivities. Ideally they will have travelled widely and lived in several countries so that they understand why and how other people behave. Having a grip on this is probably the most important problem to solve because it alters how you behave.
2. Don't bother for small assignments. The overhead of managing is larger than it is worth. Only outsource large developments where the cost savings can be huge. Plan on having a long-term relationship.
3. Find developers who are in the top 5%. Do not work with anyone who is not excellent. You will be wasting your time and money.
4. Be prepared to devote one person full-time to managing the project. You will only get what you want with clear specification. But as we all know initial specifications are never right. You overcome the problem with continuous feedback. Talk several times a day.
5. Be prepared to visit quarterly for a week or two.
6. Pay on goals achieved and not time worked. Be flexible on the first few payments - you need to set up a metric so that you are paying regularly for goals achieved. Always always always budget for slippage. Despite paying on goals remember that people need to eat. If they fail to hit a goal you need a system worked out to make sure that you are not starving them of income. You do not have to tell them about the system though. You do not want them to have to take on other work because your project will come 2nd place.
7. Try very hard to set the mood. When you have in-house developers you can respond instantly to despondency. It's so much harder when people are far away. Remember that people are people - do the things that you would do if they were sitting next to you. Have the company pay for the team to go to dinner. Arrange for flowers. Judging the mood is another reason for point 1.
8. Don't micro-manage. For instance, let them take all the architectural design decisions. But do keep a constant check on the state of things. Ask questions about the internals.
9. Be prepared to bring in outside expertise. Make sure that the team understands this and understands that this is not any sort of insult. For instance - user interfaces have quite deep cultural influences. If your UI is designed by someone without an understanding of the culture it is designed for then the final item is likely to be unappealing. For instance - imagine developing a mail program. If you put a US style mailbox on a button then it will not be recognised in Europe. If you use Indian colour mixes Westerners may find the interface garish. If you the interface involves scenes then the scenes may be alien - a program teaching kids about money set in the gun fighting Old West will have zero appeal to teachers in Germany. Especially when the key character (a talking gunfighter dollar sign) appears. You may have guessed that these are real world examples.
10. Be prepared to work odd hours. Asynchronous communication slows things doooooooowwwwwwwwwwwnnnnnn.
11. Empathise.
12. Watch the budget like a snake watching a mouse. When you outsource you give up direct controls - but you do still control money flow.
13. Be prepared to kill the project. Have clauses in the contract that allow escape routes. Have your fallback position planned. The first project with a new team is the riskiest.
14. Have a good contract. Make sure that you explain the contract in clear normal language and not legalese. Double check that they understand what they are agreeing to do. Triple check. Spend more time than you have to. Develop trust. Make very sure that everyone understands what belongs to who when and what the deliverables are. And what belongs to who if things go badly. Then forget the contract - it pretty worthless as a piece of paper. If things go badly you can pretty much kiss your investment goodbye - trying to sue across borders is not worth your time, effort, money. The value of spending time on the contract is that you make sure that everyone knows what they are supposed to do. Be prepared to negotiate contract addendums as the project continues. Nothing ever matches plans. Ever. You will need to change the terms. Be prepared to be flexible.
15. If it's possible test the people concerned with a small project before diving in the deep end. Remember: the first project is the riskiest.
If you need help - I do consultancy.
Jeff Veit
http://www.tanasity.com/ - Tanasity develops software and net applications
http://www.tangledtime.com/ - New! Discussion about the net, software and business - come and contribute
Tel: +44 (0)1223 721513
There are people out there working on this.
Look at http://www.halfbakery.com/editorial/links.html
There are also idea exchanges like yet2.com.
Jeff Veit
I don't know enough about C# to judge yet, but it's clear that you aren't taking a thinking-persons stance here.
.Net runtime engine. He has also said that the language will be submittes to ECMA, so you can reasonably expect runtimes to exist for other platforms.
Let's deal with your points 1 by 1.
1: It's been shown a few times that incremental languages are successful and revolutionary ones aren't. C++ was incremental on C. Eiffel was revolutionary. Which is in greater use. Leave the revolutionary stuff to experimental languages but be clear that ideas extracted from those languages and implemented in a incremental way are ideas that are successful.
2: Schizo Gerbil. Jeeze - get a grip. Does C++ keep all semantics the same as C? Nope. Does Java?
3. Non-open runtime. Really you don't know because the language is not ready for use yet. However Anders has said that the lnguage and all the other MS languages will compile down to run on top of the
4. No real standard. They have said they will submit to ECMA.
Get some balance dude.
You are facing a very similar dilemma to the one I face. I've come to the conclusion that for the stuff I am working on Open Source is a lovely idea, but impractical.
Firstly - the GPL is designed in such a way to guarantee that if you try to sell your software as a product, and are making good profit margins, that someone will undercut you, using your own work; it removes barriers to entry.
Secondly - there are very very very few OS companies whose primary product is a software package that are making money. If you know of one, tell me so that I can offer their software at a cheaper price than they do.
It seems that if you are a software developer hoping to make money by selling a product that you are dead in the water.
The standard suggestion is that you offer services rather than the software. For you that's an option, since you are selling into a 9's situation. For small or medium sized packages software designed for ease-of-use this does not seem to offer much hope.
(However I do think that packages with very small and larger scale user base can benefit by going OS. So Zope works because it has a large enough user base to generate service needs. Of course if there is a sinificant amount of code the demand for the original author increases.
There are a bunch of other models - I don't see many of them offering much hope...
Personalisation. Performance. Sponsorship. Last version is Open. Non-Open, with access to Source.
My advice - the Closed Source model has a history of making money, be cautious and stay with it unless there very very good financial reasons (not warm fuzziness) for going Open.
Jeff veit