actionscript-3 - botones - como se ocupa actionscript 3.0 en una animacion

Cómo explicar al cliente que no puedes darles algo de la fuente

Question

Tenemos una serie de componentes de AS / Flex que hemos desarrollado con el tiempo y mejorado. Han sido convertidos en componentes para que puedan ser reutilizados en diferentes proyectos y ahorrarnos tiempo. Entonces puede pensar en ellos como parte de un marco de trabajo interno.

Ahora nos estamos dando cuenta de que no tiene sentido lanzar el código fuente de estos componentes a los diversos clientes como parte del proyecto, porque técnicamente este código no es realmente propiedad de los clientes.

Entonces mi pregunta

• Cuando un cliente acude a usted, ¿cómo le explica que no puede darles el código fuente completo para esos componentes? El cliente no comprende la diferencia, solo espera que les proporcione todo el código del sitio que le pagó. Él no entiende que este código le ha tomado mucho más tiempo para escribir que lo que está pagando por su sitio. Pero como él no comprende, se desconectaría y pensaría que lo estás estafando o algo así.

• ¿Cómo manejas esta situación? ¿Qué le dices a los clientes por adelantado? ¿Lo anuncia en su sitio desde el principio? ¿Cómo manejan sus objeciones para que todavía lo contraten?

• Como una pregunta complementaria, ¿con qué frecuencia le das código fuente AS y Flex a tus clientes? En el caso en que el código no tenga componentes internos que reutilice en varios proyectos, y en el caso en que tenga componentes internos.

También me gustaría saber de personas que han trabajado en agencias creativas, ya que es muy probable que ya se hayan topado con ese tema.

Answer 1

Los temas de propiedad intelectual deben estar cubiertos por adelantado como parte del contrato. No soy abogado, pero la práctica común es especificar:

• Qué componentes son proporcionados por terceros y se refieren a sus términos de licencia
• Qué código se producirá como parte del contrato.
• Si licencia o vende varios derechos de propiedad intelectual.
• Términos de licencia.

Las leyes de propiedad intelectual son complejas y diversas, difieren de un país a otro. Dependiendo de dónde se encuentre y dónde esté su cliente, es posible que los términos de la licencia deban cambiar. Como ejemplo, la ingeniería inversa se ve de manera diferente en diferentes jurisdicciones.

Además de los componentes de terceros y los bits de software que no desea vender, ni otorgar una licencia exclusiva, probablemente desee exhibir y distribuir las obras como parte de su cartera de empresas. Esta última actividad también debería estar cubierta dentro del contrato.

Tener un contrato bien escrito preparado por adelantado evitará muchos malentendidos y negociaciones innecesarias. Probablemente necesites una sola plantilla que puedas usar para todos tus clientes. Entonces mi consejo es "hablar con un abogado" .

Answer 2

No soy una persona de negocios, pero generalmente estas cosas se especifican en el contrato. Si su contrato estipula que debe proporcionar al cliente el código fuente al final del proyecto, al menos deberá proporcionarles swcs de sus componentes para que puedan recompilar el código si es necesario. Si no desea compartir su código con el cliente, eso también es algo que deberá especificar de antemano.

Answer 3

Simplemente explique que no puede proporcionar la fuente de bibliotecas externas que utilizó en su proyecto para hacer que la oferta sea más barata para él. No esperaba la fuente de un proveedor de terceros que utilizó en su proyecto, solo trate de explicar que esta es la misma situación.

Answer 4

Su contrato debe dejar claro que los componentes desarrollados por usted tienen licencia para el cliente para ser utilizados como parte del proyecto y solo los proyectos que usted realizó para ellos. Por supuesto, tendrá que determinar el idioma exacto para usted y la situación, pero si utiliza estos componentes repetidamente en sus proyectos, realmente debería tener algún tipo de repetición para esta situación.

Answer 5

Le explicaría a mi cliente cómo funciona el mundo. Usaría ejemplos, analogías y metáforas.

Esto no es un problema de desarrollo de software, esto se aplica a todos los productos. Algunas cosas se venden como caja negra, y algunas se venden como cajas transparentes que contienen cajas negras en su interior.

Digamos que deseas comprar una casa. Usted paga al ingeniero y al arquitecto por su trabajo y obtiene los documentos que produce. Estos documentos contienen información que se basa en otros datos que usted no obtiene. Por ejemplo, el ingeniero puede usar enormes barras de acero en sus planes. Las especificaciones del ingeniero determinan las cualidades que debe tener cada barra de acero, pero no especifican cómo se crean las barras de acero. Comprar planes de casas no te compra los planes para crear los bloques de construcción de la casa. Con softwre es más o menos lo mismo: no se obtiene el código fuente para .NET Framework cuando se compra una aplicación .NET "con el código fuente incluido". Lo que obtienes es la documentación de .NET, que especifica cómo trabajar con el marco (y no especifica cómo el marco hace lo que hace).

La cantidad de ejemplos es interminable porque, como se dijo anteriormente, esta es la forma en que funciona el mundo.

Construya sus propias analogías para adaptarse a su escenario. Explique a su cliente dónde termina la infraestructura y comienza su solución propia.

quoo tiene razón sobre la necesidad de especificar esto en el contrato. El contrato es la columna vertebral legal del trato. Pero me gustaría enfatizar el hecho de que señalar el contrato debería ser un último recurso . Si le puede dar a su cliente una explicación razonable que le permita al cliente entender por qué las cosas son como son, no tendrá que cumplir con el contrato (que solo es como son las cosas, sin la motivación, la explicación, etc.) .