나는 당신이 체커의 교차점을 강타하기 위해 표준 수단을 사용할 수 있다는 것을 이해하며 유감스럽지 않습니다. 그리고 템플릿에 엄청난 작업이 투자된다면 어떻게 될까요? 아니, 준비됐어?
작업 지시서를 읽었습니까? 거기에는 마샤를 건너는 등의 넌센스 외에는 아무것도 없습니다. 제공하는 것이 유감스럽지 않은 방식으로 작성하십시오. 작동하는 경우에만 템플릿에서 불필요한 모든 것을 제거하고 중단하십시오. 빌드하지 마십시오. 그것에 대해 복잡한 것은 없습니다.
흥미로운 :
글쎄, 나는 "좋은" 소프트웨어 구현보다 더 많은 비용이 드는 "좋은" 아이디어를 Forex에서 보지 못했습니다.
나는 다음과 같이 질문에 대답할 것이다 - 소스 코드에는 고객이 자신이 저작권 보유자임을 주장할 수 있는 기회가 있습니다
글쎄, 그를 저작권 보유자하자. 그는 별로 좋지 않은 아이디어를 내놓았고 당신은 별로 좋은 소프트웨어를 작성하지 않았고 그것에 대한 좋은 돈도 받지 못했습니다. 모두가 행복해야 합니다. 일주일 안에 그러한 소프트웨어에 대해 기억조차 하지 못할 것입니다. 좋은 아이디어가 있지만 결코 작업 순서대로 실행되지는 않을 것입니다. 그러한 아이디어의 가치는 그것의 소프트웨어 구현과 비교할 수 없기 때문에 어떤 바보도 그것을 공개적으로 전시하지 않을 것이며 심지어 익숙하지 않은 프로그래머에게 개인적으로 그것을 보여줄 수도 없습니다. 좋은 아이디어를 생각한 사람은 언어를 마스터할 것입니다.
제 생각에는 또 다른 대안이 있습니다. 특정 중개자(저희의 경우 MQ)가 계약자와 고객 사이에 있는 반면, 계약자는 전체 자료 패키지 + 소스 코드를 중개자(누가 확인합니까? TOR 준수를 위해), 그 후 고객은 중개자로부터 작업 완료에 대해 통지를 받고 비용을 지불해야 합니다.
작업의 독점성과 초기 계약에 따라 지불 후 고객은 가장 오픈 소스 코드를 받거나 그냥 컴파일된 파일을 받습니다.
제 생각에는 또 다른 대안이 있습니다. 특정 중개자(우리의 경우 MQ)가 계약자와 고객 사이에 있는 반면 계약자는 전체 자료 패키지 + 소스 코드를 중개자(누가 확인하는지 확인합니다. TOR 준수를 위해), 그 후 고객은 중개자로부터 작업 완료에 대해 통지를 받고 비용을 지불해야 합니다.
pronych : 모두에게 해당되는 것은 아닙니다.)) 하지만, 물론 이것도 선택사항입니다... 저에게는 미리 만들어진 파일이 하나 있는 것이 더 편리합니다. 이것은 작업을 복잡하게 만듭니다('비용' 읽기). 그러나 대화는 그것에 대한 것조차 아닙니다. 그런 접근 방식은 아이디어를 분기하고 고객은 그런 점에서 더듬거리지 않습니다(또는 더듬거릴 수 있습니다! 다를 수 있음). 비록 그가 바보는 아니지만)) "소스 코드를 원합니다" 확인란이면 충분하다고 생각합니다. 계약 tz 전에 대부분의 문제를 해결할 것입니다. 이 질문이 명확하면 작업에 대해 더 논의할 수 있습니다. 풀은 자라지 않지만 완전히 다른 단계입니다.
1. 왜? 특정 모듈만 열려 있는 부분적으로 닫힌 템플릿의 관점에서 볼 때 실행 가능한 아이디어입니다.
동시에 비용과 시간 면에서 이 접근 방식이 훨씬 저렴할 것이라고 확신합니다.
2. 아마도 확인란이 필요할 것입니다. 제 생각에는 소스 코드뿐만 아니라 고객에 대한 모든 권리의 이전에 관한 것이어야 합니다. 수행자의 행동을 원하고 제한함).
그렇지 않으면 누가 공연자가 자신의 작업 결과를 제3자(예: STORE를 통해)에 판매하는 것을 방해하는지 말해주십시오.
누가 고객이 같은 일을 하지 못하도록 막겠습니까? 그러나 여러 고객이 하나의 작업에 참여하고 비용을 지불하는 경우에도 이러한 옵션이 가능합니다. 그러면 어떻게 될까요?
글쎄, 그를 저작권 보유자하자. 그는 별로 좋지 않은 아이디어를 내놓았고 당신은 별로 좋은 소프트웨어를 작성하지 않았고 그것에 대한 좋은 돈도 받지 못했습니다. 모두가 행복해야 합니다. 일주일 안에 그러한 소프트웨어에 대해 기억조차 하지 못할 것입니다. 좋은 아이디어가 있지만 결코 작업 순서대로 실행되지는 않을 것입니다. 그러한 아이디어의 가치는 그것의 소프트웨어 구현과 비교할 수 없기 때문에 어떤 바보도 그것을 공개적으로 전시하지 않을 것이며 심지어 익숙하지 않은 프로그래머에게 개인적으로 그것을 보여줄 수도 없습니다. 좋은 아이디어를 생각한 사람은 언어를 마스터할 것입니다.
1. (내 생각으로는) 그다지 좋은 생각은 아닙니다. 개인적으로 자동화할 뿐만 아니라 논의하기에는 너무 게을러질 것입니다. 글쎄, 나는 2 MASHKH에 Expert Advisors를 복제하고 $10에 팔고 싶지 않습니다.
아이디어가 가치가 있다면 두 번째 MASHKI는 모든 차량의 기초가 될 수 있습니다.
2. 최종 권리를 누가 소유하느냐가 가장 중요하다고 생각합니다. 내가 개인적으로 이 질문을 이해하는 한, 고객이 저작권 소유자인 경우 적절한 조치를 취할 수 있습니다(독립적으로 또는 제3자의 도움을 받아 작업 결과를 판매하고 코드를 변경하고 그의 발전 등), 예술가에 대한 언급은 제거될 수 있습니다.
코드에 대한 권리가 실연자에게 완전히 또는 부분적으로 남아 있는 경우, 그는 고객에게 재정적 권리와 저작권 모두를 존중하도록 요구할 권리가 있습니다. 또한 동시에 수행자는 자신의 이익을 위해 알고리즘과 코드를 사용할 권리를 보유합니다.
3. 정상적인 주문과 정상적인 작업이 반드시 나타납니다(단말기가 실제 계정 에 사용되고 진지한 거래자가 관심을 가진 후). 이것만으로도 TK는 완전히 달라지고 작업 비용은 더 이상 $ 10-15가 아닙니다.
추신
개인적으로 제 생각에 일반 TK의 비용은 주문 총액의 최대 50%, 평균 약 10%가 될 수 있습니다(물론 TK 자체의 비용은 동일한 10%보다 훨씬 낮을 수 있습니다. , 그러나 동시에 고객과 계약자는 수행된 작업의 본질을 명확하게 이해해야 합니다).
물론 일반적으로 공식화 된 TOR의 비용이 작업 자체보다 비용이 많이 드는 독특한 경우도 있지만 이것은 대부분의 경우 고객 자신이 원하는 것이 무엇인지 알지 못하는 별도의 이야기입니다.
1. 왜? 특정 모듈만 열려 있는 부분적으로 닫힌 템플릿의 관점에서 볼 때 실행 가능한 아이디어입니다.
동시에 비용과 시간 면에서 이 접근 방식이 훨씬 저렴할 것이라고 확신합니다.
2. 아마도 확인란이 필요할 것입니다. 제 생각에는 소스 코드뿐만 아니라 고객에 대한 모든 권리의 이전에 관한 것이어야 합니다. (고객이 무엇이든 할 수 있도록 허용하는 독점적 권리 수행자의 행동을 원하고 제한함).
그렇지 않으면 누가 공연자가 자신의 작업 결과를 제3자(예: STORE를 통해)에 판매하는 것을 방해하는지 말해주십시오.
누가 고객이 같은 일을 하지 못하도록 막겠습니까? 그러나 여러 고객이 하나의 작업에 참여하고 비용을 지불하는 경우에도 이러한 옵션이 가능합니다. 그러면 어떻게 될까요?
1. 동의합니다. 그러나 결론은 이 경우 고객에게 어떤 종류의 결과(이 경우 파일)를 받기를 원하는지 명확하게 표시해야 한다는 것입니다. 확인란이 있거나 확인란이 없는 경우 "전체 소스", "일부 소스", "컴파일됨"과 같은 옵션이 있습니다. 이것은 프로세스를 복잡하게 만들고 적용 단계에서 의미가 없습니다. 나중에 모든 것을 논의할 수 있습니다. 고객이 "출처" 확인란을 선택했다면 논의하는 것이 합리적이고 그렇지 않은 경우 어떤 질문을 하고 계속 진행하십시오! )) 이 상황에서 소스 코드에 대한 질문은 섬세할 뿐만 아니라 매우 미끄럽습니다. 규정에서 그런 부분을 발견하지 못해서 나도 놀랐다.
2. 이것은 또한 심각한 질문입니다. 생각해야 합니다. 수행자에게 의무가 있을 뿐만 아니라 고객도 신청 단계에서 보다 완전한 정보를 표시해야 합니다. 애플리케이션을 더욱 확장하는 것이 합리적일 수 있습니다. 몇 가지 아이디어를 입력합니다. 예를 들어 컴파일된 제품도 보호하는 것입니다. 개인적으로 나는 항상 계정을 확인하여 내 개발 (MT4)을 보호했습니다. 글쎄, 그것은 나에 관한 것이 아니라 ...
1. (내 생각으로는) 그다지 좋은 생각은 아닙니다. 개인적으로 자동화할 뿐만 아니라 논의하기에는 너무 게을러질 것입니다. 글쎄, 나는 2 MASHKH에 Expert Advisors를 복제하고 $10에 팔고 싶지 않습니다.
아이디어가 가치가 있다면 두 번째 MASHKI는 모든 차량의 기초가 될 수 있습니다.
2. 최종 권리를 누가 소유하느냐가 가장 중요하다고 생각합니다. 내가 개인적으로 이 질문을 이해하는 한, 고객이 저작권 소유자인 경우 적절한 조치를 취할 수 있습니다(독립적으로 또는 제3자의 도움을 받아 작업 결과를 판매하고 코드를 변경하고 그의 발전 등), 예술가에 대한 언급은 제거될 수 있습니다.
코드에 대한 권리가 실연자에게 완전히 또는 부분적으로 남아 있는 경우, 그는 고객에게 재정적 권리와 저작권 모두를 존중하도록 요구할 권리가 있습니다. 또한 동시에 수행자는 자신의 이익을 위해 알고리즘과 코드를 사용할 권리를 보유합니다.
3. 정상적인 주문과 정상적인 작업이 반드시 나타납니다(단말기가 실제 계정 에 사용되고 진지한 거래자가 관심을 가진 후). 이것만으로도 TK는 완전히 달라지고 작업 비용은 더 이상 $ 10-15가 아닙니다.
추신
개인적으로 제 생각에 일반 TK의 비용은 주문 총액의 최대 50%, 평균 약 10%가 될 수 있습니다(물론 TK 자체의 비용은 동일한 10%보다 훨씬 낮을 수 있습니다. , 그러나 동시에 고객과 계약자는 수행된 작업의 본질을 명확하게 이해해야 합니다).
물론 일반적으로 공식화 된 TOR의 비용이 작업 자체보다 비용이 많이 드는 독특한 경우도 있지만 이것은 대부분의 경우 고객 자신이 원하는 것이 무엇인지 알지 못하는 별도의 이야기입니다.
그게 다야! 추가할 내용도 없습니다. 이 게시물을 전적으로 지지합니다. 이제 장난이 옵니다. 아직 앞서
1. STORE의 주요 아이디어는 프로그래머가 소프트웨어 솔루션(전문가/스크립트/지표 또는 라이브러리)을 생성하고 이를 제공하지 않고 여러 "고객"(또는 오히려 구매자라고 부름)에게 판매할 기회가 있다는 것입니다. 저작권 소유자의 코드 및 권리.
동시에 MQ는 서비스의 주최자로서 판매자와 구매자 사이의 중개자 역할을 하여 쌍방을 일정한 방식으로 보호합니다. 따라서 개발자는 판매되는 상품의 불법 복제로부터 프로그래머의 권리를 보호하고 구매자는 상품이 설명과 일치하고 "돈 가치가" 있는지 확인해야 합니다.
2. 내 아이디어는 상점의 아이디어와 막연하지만 약간의 예약이 있습니다. 즉, 고객이 원하는 경우 권리와 소스 코드를 구매할 수 있습니다. 또한 SHOP은 내가 이해하는 한 일부 품목/솔루션을 판매할 수 없습니다. 예를 들어, TK를 직접 "판매"할 수 있는 기회가 없으며("작업" 서비스에 이러한 기회가 있음) 자체 DLL 및 유사한 것과 관련된 모든 솔루션이 상점에서 작동하지 않습니다.
추신
일반 소프트웨어 솔루션의 관점에서 제 생각에는 두 가지 방법이 있습니다(STORE와 WORK의 주요 차이점).
1. 프로그래머는 "좋은" 소프트웨어 솔루션을 만들어 많은 구매자에게 합리적인 가격으로 판매할 수 있는 능력이 있습니다. 고객은 다른 구매자 중에서 특정 소프트웨어 제품을 저렴한 가격으로 구매할 수 있는 기회가 있습니다(단, 독점권은 아님).
2. 계약에 따라 양 당사자가 수락할 수 있는 금액에 대해 고객은 맞춤형 소프트웨어 제품을 주문할 수 있습니다. 동시에 그는 출연자의 작업 결과에 대한 독점적 권리를 얻을 수 있습니다.
소스 코드는 많은 추가 기능, 클래스 등이 포함된 잘 설계된 템플릿이 될 수 있습니다.
나는 당신이 체커의 교차점을 강타하기 위해 표준 수단을 사용할 수 있다는 것을 이해하며 유감스럽지 않습니다. 그리고 템플릿에 엄청난 작업이 투자된다면 어떻게 될까요? 아니, 준비됐어?
작업 지시서를 읽었습니까? 거기에는 마샤를 건너는 등의 넌센스 외에는 아무것도 없습니다. 제공하는 것이 유감스럽지 않은 방식으로 작성하십시오. 작동하는 경우에만 템플릿에서 불필요한 모든 것을 제거하고 중단하십시오. 빌드하지 마십시오. 그것에 대해 복잡한 것은 없습니다.
글쎄, 나는 "좋은" 소프트웨어 구현보다 더 많은 비용이 드는 "좋은" 아이디어를 Forex에서 보지 못했습니다.
나는 다음과 같이 질문에 대답할 것이다 - 소스 코드에는 고객이 자신이 저작권 보유자임을 주장할 수 있는 기회가 있습니다
글쎄, 그를 저작권 보유자하자. 그는 별로 좋지 않은 아이디어를 내놓았고 당신은 별로 좋은 소프트웨어를 작성하지 않았고 그것에 대한 좋은 돈도 받지 못했습니다. 모두가 행복해야 합니다. 일주일 안에 그러한 소프트웨어에 대해 기억조차 하지 못할 것입니다. 좋은 아이디어가 있지만 결코 작업 순서대로 실행되지는 않을 것입니다. 그러한 아이디어의 가치는 그것의 소프트웨어 구현과 비교할 수 없기 때문에 어떤 바보도 그것을 공개적으로 전시하지 않을 것이며 심지어 익숙하지 않은 프로그래머에게 개인적으로 그것을 보여줄 수도 없습니다. 좋은 아이디어를 생각한 사람은 언어를 마스터할 것입니다.
권리
그런 다음 서비스 데스크에 편지를 쓰 십시오. 아이디어 자체가 적합한 경우(필요한 경우 문구 수정 가능).
그럼 바로 (조용히, 개발자들이 잠든 사이에) 생각해보자)), '작업' 섹션에서 어떤 추가 사항을 요청하고 싶나요?
제 생각에는 또 다른 대안이 있습니다. 특정 중개자(저희의 경우 MQ)가 계약자와 고객 사이에 있는 반면, 계약자는 전체 자료 패키지 + 소스 코드를 중개자(누가 확인합니까? TOR 준수를 위해), 그 후 고객은 중개자로부터 작업 완료에 대해 통지를 받고 비용을 지불해야 합니다.
작업의 독점성과 초기 계약에 따라 지불 후 고객은 가장 오픈 소스 코드를 받거나 그냥 컴파일된 파일을 받습니다.
동시에, 당신이 이해하는 바와 같이, 중개자는 일정한 보수를 받습니다.
추신
MQ는 별로 내 취향은 아닌 것 같지만...
제 생각에는 또 다른 대안이 있습니다. 특정 중개자(우리의 경우 MQ)가 계약자와 고객 사이에 있는 반면 계약자는 전체 자료 패키지 + 소스 코드를 중개자(누가 확인하는지 확인합니다. TOR 준수를 위해), 그 후 고객은 중개자로부터 작업 완료에 대해 통지를 받고 비용을 지불해야 합니다.
모두에게 해당되는 것은 아닙니다.)) 하지만, 물론 이것도 선택사항입니다... 저에게는 미리 만들어진 파일이 하나 있는 것이 더 편리합니다. 이것은 작업을 복잡하게 만듭니다('비용' 읽기). 그러나 대화는 그것에 대한 것조차 아닙니다. 그런 접근 방식은 아이디어를 분기하고 고객은 그런 점에서 더듬거리지 않습니다(또는 더듬거릴 수 있습니다! 다를 수 있음). 비록 그가 바보는 아니지만)) "소스 코드를 원합니다" 확인란이면 충분하다고 생각합니다. 계약 tz 전에 대부분의 문제를 해결할 것입니다. 이 질문이 명확하면 작업에 대해 더 논의할 수 있습니다. 풀은 자라지 않지만 완전히 다른 단계입니다.
1. 왜? 특정 모듈만 열려 있는 부분적으로 닫힌 템플릿의 관점에서 볼 때 실행 가능한 아이디어입니다.
동시에 비용과 시간 면에서 이 접근 방식이 훨씬 저렴할 것이라고 확신합니다.
2. 아마도 확인란이 필요할 것입니다. 제 생각에는 소스 코드뿐만 아니라 고객에 대한 모든 권리의 이전에 관한 것이어야 합니다. 수행자의 행동을 원하고 제한함).
그렇지 않으면 누가 공연자가 자신의 작업 결과를 제3자(예: STORE를 통해)에 판매하는 것을 방해하는지 말해주십시오.
누가 고객이 같은 일을 하지 못하도록 막겠습니까? 그러나 여러 고객이 하나의 작업에 참여하고 비용을 지불하는 경우에도 이러한 옵션이 가능합니다. 그러면 어떻게 될까요?
글쎄, 그를 저작권 보유자하자. 그는 별로 좋지 않은 아이디어를 내놓았고 당신은 별로 좋은 소프트웨어를 작성하지 않았고 그것에 대한 좋은 돈도 받지 못했습니다. 모두가 행복해야 합니다. 일주일 안에 그러한 소프트웨어에 대해 기억조차 하지 못할 것입니다. 좋은 아이디어가 있지만 결코 작업 순서대로 실행되지는 않을 것입니다. 그러한 아이디어의 가치는 그것의 소프트웨어 구현과 비교할 수 없기 때문에 어떤 바보도 그것을 공개적으로 전시하지 않을 것이며 심지어 익숙하지 않은 프로그래머에게 개인적으로 그것을 보여줄 수도 없습니다. 좋은 아이디어를 생각한 사람은 언어를 마스터할 것입니다.
1. (내 생각으로는) 그다지 좋은 생각은 아닙니다. 개인적으로 자동화할 뿐만 아니라 논의하기에는 너무 게을러질 것입니다. 글쎄, 나는 2 MASHKH에 Expert Advisors를 복제하고 $10에 팔고 싶지 않습니다.
아이디어가 가치가 있다면 두 번째 MASHKI는 모든 차량의 기초가 될 수 있습니다.
2. 최종 권리를 누가 소유하느냐가 가장 중요하다고 생각합니다. 내가 개인적으로 이 질문을 이해하는 한, 고객이 저작권 소유자인 경우 적절한 조치를 취할 수 있습니다(독립적으로 또는 제3자의 도움을 받아 작업 결과를 판매하고 코드를 변경하고 그의 발전 등), 예술가에 대한 언급은 제거될 수 있습니다.
코드에 대한 권리가 실연자에게 완전히 또는 부분적으로 남아 있는 경우, 그는 고객에게 재정적 권리와 저작권 모두를 존중하도록 요구할 권리가 있습니다. 또한 동시에 수행자는 자신의 이익을 위해 알고리즘과 코드를 사용할 권리를 보유합니다.
3. 정상적인 주문과 정상적인 작업이 반드시 나타납니다(단말기가 실제 계정 에 사용되고 진지한 거래자가 관심을 가진 후). 이것만으로도 TK는 완전히 달라지고 작업 비용은 더 이상 $ 10-15가 아닙니다.
추신
개인적으로 제 생각에 일반 TK의 비용은 주문 총액의 최대 50%, 평균 약 10%가 될 수 있습니다(물론 TK 자체의 비용은 동일한 10%보다 훨씬 낮을 수 있습니다. , 그러나 동시에 고객과 계약자는 수행된 작업의 본질을 명확하게 이해해야 합니다).
물론 일반적으로 공식화 된 TOR의 비용이 작업 자체보다 비용이 많이 드는 독특한 경우도 있지만 이것은 대부분의 경우 고객 자신이 원하는 것이 무엇인지 알지 못하는 별도의 이야기입니다.
1. 왜? 특정 모듈만 열려 있는 부분적으로 닫힌 템플릿의 관점에서 볼 때 실행 가능한 아이디어입니다.
동시에 비용과 시간 면에서 이 접근 방식이 훨씬 저렴할 것이라고 확신합니다.
2. 아마도 확인란이 필요할 것입니다. 제 생각에는 소스 코드뿐만 아니라 고객에 대한 모든 권리의 이전에 관한 것이어야 합니다. (고객이 무엇이든 할 수 있도록 허용하는 독점적 권리 수행자의 행동을 원하고 제한함).
그렇지 않으면 누가 공연자가 자신의 작업 결과를 제3자(예: STORE를 통해)에 판매하는 것을 방해하는지 말해주십시오.
누가 고객이 같은 일을 하지 못하도록 막겠습니까? 그러나 여러 고객이 하나의 작업에 참여하고 비용을 지불하는 경우에도 이러한 옵션이 가능합니다. 그러면 어떻게 될까요?
1. 동의합니다. 그러나 결론은 이 경우 고객에게 어떤 종류의 결과(이 경우 파일)를 받기를 원하는지 명확하게 표시해야 한다는 것입니다. 확인란이 있거나 확인란이 없는 경우 "전체 소스", "일부 소스", "컴파일됨"과 같은 옵션이 있습니다. 이것은 프로세스를 복잡하게 만들고 적용 단계에서 의미가 없습니다. 나중에 모든 것을 논의할 수 있습니다. 고객이 "출처" 확인란을 선택했다면 논의하는 것이 합리적이고 그렇지 않은 경우 어떤 질문을 하고 계속 진행하십시오! )) 이 상황에서 소스 코드에 대한 질문은 섬세할 뿐만 아니라 매우 미끄럽습니다. 규정에서 그런 부분을 발견하지 못해서 나도 놀랐다.
2. 이것은 또한 심각한 질문입니다. 생각해야 합니다. 수행자에게 의무가 있을 뿐만 아니라 고객도 신청 단계에서 보다 완전한 정보를 표시해야 합니다. 애플리케이션을 더욱 확장하는 것이 합리적일 수 있습니다. 몇 가지 아이디어를 입력합니다. 예를 들어 컴파일된 제품도 보호하는 것입니다. 개인적으로 나는 항상 계정을 확인하여 내 개발 (MT4)을 보호했습니다. 글쎄, 그것은 나에 관한 것이 아니라 ...
1. (내 생각으로는) 그다지 좋은 생각은 아닙니다. 개인적으로 자동화할 뿐만 아니라 논의하기에는 너무 게을러질 것입니다. 글쎄, 나는 2 MASHKH에 Expert Advisors를 복제하고 $10에 팔고 싶지 않습니다.
아이디어가 가치가 있다면 두 번째 MASHKI는 모든 차량의 기초가 될 수 있습니다.
2. 최종 권리를 누가 소유하느냐가 가장 중요하다고 생각합니다. 내가 개인적으로 이 질문을 이해하는 한, 고객이 저작권 소유자인 경우 적절한 조치를 취할 수 있습니다(독립적으로 또는 제3자의 도움을 받아 작업 결과를 판매하고 코드를 변경하고 그의 발전 등), 예술가에 대한 언급은 제거될 수 있습니다.
코드에 대한 권리가 실연자에게 완전히 또는 부분적으로 남아 있는 경우, 그는 고객에게 재정적 권리와 저작권 모두를 존중하도록 요구할 권리가 있습니다. 또한 동시에 수행자는 자신의 이익을 위해 알고리즘과 코드를 사용할 권리를 보유합니다.
3. 정상적인 주문과 정상적인 작업이 반드시 나타납니다(단말기가 실제 계정 에 사용되고 진지한 거래자가 관심을 가진 후). 이것만으로도 TK는 완전히 달라지고 작업 비용은 더 이상 $ 10-15가 아닙니다.
추신
개인적으로 제 생각에 일반 TK의 비용은 주문 총액의 최대 50%, 평균 약 10%가 될 수 있습니다(물론 TK 자체의 비용은 동일한 10%보다 훨씬 낮을 수 있습니다. , 그러나 동시에 고객과 계약자는 수행된 작업의 본질을 명확하게 이해해야 합니다).
물론 일반적으로 공식화 된 TOR의 비용이 작업 자체보다 비용이 많이 드는 독특한 경우도 있지만 이것은 대부분의 경우 고객 자신이 원하는 것이 무엇인지 알지 못하는 별도의 이야기입니다.
MQ의 상점 아이디어에 익숙하지 않습니다. 당신의 아이디어가 매장의 아이디어와 다른가요?
1. STORE의 주요 아이디어는 프로그래머가 소프트웨어 솔루션(전문가/스크립트/지표 또는 라이브러리)을 생성하고 이를 제공하지 않고 여러 "고객"(또는 오히려 구매자라고 부름)에게 판매할 기회가 있다는 것입니다. 저작권 소유자의 코드 및 권리.
동시에 MQ는 서비스의 주최자로서 판매자와 구매자 사이의 중개자 역할을 하여 쌍방을 일정한 방식으로 보호합니다. 따라서 개발자는 판매되는 상품의 불법 복제로부터 프로그래머의 권리를 보호하고 구매자는 상품이 설명과 일치하고 "돈 가치가" 있는지 확인해야 합니다.
2. 내 아이디어는 상점의 아이디어와 막연하지만 약간의 예약이 있습니다. 즉, 고객이 원하는 경우 권리와 소스 코드를 구매할 수 있습니다. 또한 SHOP은 내가 이해하는 한 일부 품목/솔루션을 판매할 수 없습니다. 예를 들어, TK를 직접 "판매"할 수 있는 기회가 없으며("작업" 서비스에 이러한 기회가 있음) 자체 DLL 및 유사한 것과 관련된 모든 솔루션이 상점에서 작동하지 않습니다.
추신
일반 소프트웨어 솔루션의 관점에서 제 생각에는 두 가지 방법이 있습니다(STORE와 WORK의 주요 차이점).
1. 프로그래머는 "좋은" 소프트웨어 솔루션을 만들어 많은 구매자에게 합리적인 가격으로 판매할 수 있는 능력이 있습니다. 고객은 다른 구매자 중에서 특정 소프트웨어 제품을 저렴한 가격으로 구매할 수 있는 기회가 있습니다(단, 독점권은 아님).
2. 계약에 따라 양 당사자가 수락할 수 있는 금액에 대해 고객은 맞춤형 소프트웨어 제품을 주문할 수 있습니다. 동시에 그는 출연자의 작업 결과에 대한 독점적 권리를 얻을 수 있습니다.