I think you're reading too much into this...IBMs creation of SWT was a welcome response to sun's lethargy in creating a viable Desktop GUI toolkit. Swing drives me nuts...it's layered on top of awt, one if the worst(the worst if you measure it by quality + importance) apis among the java libraries. It in itself is nothing to behold either. It has a terrible memory and processing profile. And I haven't looked at IntelliJ(though I will since you have mentioned it), but the only Swing application I've ever been able to stomach is JEdit, and I kicked that to the curb like an old hooker when Eclipse came out. SWT _is_ what Swing should be and the fact that the Eclipse developers finally got fed up with waiting around for someone to make Swing _work_ and built their own is something I applaud wholeheartedly.
I do second the comment above about fragmentation, but really, there are so few Java gui apps out there(and among the ones that are, 90% are ides, probably just because if you build your ide in a language other than one it's intended for you will lose credibility), there's really not a market to fragment. My hope is that with SWT, we will start to see some real java desktop gui apps emerge.
I appreciate you taking the time to make a thoughtful response.
I have though in fact done a significant amount of contract work. Every project I have ever worked on, save one, the source code and the IP was owned by the client. In every case, I was doing this contracting work as part of a small-to-medium size team for medium-to-large corporations. These were not companies that were involved in software development as their primary vocation, but rather were using it to enhance their own in-house productivity.
The one instance that I worked on a project where the code/IP was owned by the developer and not the client was essentially a proprietary software system for which we were hired, as part of the company the originally developed the product, to make modifications to it. I feel this is really more an example of software vendor than contractor/consultant, but the lines blurs, and I was at times doing one-off smaller programs that were nonetheless utterly owned the development firm that I worked for. This was the first job I had out of school, so I can't tell you much about the nature of the negotiations, but my presumption was always that we were able to establish the contracts in this manner because we had the dominant product in the market, and could leverage this dominance.
So that is my experience. Other anecdotal experience of how companies structure their contracts on projects that my peers have worked on also backs up my views. Is is impossible/unthinkable for a company to release the control of the source code to the developers? No, it's not. I suppose there are reasons a company might do this, but to hone in on a specific point that you make:
They might, at a stretch, want to keep the code, not for reselling, but for further customization, but if they aren't a software company, in other words, if software isn't their core business and they don't have in-houes programmers (presumably the case since they hired a contracter) they would need to hire a contracter to make any further changes anyway.
This represents for me the fundamental reason why a company not run by someone very naive about software would never give the ownership of software developed by a third-party back to that third-party: 1) They will want to make customizations. Is there ever a program/pieceo of softare of more than trivial complexity and usefulness that is not modified(heavily) after its introduction? 2) They may want to do these customizations themselves or hire someone else to do them other than yourself. At the very least, even if they plan on hiring you, they are at a significantly weaker position in any negotiation if you are the one who owns the source code.
So, I will admit that it is silly for me to say this never happens or even shouldn't happen. There are all sorts of tradeoffs that go into negotiations. However, I would stand by the point that any company that pays someone to write code for them and then gives the ownership of that code back to the author they paid to do it(and not even as open-source mind you, but as that developers proprietary work) without some very strong compensating benefits should have its head examined. Perhaps it's a nice thing to do, but I can see no compelling business reason to do so, and a host of very significant drawbacks.
Umm, no. Crowheads point stands. Any company that hires someone to write software for them, and then gives away the ip/code to the developer is being run by idiots. There is no reason to allow this, especially the market being what it is nowadays. I would imagine it would be easier to convince them to open-source it than to allow oneself to own the ip, since if it's open-source at least they are assured of indefinite free access to it(along with everyone else too, surely, but at least they won't be at your mercy when they wan't to make modifications)
The only catch to this is if the developer has some remarkable leverage in negotiating that would persuade the client to give them the IP. I have seen this happen, but it is not the norm, and especially not for a small one-off application such as what I imagine the individual who is posing the original question is talking about.
As for a company just giving it away to the developer with no compelling reason or significant balancing contribution by the developer, I would say you are talking about a very naive/incompetent business.
Glad to hear so many had installations that went flawlessly. I can't say that was the case for me. I had a couple minor issues and one major one. The minor ones just had to do with the rendering of fonts by KDE/X. No big deal there, but if I was evaluating it from an ignorant user's perspective, I would say completely ugly fonts that the system produced on first boot are totally unacceptable and would have them runnning screaming to their windows installation disk.
Other problem was a bigger one. The installer,YaST2 or whatever they call it, did not correctly recognize my keyboard. I am not sure how they compile support for usb input devices in the kernel, but about midway through the installation process, my keyboard ceased to function. This was very problematic. When I rebooted the machine the keyboard started working fine again, but the mappings for non-standard keys were not functioning correctly. I changed the keyboard setting to 104-key standard and it began recognizing my keys for a short time before again losing track of the keyboard and forcing me to reboot again.
On the whole not a great experience...I assumed the keyboard problem could have been overcome by recompiling the kernel with the correct usb settings(or at least the ones that have always worked for me) and perhaps screwing around with my X86Config file if things were still not working correctly. Were I evaluating this system from the perspective of a not particularly tech-savvy or curious windows user I would say these problems are wholly unacceptable.
I found this article not insightful at all...just a couple of obvious points everyone has heard before.
I'm not sure why this was linked to, but I personally feel like it was a waste of my time to read it. Only note this because I would say that this is not typical of most of the links on this site.
The two most attractive things about it in my mind are:
1) The ability to compile the code to native binary. I don't know why Sun resists making this available for Java. I am not sure what problems you allude to with Swing, but I personally have found it very nice to work with. What kills me about it is it's slowness and resource consumption.
2) The focus on adding new languages. There are other languages available for Java, but not many, and it doesn't seem to be something that Sun is focused on at all. I think this would be a great thing for Java developers.
As for problems with portability with Java, I am among those who believe that it goes a long way towards achieving the WO/RA dream. There are times when I have been kicked in the butt by it(such as moving from WebLogic to Bluestone), but I have found other transitions very easy(I have moved apps between Orion, WebLogic, and Tomcat in just about every permutation without much problem).
I think this could happen with Java, but probably not
in the near future as Sun needs the goodwill of the developer community for their battle with msoft. If Sun had the same market share as Microsoft I haven't seen anything to believe they would behave any better than Redmond does....
I haven't heard anything from Miguel addressing this subject, but I am sure he must be aware of this.
There is no one out there(at least on this site) that does not seriously believe that Microsoft will try to embrace and extend projects such as Mono out of existence if they start to challenge their hegemony in this domain. Does this necessarily mean they will be successful? They have submitted it to the ECMA after all, and if they are holding bits back, well,then that's going to be a problem for both Mono and.NET.
I imagine what Miguel is thinking is that here is an opportunity to give to the open source community a cross-platform, cross-language tool. Obviously, this is a pretty bold goal, and it may not succeed. But in my mind it is a fantastic one, and I applaud him for striving for it. Is it the best way to go about? Would they be better off getting on the Java bandwagon(which has it's own licensing problems) or Perl(which has questionable momentum) or something else alltogether? I don't know the answer to this for certain, but from where I am sitting he hasn't made a bad one because:
1) Most of the hard design and specification work has already been done for him by Microsoft(and don't think Microsoft is thrilled about this...I'm sure it pisses the hell out of them but at the same time they saw it as necessary to compete with Java).
2) You know a lot of people are going to get behind.NET, if only because it is from Microsoft. Some would use it even if it was just a warm pile of doo-doo....
3)....which it is not, as C# was designed by Anders Hejlsberg, one of the better minds of current software development, as well as I'm sure of a bevy of other not-exactly-morons at microsoft. Sure there copying Java, but from what I've read, they've made up some of the annoying things about it already(such as being able to transparently access primitives and their object wrappers).
All good mitigating factors in my mind. Still, it's far from a sure thing. But neither are most really cool innovative things...
1) I thought Miguel's arguments for why he's getting behind the.NET Framework(the CLI and CLR to be specific) were excellent. I have read much about the Mono project since the announcement of its inception, but this is by far the best explication I have seen. If he hasn't made me a believer, he has at least made me very curious.
2) As an active Java developer, I think that this may very well be the BEST thing someone could do to help Java. The directions Microsoft are going in with.NET to me seem like the obvious directions(licensing as a standard to ECMA, support for multiple languages, etc.) that Java should be going towards, but, for whatever reason, is not. I think.NET(and Mono) if they pick up steam will give sun the kick in the ass they need to get moving on some of this stuff that they are not.
I personally think the main reason Sun has not further opened Java up is because they have not perceived the need to. They are doing some calculus in their head to make it as open as they need to gain developers from Redmond, but still try to hold onto as much as possible of it for themselves.
3) My largest concern with this, and I didn't notice Miguel addressing it there or in the followups, is the patent issue. My worst fear is everything would go incredibly well with mono: diverse compilers, robust libraries, etc. and we would all start to build code around it, and then about 5 years down the line Microsoft whips out a patent and demands royalties for all the labor that we have done under the illusion that it would be free.
I would love to see Miguel address this concern. I cannot speak for others, but I would be a long way to considering getting involved with Mono(whether it mean using their tools to develop, or even contributing to the developmen of libraries, languages, etc.) if I felt better about these things.
I think that there are some good points made here, but I feel that a interesting aspect of this situation is being ignored. We seem to be focused largely on the legal aspects of the situation and what exactly constitutes IP. These are important considerations, but another aspect (or at least the one I am more accustomed to dealing with) is how IP contributions are a part of the negotiated price that a product is sold for.
For example, we developed a product for a customer during which they made significant contributions to the feature set that was included in the product. There were of course differences as to what the degree of their contributions were(they of course felt it was larger than we did, and vice versa), but there was certainly no attempt to deny on our part that their contribution had been significant. Of course, we argue this to them as an advantage of what we did: you get a product that is customized to your needs, so why should you pay any less for it, etc. Their retort is that they made it a better product not just for themselves, but for our other customers as well.
I believe this was a valid point on their part, and their desire to realize something for this contribution seemed fair to me. What it ended up being was essentially a discount off of what the cost of the product was. The particulars of what the exact discount was, were, of course, contested, but everyone agreed on the principle behind it.
So, I don't know about the legal particulars of any of this(except of course for the contractual ones that were negotiated), but it seems to me that whatever the law says, if the customer has made your product a better one, then it is not unreasonable on their part to demand something in return. At the same time, this is just one small piece in the negotiations puzzle. We for example were more willing to recognize their contributions since being a small company with few customers, they had a greater degree of leverage over us than say if they were dealing with Oracle. In that situation, the most you might ask for is that they implement your suggestion and don't raise your prices.
A few thoughts on VCs, Engineers, and Managements:
1) VCs, in general, are not very trustworthy. They are in business, they are looking to make money, and they are not afraid to step on some toes to get it. I don't think there is anything particularly shocking about this, but it is something to keep in mind when dealing with them.
2) "Your ideas, Your work, Their company" - let's not forget their money. As the author of this article himself points out, it is very difficult to raise money. The fact that VCs give people astronomical amounts of money and ask for something in return (i.e. a share of the company and a voice in how it is run to protect their investment) is not unreasonable.
3) VCs, like most people, and especially those controlling large amounts of money, tend to have a herd mentality. Do they take more risk than the average investor? Absolutely. Looking at the number of ideas that have been funded in the last few years and then turning and blaming vcs for not funding "enough" risky ideas to me seems pretty silly.
4) Good management is critical to the success of a company. This may be anathema to many of the people who frequent this site(or at least this topic), but one of the mantra's of VCs is "management, management, management." Now, I am an engineer, I started a company, but I am more than willing to admit that:
A) I am not well suited to managing it
B) If I don't find someone who is, the company will have real difficulty succeeding.
Now, obviously there are many examples of companies that have been run into the ground by bad management. Does this mean that management is evil or (perhaps even more absurd) unnecessary? No. Good management is critical to a company's success, just as bad management is critical to its failure. This may not be pleasing to our egos as engineers, and there may be exceptions to this, but having worked with some good managers and some bad ones, it seems to me to be generally true.
5) Engineers are often not good managers. Let's be honest here. Sometimes the guy from Wharton is a really lousy manager. But just as often (I would argure more often) the brilliant programmer is also a really lousy manager. Being a good manager is an hard-to-acquire skill, in some ways as nuanced and difficult to achieve as technical proficiency. Just as a cs degree does not assure programming competence, neither does an MBA assure management competence.
6) In general, I found this article to be whiny and annoying. Yes, I don't like VCs either. Many of them are "sharks"(as I was told before I got involved with them, and have generally found to be true). They are not necessarily (and I would argure are rarely) the best businessmen, the best partners, or the best engineers. They are though the guys with the money. And if your talking to them, you are most likely the guy who needs. Now, the historical balance of power in relationships between those having money and those asking for it does not need to be summarized here, except to say that one of them (I'll give the author of the article a hint, not the one without it) holds a significantly stronger position.
What would be nice is a more practical-minded article about engineers dealing with VCs(because there are many useful things to keep in mind, and are things to watch out for, even if you don't have an axe to grind), rather than the sort of flailing complaints that we have received here.
Attempting to identifying an individual's primary freedom is something that is not unique to the field of software engineering. Philosophers have been arguing over such questions for thousands of years, and I'm not sure they have reached a consensus, so perhaps that is why I am skeptical of either side getting the resounding "last word" in this discussion.
To throw my two cents in anyway, though, it seems that both parties are working with coherent definitions of freedom. Under both definitions, one person's freedom is another's restriction. I don't believe there is an ethically "correct" answer to this discussion. Both as I see it, would meet Kant's categorical imperative test(in short, if everyone were to behave in this manner, would it be desirable/feasible), and it seems to me that it comes down to a matter of what we as individuals and as a group desire more.
In this way, this is sort of a classic public policy debate: valuing competing principles/priorities to shape law. We cannot have both freedoms utterly. We can have a little of both, or all of one and some of the other. I would both like to be able to have the ability to distribute my software under any license I choose, as well as to be able to take any one's source code and modify it to my own ends. Now, if I were to attempt to give these freedoms to everyone(not just myself), the result would be a violation of the categorical imperative. It would in fact be absurd.
So what it comes down to is us, as a group, deciding on which is more important. Realistically, the best I think we can hope for is that whatever laws are put in place our shaped by us, as a community of programmers, and not by a powerful elite. I believe this is the true freedom zero(at least with respect to democracy): not that either freedom should necessarily prevail, but that we, the programmers/people, should shape the rules by which we are governed. Though these rules may not be amenable to us all, they should represent the views of the majority of us.
The DCMA is a true example of a threat, in my view, to the freedom of you and I, and perhaps everyone would be better served, IMHO, to focus on this.
Slashdot Mirror
I think you're reading too much into this...IBMs creation of SWT was a welcome response to sun's lethargy in creating a viable Desktop GUI toolkit. Swing drives me nuts...it's layered on top of awt, one if the worst(the worst if you measure it by quality + importance) apis among the java libraries. It in itself is nothing to behold either. It has a terrible memory and processing profile. And I haven't looked at IntelliJ(though I will since you have mentioned it), but the only Swing application I've ever been able to stomach is JEdit, and I kicked that to the curb like an old hooker when Eclipse came out. SWT _is_ what Swing should be and the fact that the Eclipse developers finally got fed up with waiting around for someone to make Swing _work_ and built their own is something I applaud wholeheartedly.
I do second the comment above about fragmentation, but really, there are so few Java gui apps out there(and among the ones that are, 90% are ides, probably just because if you build your ide in a language other than one it's intended for you will lose credibility), there's really not a market to fragment. My hope is that with SWT, we will start to see some real java desktop gui apps emerge.
I appreciate you taking the time to make a thoughtful response.
I have though in fact done a significant amount of contract work. Every project I have ever worked on, save one, the source code and the IP was owned by the client. In every case, I was doing this contracting work as part of a small-to-medium size team for medium-to-large corporations. These were not companies that were involved in software development as their primary vocation, but rather were using it to enhance their own in-house productivity.
The one instance that I worked on a project where the code/IP was owned by the developer and not the client was essentially a proprietary software system for which we were hired, as part of the company the originally developed the product, to make modifications to it. I feel this is really more an example of software vendor than contractor/consultant, but the lines blurs, and I was at times doing one-off smaller programs that were nonetheless utterly owned the development firm that I worked for. This was the first job I had out of school, so I can't tell you much about the nature of the negotiations, but my presumption was always that we were able to establish the contracts in this manner because we had the dominant product in the market, and could leverage this dominance.
So that is my experience. Other anecdotal experience of how companies structure their contracts on projects that my peers have worked on also backs up my views. Is is impossible/unthinkable for a company to release the control of the source code to the developers? No, it's not. I suppose there are reasons a company might do this, but to hone in on a specific point that you make:
They might, at a stretch, want to keep the code, not for reselling, but for further customization, but if they aren't a software company, in other words, if software isn't their core business and they don't have in-houes programmers (presumably the case since they hired a contracter) they would need to hire a contracter to make any further changes anyway.
This represents for me the fundamental reason why a company not run by someone very naive about software would never give the ownership of software developed by a third-party back to that third-party:
1) They will want to make customizations. Is there ever a program/pieceo of softare of more than trivial complexity and usefulness that is not modified(heavily) after its introduction?
2) They may want to do these customizations themselves or hire someone else to do them other than yourself. At the very least, even if they plan on hiring you, they are at a significantly weaker position in any negotiation if you are the one who owns the source code.
So, I will admit that it is silly for me to say this never happens or even shouldn't happen. There are all sorts of tradeoffs that go into negotiations. However, I would stand by the point that any company that pays someone to write code for them and then gives the ownership of that code back to the author they paid to do it(and not even as open-source mind you, but as that developers proprietary work) without some very strong compensating benefits should have its head examined. Perhaps it's a nice thing to do, but I can see no compelling business reason to do so, and a host of very significant drawbacks.
John
Umm, no. Crowheads point stands. Any company that hires someone to write software for them, and then gives away the ip/code to the developer is being run by idiots. There is no reason to allow this, especially the market being what it is nowadays. I would imagine it would be easier to convince them to open-source it than to allow oneself to own the ip, since if it's open-source at least they are assured of indefinite free access to it(along with everyone else too, surely, but at least they won't be at your mercy when they wan't to make modifications)
The only catch to this is if the developer has some remarkable leverage in negotiating that would persuade the client to give them the IP. I have seen this happen, but it is not the norm, and especially not for a small one-off application such as what I imagine the individual who is posing the original question is talking about.
As for a company just giving it away to the developer with no compelling reason or significant balancing contribution by the developer, I would say you are talking about a very naive/incompetent business.
John
Glad to hear so many had installations that went flawlessly. I can't say that was the case for me. I had a couple minor issues and one major one. The minor ones just had to do with the rendering of fonts by KDE/X. No big deal there, but if I was evaluating it from an ignorant user's perspective, I would say completely ugly fonts that the system produced on first boot are totally unacceptable and would have them runnning screaming to their windows installation
disk.
Other problem was a bigger one. The installer,YaST2 or whatever they call it, did not correctly recognize my keyboard. I am not sure how they compile support for usb input devices in the kernel, but about midway through the installation process, my keyboard ceased to function. This was very problematic. When I rebooted the machine the keyboard started working fine again, but the mappings for non-standard keys were not functioning correctly. I changed the keyboard setting to 104-key standard and it began recognizing my keys for a short time before again losing track of the keyboard and forcing me to reboot again.
On the whole not a great experience...I assumed the keyboard problem could have been overcome by recompiling the kernel with the correct usb settings(or at least the ones that have always worked for me) and perhaps screwing around with my X86Config file if things were still not working correctly. Were I evaluating this system from the perspective of a not particularly tech-savvy or curious windows user I would say these problems are wholly unacceptable.
John
I found this article not insightful at all...just a couple of obvious points everyone has heard before.
I'm not sure why this was linked to, but I personally feel like it was a waste of my time to read it. Only note this because I would say that this is not typical of most of the links on this site.
The two most attractive things about it in my mind are:
1) The ability to compile the code to native binary. I don't know why Sun resists making this available for Java. I am not sure what problems you allude to with Swing, but I personally have found it very nice to work with. What kills me about it is it's slowness and resource consumption.
2) The focus on adding new languages. There are other languages available for Java, but not many, and it doesn't seem to be something that Sun is focused on at all. I think this would be a great thing for Java developers.
As for problems with portability with Java, I am among those who believe that it goes a long way towards achieving the WO/RA dream. There are times when I have been kicked in the butt by it(such as moving from WebLogic to Bluestone), but I have found other transitions very easy(I have moved apps between Orion, WebLogic, and Tomcat in just about every permutation without much problem).
John
I think this could happen with Java, but probably not
in the near future as Sun needs the goodwill of the developer community for their battle with msoft. If Sun had the same market share as Microsoft I haven't seen anything to believe they would behave any better than Redmond does....
John
I haven't heard anything from Miguel addressing this subject, but I am sure he must be aware of this.
.NET.
.NET, if only because it is from Microsoft. Some would use it even if it was just a warm pile of doo-doo....
....which it is not, as C# was designed by Anders Hejlsberg, one of the better minds of current software development, as well as I'm sure of a bevy of other not-exactly-morons at microsoft. Sure there copying Java, but from what I've read, they've made up some of the annoying things about it already(such as being able to transparently access primitives and their object wrappers).
There is no one out there(at least on this site) that does not seriously believe that Microsoft will try to embrace and extend projects such as Mono out of existence if they start to challenge their hegemony in this domain. Does this necessarily mean they will be successful? They have submitted it to the ECMA after all, and if they are holding bits back, well,then that's going to be a problem for both Mono and
I imagine what Miguel is thinking is that here is an opportunity to give to the open source community a cross-platform, cross-language tool. Obviously, this is a pretty bold goal, and it may not succeed. But in my mind it is a fantastic one, and I applaud him for striving for it. Is it the best way to go about? Would they be better off getting on the Java bandwagon(which has it's own licensing problems) or Perl(which has questionable momentum) or something else alltogether? I don't know the answer to this for certain, but from where I am sitting he hasn't made a bad one because:
1) Most of the hard design and specification work has already been done for him by Microsoft(and don't think Microsoft is thrilled about this...I'm sure it pisses the hell out of them but at the same time they saw it as necessary to compete with Java).
2) You know a lot of people are going to get behind
3)
All good mitigating factors in my mind. Still, it's far from a sure thing. But neither are most really cool innovative things...
John
1) I thought Miguel's arguments for why he's getting behind the .NET Framework(the CLI and CLR to be specific) were excellent. I have read much about the Mono project since the announcement of its inception, but this is by far the best explication I have seen. If he hasn't made me a believer, he has at least made me very curious.
.NET to me seem like the obvious directions(licensing as a standard to ECMA, support for multiple languages, etc.) that Java should be going towards, but, for whatever reason, is not. I think .NET(and Mono) if they pick up steam will give sun the kick in the ass they need to get moving on some of this stuff that they are not.
2) As an active Java developer, I think that this may very well be the BEST thing someone could do to help Java. The directions Microsoft are going in with
I personally think the main reason Sun has not further opened Java up is because they have not perceived the need to. They are doing some calculus in their head to make it as open as they need to gain developers from Redmond, but still try to hold onto as much as possible of it for themselves.
3) My largest concern with this, and I didn't notice Miguel addressing it there or in the followups, is the patent issue. My worst fear is everything would go incredibly well with mono: diverse compilers, robust libraries, etc. and we would all start to build code around it, and then about 5 years down the line Microsoft whips out a patent and demands royalties for all the labor that we have done under the illusion that it would be free.
I would love to see Miguel address this concern. I cannot speak for others, but I would be a long way to considering getting involved with Mono(whether it mean using their tools to develop, or even contributing to the developmen of libraries, languages, etc.) if I felt better about these things.
I think that there are some good points made here, but I feel that a interesting aspect of this situation is being ignored. We seem to be focused largely on the legal aspects of the situation and what exactly constitutes IP. These are important considerations, but another aspect (or at least the one I am more accustomed to dealing with) is how IP contributions are a part of the negotiated price that a product is sold for.
For example, we developed a product for a customer during which they made significant contributions to the feature set that was included in the product. There were of course differences as to what the degree of their contributions were(they of course felt it was larger than we did, and vice versa), but there was certainly no attempt to deny on our part that their contribution had been significant. Of course, we argue this to them as an advantage of what we did: you get a product that is customized to your needs, so why should you pay any less for it, etc. Their retort is that they made it a better product not just for themselves, but for our other customers as well.
I believe this was a valid point on their part, and their desire to realize something for this contribution seemed fair to me. What it ended up being was essentially a discount off of what the cost of the product was. The particulars of what the exact discount was, were, of course, contested, but everyone agreed on the principle behind it.
So, I don't know about the legal particulars of any of this(except of course for the contractual ones that were negotiated), but it seems to me that whatever the law says, if the customer has made your product a better one, then it is not unreasonable on their part to demand something in return. At the same time, this is just one small piece in the negotiations puzzle. We for example were more willing to recognize their contributions since being a small company with few customers, they had a greater degree of leverage over us than say if they were dealing with Oracle. In that situation, the most you might ask for is that they implement your suggestion and don't raise your prices.
Any thoughts on this? Similar situations?
John
A few thoughts on VCs, Engineers, and Managements:
1) VCs, in general, are not very trustworthy. They are in business, they are looking to make money, and they are not afraid to step on some toes to get it. I don't think there is anything particularly shocking about this, but it is something to keep in mind when dealing with them.
2) "Your ideas, Your work, Their company" - let's not forget their money. As the author of this article himself points out, it is very difficult to raise money. The fact that VCs give people astronomical amounts of money and ask for something in return (i.e. a share of the company and a voice in how it is run to protect their investment) is not unreasonable.
3) VCs, like most people, and especially those controlling large amounts of money, tend to have a herd mentality. Do they take more risk than the average investor? Absolutely. Looking at the number of ideas that have been funded in the last few years and then turning and blaming vcs for not funding "enough" risky ideas to me seems pretty silly.
4) Good management is critical to the success of a company. This may be anathema to many of the people who frequent this site(or at least this topic), but one of the mantra's of VCs is "management, management, management." Now, I am an engineer, I started a company, but I am more than willing to admit that:
A) I am not well suited to managing it
B) If I don't find someone who is, the company will have real difficulty succeeding.
Now, obviously there are many examples of companies that have been run into the ground by bad management. Does this mean that management is evil or (perhaps even more absurd) unnecessary? No. Good management is critical to a company's success, just as bad management is critical to its failure. This may not be pleasing to our egos as engineers, and there may be exceptions to this, but having worked with some good managers and some bad ones, it seems to me to be generally true.
5) Engineers are often not good managers. Let's be honest here. Sometimes the guy from Wharton is a really lousy manager. But just as often (I would argure more often) the brilliant programmer is also a really lousy manager. Being a good manager is an hard-to-acquire skill, in some ways as nuanced and difficult to achieve as technical proficiency. Just as a cs degree does not assure programming competence, neither does an MBA assure management competence.
6) In general, I found this article to be whiny and annoying. Yes, I don't like VCs either. Many of them are "sharks"(as I was told before I got involved with them, and have generally found to be true). They are not necessarily (and I would argure are rarely) the best businessmen, the best partners, or the best engineers. They are though the guys with the money. And if your talking to them, you are most likely the guy who needs. Now, the historical balance of power in relationships between those having money and those asking for it does not need to be summarized here, except to say that one of them (I'll give the author of the article a hint, not the one without it) holds a significantly stronger position.
What would be nice is a more practical-minded article about engineers dealing with VCs(because there are many useful things to keep in mind, and are things to watch out for, even if you don't have an axe to grind), rather than the sort of flailing complaints that we have received here.
John
Attempting to identifying an individual's primary freedom is something that is not unique to the field of software engineering. Philosophers have been arguing over such questions for thousands of years, and I'm not sure they have reached a consensus, so perhaps that is why I am skeptical of either side getting the resounding "last word" in this discussion.
To throw my two cents in anyway, though, it seems that both parties are working with coherent definitions of freedom. Under both definitions, one person's freedom is another's restriction. I don't believe there is an ethically "correct" answer to this discussion. Both as I see it, would meet Kant's categorical imperative test(in short, if everyone were to behave in this manner, would it be desirable/feasible), and it seems to me that it comes down to a matter of what we as individuals and as a group desire more.
In this way, this is sort of a classic public policy debate: valuing competing principles/priorities to shape law. We cannot have both freedoms utterly. We can have a little of both, or all of one and some of the other. I would both like to be able to have the ability to distribute my software under any license I choose, as well as to be able to take any one's source code and modify it to my own ends. Now, if I were to attempt to give these freedoms to everyone(not just myself), the result would be a violation of the categorical imperative. It would in fact be absurd.
So what it comes down to is us, as a group, deciding on which is more important. Realistically, the best I think we can hope for is that whatever laws are put in place our shaped by us, as a community of programmers, and not by a powerful elite. I believe this is the true freedom zero(at least with respect to democracy): not that either freedom should necessarily prevail, but that we, the programmers/people, should shape the rules by which we are governed. Though these rules may not be amenable to us all, they should represent the views of the majority of us.
The DCMA is a true example of a threat, in my view, to the freedom of you and I, and perhaps everyone would be better served, IMHO, to focus on this.
John