Making Money With Open Code, APIs, And Docs? 194
"We've looked at the common model right now which is to sell support and give the code away on a CD for lots-o-money like a record label does. But our product doesn't work with that model very well. Our product is not many megabytes, so a CD to move bits isn't really justified. It's also fully documented in HTML, with man pages and HTML for the API, so a dead-tree manual is not needed at all. We're also doing development in a CMM-3+ environment, so there is no need for someone to buy support unless we purposely start adding "features" (i.e. bugs) or make it so complex no one can use it without calling us on the phone. That's just not an acceptable option since our product needs to operate in a five-9's environment, where if it doesn't work right it's never even allowed in the building.
We realize that if we do keep the source closed, but open the API or docs, someone will clone it because they don't want to pay for our work. Even with the typical no-quality clone, this makes the product life too short and the market too small to justify the large development costs.
Since the above model doesn't work for us, the only other way to make money (other then a sweet stock market scam) is to have a pile of patents. This is definitely not the way we want to go since we would need five lawyers for every geek in the company, and we all know software patents are all bogus since everything was done by 1975.
So did we back ourselves into a corner where we have to move to closed source or patents? Or should we just give up and go back to the day job working for someone with a pile of patents and a closed everything that can pay us? There are alot of issues here, but the bottom line is the bottom line, we have bills to pay, and if we can't pay them we'll go back to doing something else.
- frustrated."
One possibility... (Score:2)
Rob.
Why open source? (Score:5)
At the end of the day, i'd guess, your company is in business to make money and I dont entirely see why you should be so keen to open source something if your livelyhoods depend on it.
Where open source fit in nicely is when a company has some internal software that they use and isn't central to their line of business. This way they can return something to the community and other people can help them sort out bugs.
Obviously open sourcing some of your products can help promote other products, but this essentially only works for large companies who aren't dependant on one core product.
If you have developed a package which is truly unique then you could potentially make a lot of money off it, and I think that's only fair. But unless opensource fits in well with your business proposal then there's no real reason to use it (apart from that warm fuzzy feeling inside)
Ok having stuck my head up and i'm going to hide before someone shoots it off :)
Open source not good for small companies (Score:4)
As a consultant that has worked in the industry for some years now, I can say that your situation is not unique and all, and that there are quite a few companies in the same boat as you.
Whilst excersing my new-found elite Linux skills using my Corel Linux box at home I have found an essay by someone called Eric S Ramond called "The Cathedral in the Bazaar" about the values of open source vs. closed source. An interesting read, if a bit naive, but it misses out one important point - people need money to live, and if their job is programming, they need to make money from doing that.
Now the technical benefits of open source may be apparent, but the philosophical baggage that it brings with it means that do develop an open source product at work, you need to either a) generate revenue through secondary services such as support or b) be part of a large company that can support the monetary loss.
This seems to me to be an unfortunate side-effect of the GNU Public License, and it means that the smaller players in the commercial sector will be unable to move to the open source model for financial reasons. Maybe a new licensing scheme is needed?
---
Jon E. Erikson
benefit analysis (Score:5)
Do you want it to be debugged by the (purely hypothetical) "millions of eyes" of open source coders out there? No, you've already said that if it doesn't work first time, it's fucked.
Do you want the open sourcies to be involved in developing it going forward, and extending the program? If so, then consider a restrictive licence which puts it in the public domain, but with limited rights. Anyone who really wants to be involved in extending your product will still want to be involved (if it's good); as for the rest, fuck 'em.
Or do you want the deep satisfying feeling of being "part of the free software community", and "knowing that you Get It About Open Source"? Then go ahead, open it all up. But realise that this will probably be a costly luxury.
Or indeed, have you not thought about this in any very great depth yet? In which case, now might be a good time to start.
Oh yeh, and whatever you choose, software patents are almost certainly not going to help.
Microsoft is ahead of the curve on this one (Score:1)
How do you make money like this? You don't.
Microsoft has realized this for years, and, in fact, Bill Gates was one of the first to point this out with his groundbreaking letters to the software community back in the 70's and 80's.
So who says Microsoft doesn't innovate?
Community (Score:1)
If there REALLY is no room for this kind of support, try the donation-way. Make the product open source and tell the users (especially if they are compaines) that you would like to continue development etc. and some money would do good. It may work, Open Source IS the Buzz-word today.
Hard Topic to Resolve (Score:4)
Giving the code away is a good move in many aspect, it is good for marketing, and it is going with the current bandwagon. If your product is not that hard to replicate though, then it isn't worth much anyway - there is nothing terribly unique about it. Patents can be used to resolve certain IP issues - and they should be used if the IP is new, original and non-obvious. Of course, being a software only solution, you can only get the patent in America, which limits the power of the patent. You could give a free license for all free software, to avoid being badmouthed about it, but software patents are not desirable, as you point out.
Make the product a solution. Corporate entities buy solutions - basically products that solve one particular thing very well. The support for a solution will be there, and you can make money from selling the product as a solution. Many companies will also like the fact that they get the source, not the majority of companies, as it will mean nothing to them, but some. These companies will like the power to amend small things in the codebase to meet their needs.
Otherwise, you are hitting the nail on the head. What incentive is their to write easy, good quality software when you are trying to make money from support? Luckily most computer users aren't that clued up, and will need support whatever the software or hardware(Moving the Mouse for Dummies! etc).
It just depends on the target audience for the product, which you haven't specified, so it makes it hard to assess your chances. I wish you luck.
Qt license? (Score:1)
It gives people access to the source code, and is free for non-commercial use.
Users who use your product for profit, will have to pay a licensing fee.
Another Wrench (Score:1)
How can you sell a product for $500 if it uses Unix, Perl, Apache, and mySQL?
Alakaboo
Re:Another Wrench (Score:1)
So if you compile your program with gcc then you shouldn't sell it since it used an open sourced tool to compile it? Is this something you might like the GPL to cover - "If you have ever used a GPLed tool then all software you ever write must also be GPLed".
What tools it uses shouldn't matter. Otherwise you'll see a vast dearth of commercial interest in Linux as they decide that it's not worth the hassle.
---
Jon E. Erikson
How about the Alladin Ghostscript model? (Score:2)
five nines ? Support! (Score:5)
If a potential customer of yours sees more value in reimplementing your stuff than buying it from you then you have priced yourself out of that particular market anyway. So the debate is moot.
As usual in business life, offer something of value to the customer he is willing to pay for. I work in a five-9s environment. This is the perfect place for high-end support contracts. Of course no 'we will help you on the phone if you happen to get us on a free line' type of support, but a 'yes sir, we will be on site within 30 minutes 7 days a week 24 hours a day and make it work again' type of support. Priced, of course, accordingly.
90 percent of the support contracts of this kind are cover-my-ass contracts anyway, but in a five-9s environment you practically have to have these.
f.
This project remains half-baked (Score:3)
Now this is important, so I'm gonna repeat it twice, with increasing emphasis:
If the legal work is not finished, the project is not finished
If the legal work is not finished, the project is not finished
If the legal work is not finished, the project is not finished
You screwed up badly by your own admission, by not getting good legal staff incorporated into the development plan. Now you're trying to rescue the whole deal. All I can reccommend is, hire a lawyer. And don't try to cut corners, because you've clearly developed the whole thin in this lop-sided fashion.
dot-net your application (Score:1)
Keep potential patentable techniques on server side (as much as possible).
I agree (Score:2)
Re:One possibility... (Score:1)
make money ! (Score:1)
my work. But it's my job to write programms and I
need the money I get for this. I would like to
put all my stuff under the GPL (or any other open
licens...) but for this I won't get any money
Have a look at www.novashare.com (Score:1)
Re:Open source not good for small companies (Score:1)
Thirteen-year-old zealots like you make the vast majority of thinking slashdot readers like myself sick.
Re:Another Wrench (Score:1)
Jeroen
OSS Benefits vs Profit (Score:1)
If I bought a house, I wouldn't expect the architectural blueprints, if I buy a car, I don't expect the concept sketches or design drawings, if I buy a CD player, I don't need the circuit diagrams and so on.
I do work in this area of business and can only add this to the discussion. Most IT managers that I know have a whole mix of solutions. They will buy closed products to fix specific tasks, they'll pay the Microsoft Tax for their workstations because everyone (generalisation) knows how to use Windows, they have a Sun E10000 for their ERP system.
As long as they have the budget to fix a problem, most large corporations don't care whether it is open source or not.
If you are playing to the smaller market where cost is a huge issue, but your product is the only one that will do the job, then market and price it appropriately (no point having an enterprise license at $250K a year for a 5 man set up in Ohio).
Open source is not necessarily the answer. Precise pricing and marketing is. If that means OS, then do so, if not, make the cash on single license sales.
Good Luck.
Does anyone have any fuel for my Monkey Spunk Moped?
Re:Have a look at www.novashare.com (Score:2)
Jeroen
Services (Score:2)
There are probably downsides to this model as well, and I'm sure someone will point them out here. One of the chief benefits of this model, which I have not mentioned, is that the organization that supports the software need not be the one that made it (although there would be benefit to having made it), encouraging competition for support. Case in point where this model succeeds: IBM's Global Support Branch.
Why we switched to Open Source (Score:4)
Brief summary of the argument: our customers are not the people who buy toolkits and components, they're people who buy completed applications. But in order to deliver completed applications we need a toolkit to build on. If we try to keep our toolkit proprietary, it will fall behind competing toolkits (such as, e.g., Enhydra [enhydra.org]) because we don't have, inside the team, enough people to develop it and debug it fast enough.
We could adopt another toolkit (such as Enhydra) but if we do we become just another user of the toolkit, with little control over its direction and no particular reason for people who want things built with it to come to us. By being the core of an Open Source project we get potential for kudos, the ability to steer the project, and, hopefully, a wider user base for the toolkit contributing patches and extensions.
Re:Another Wrench (Score:1)
Jeroen
Re:This project remains half-baked (Score:1)
Without wishing to endorse Mr Montoya's tone (although I get like that sometimes) I think there's a valid point there.
A properly-developed business budgets for the legal and administrative side of things: a business that tries to do it any other way is stuffed and mounted before it begins. The entire world of commerce works because it adheres to the rules of commercial law with its various local variations. If you haven't factored that into your planning - or hired someone to factor it in - any success you might achieve will be more by good luck than good management.
You might consider selling your product on a one-to-one basis as a consultant or team of consultants, charging for the service of going in and setting up the system with whatever modifications the client needs.
But before you do it, go back to your business plan (you have got a business plan, haven't you?) and reworking it to include some good advice.
How to get that advice? Well, most places there are small business advice centres (get in touch if you're in the UK and I'll give you some phone numbers) who offer free advice and sometimes grant funding. Use that to get yourself off the ground properly.
Otherwise, your local lawyers' professional association (state bar association in the US, Law Society in the UK, don't know about elsewhere) will be able to draw up a shortlist for you. Get competing quotes for prices from the lawyers, and take the decision based on how much the lawyer impressed you at first meeting rather than on price alone.
Or you could try yellow pages...
Re:Another Wrench (Score:1)
Jeroen
Support Contracts are not Evil (Score:5)
Without knowing the specifics of your case (how small the market, etc), it's a bit difficult to give a detailed answer, but probably the most important thing to realise about software is the following.
In my experience, most companies who are putting software into a mission-critical situation would prefer to pay for their software than have it for free. And what they perceive they are getting for their money is not the software itself, but rather a committment from the seller that the software will be supported. Your software doesn't have to be unreliable in order to justify a support contract; nor does it have to be heavily burdened with various flavours of intellectual property rights in order to persuade companies to part with large wads of dosh in exchange for it.
My suggestion would be to not make a big deal of the software license terms. Put it under a GPL or BSD style license, or even in the public domain, but just don't make a selling point out of it. Those who are interested enough to care will ask and be happy with the answer.
Make it available for download on a website, since it will be too small to justify the pricey-CD thing, but dress it up a bit like an evaluation copy -- probably best done by making it say "THIS IS AN UNSUPPORTED EVALUATION COPY", but it depends on the specifics of the case. Remember: the suits want to buy your committment, not your software! Do have a CD, though: make it part of your support contract, just so they have something physical and professional-looking to put on a shelf. Heck, if it's a small market, you can customise it by changing the "unsupported" message to indicate their name and the fact that you are supporting them. Such a comforting reminder! :-)
The benefits of this approach are many. One is that you can skimp on lawyers. You'll still need them for your support contract terms, for example. [Reminder to those who aren't catching on: support contract does not mean unreliable software; indeed, the ideal case is where you sell a support contract and never have a call from the customer because the software just works all the time. You think they'd be unhappy with paying for that level of service?] The customer is also happy because they don't have to count licenses or install dongles or do other obnoxious things associated with restrictive licensing. You can review their support contract service level agreement at regular intervals based on their usage, however.
Once you've got some suits paying you for your support, you should then aim to delight them with your responsiveness to their questions. You might want to hire a suitably talented monkey to handle the trivial stuff, but always be available to address the concerns of those you are being paid to support. Most proprietary houses set such dreadful standards of support that they shouldn't be hard to outdo. So long as they feel you are always poised and ready to answer your email or phone calls, they'll be happy and keep forking out the support contract fees.
Of course, there's the other class of people: the ones that don't pay. They are your friends too. Anyone with a clue who is using your software and providing you with bug reports is an ally. Be responsive to people who aren't paying you but who are doing you a great service by reporting real bugs, or simply providing ongoing testing (particularly for new releases). People without a clue who can't get it to work can be foisted off on some "users" mailing list or newsgroup: nobody should expect Linus to help them install their kernel.
I could go on, but I think by now you can see the pattern that is emerging, and decide whether it is appropriate to your situation.
Re:This project remains half-baked (Score:1)
thank you; I try to achieve this effect
Geeks hate suits not for the way they dress, but for the way they think.
thank you once more for clearing that up. Of course, hating people for the way they think is a far more reasonable and tolerant attitude than hating people for the way they dress.
It seems that... (Score:1)
--
A classical closed-source case... (Score:2)
Let me reiterate what you have:
Given these factors, I'd suggest you simply stay closed-source. You'll have a hard-enough time making money from this anyway, even then.
If your customers demand source, sell it to them, but don't give it away. If you feel you need to give back to the community, there might be other, better ways - how about sponsoring development of free software you use, for example?
To wit: the company I work for makes extensive use of MICO, Xalan, Xerces, and Apache. We're closed source, but we contribute fixes, fund MICO-MT development, and will soon sponsor standardization committee activities for XML-Apache. In the end, everyone's happy. Maybe that would work for you, too?
There are several ways to make money.... (Score:1)
1. Subscriptions to enhancements
2. Technical and how-to support
3. Consulting
4. Add-on or related products...e.g. hardware, other SW, books, etc...
5. Build a total solution around the OSS
6. Advertising revenue on the web site (assuming volume traffic of course)
7. Use the old MySQL model of keeping the newest release closed or gated and fully open sourcing the previous release
Good luck!
Army No. Va.
GPL4F (GPL for Friends?) (Score:1)
I was thinking of something like "GPL for Friends", i.e. make the code publicly available for a) personal use, b) for companies that made significant ('hello world' won't count) contributions (either in code or financial) to the Open Source Community, c) for organizations that are commonly known as to be of non-profit nature (no, COS doesn't fall in that category).
All others are required to pay if they intend to use that code.
Another possibility would be to require the user to register the code (which then could be downloaded without further charge). That way you'd at least know who your 'customers' are.
Re:This project remains half-baked (Score:1)
Perfectly, true, but there is no base whatsoever for the claim that the license is more important than the product itself. Don't bother citing Microsoft, what made them successful was neither the quality of their product nor the license, it was the marketing.
A crappy product will most likely fail, and the license is definitely not going to prevent that.
Finally, license consideration are almost totally separate from technical aspects; there's no reason why you can't write the code first and worry about the license later. Ideally, you should, of course, do both at the same time.
Re:Another Wrench (Score:1)
Why can't I use the decrypting program to decrypt the encrypted source?
Because you don't have the encryption key? That'd make it quite hard wouldn't it?
---
Jon E. Erikson
Contact a VC (Score:1)
Re:Support Contracts are not Evil (Score:1)
What's the difference ... (Score:1)
- you can amortise the development costs across many companies (ie fairly large client base)
- the software is NOT their core business
- you offer a faster growth/development/debugging rate than they can do in=house
- the collective feedback and user support base cuts down on internal costs
- the software creates productivity but requires serious training (e.g. certain financial trading packages) in which case you put on courses and charge real-line (same time/place) help (ie charge out rate)
If it is a once-off, work many times without fault then perhaps you may wish to offer it as an embedded device. Ie get a small linux kernel, compact in your software, database logs, management tools, etc and sell it as an item with remote monitoring on a long-term on-going basis. If people can recognise the service of 24 hour monitoring, then they should be able to cost it.
If it is a specialised area, requiring specific domain knowledge, then offer it as a leader to your professional services (a la lawyers doing pro bonum work).
If it is something so trivial that anyone can recreate it then why are you trying to charge above market rates? Ie buy vs build argument. People forget that the main function of a market driven firm is price discovery, finding an appropriate market value for their goods/services. If you think you are worth $100K+/person, but the market doesn't share your sentiment, then we've got a serious reality discontinuity here. This leads to a rather interesting angle on venture capitalists as what are they really investing into? A collection of intangible goods which may have fluctuating value depending on what other people don't know?
The open/close source is just a distribution mechanism. You still have to think about what business you are in, who are your clients, and how you can align your specialised resources with their objectives.
LL
Open Source and Market Makers (Score:1)
A big advantage of open source is market-making: open-sourcing a product might build up a large community of users and integrators, and even if only 5% of users buy the fancier commercial version of a product, 5% of a $100M market is much more interesting than 100% of a $100K market.
In fact, a lot of companies will buy the commercial version if it's easier to integrate into their systems: skilled engineers are expensive and rare, so they have to be rationed carefully among projects. If the commercial version of your product can be installed and integrated by a junior person alone (i.e. installation GUIs, custom adapters, etc.), then it's easily worth $20K-$50K to a company; it would be stupid to try to install the Open-Source version if it meant pulling a good techie off an important project, and maybe delaying a major lauch, just for the sake of saving a few thousand dollars.
After all, $20K is the cost of sending, say, 8 engineers to a single trade show.
Prey on closed-source minds! (Score:2)
There is a way to make money off GPL'd code, and it's been used by at least one product already, FFTW. FFTW is a high-speed fast fourier transform library, "Fastest FFT in the West", and it is distributed under the GPL. This means that it is available to anyone that wants to use it in their own GPL products.
So, I'm working on a project that uses this fourier transform to calculate derivatives of shoreline for calculating boundaries. I need FFT code; I go looking, boss man says write your own. I do, preformance sucks, no suprise. This stuff is at least one order of magnitude faster! But, boss man doesn't want anything to do with that communist open source code business.
Hence the magic. The author of the code can put whatever liscence he wants on it - or as many liscence as he wants. In this case, if you want to use it in a closed source commercial project, you can get a liscence for $5000 smackers, which is what the company ponied up - of course, they still made (much) more than that back.
Thus, this allows the two worlds to live together - if you want to get support, etc etc, pay the big money for the commericialized version. Or get the free version, with no warranty, as outlined in big letters in the GPL.
kudos!
Act like a Troll (Score:2)
I mean, one of Troll Tech [trolltech.com].
All you have to do is to release your software under two different license: one open, that benefit from the Open Source development model, and one closed, whose you sell license to those that want to create (or use) closed-source stuff. This way you can combine best of both worlds.
Note, however, that it's not possible if you use free software code that you don't own. You may need to workaround this by spliting your programs in different parts, to isolate those you don't own and this way always release them under their original license without putting the rest of your work under the same licensing term.
Support means also hot-line and warranties. The "commercial release" will include them in your offer, and the "free release" will just have a disclaimer. Some people wants warranties, even if you swear your program is bugfree. These people will buy your stuff. "Service" dosn't mean you have to obfuscate on-line manuals and add bugs, just that your customer can ease his mind by thinking if your program crash his data, he can sue you.
Use a time-delayed open source licence (Score:4)
The product you sell could include the source code under a disclosed source licence (but a user would still need to pay your company to use the product). Furthermore, you could permit registered users of your product to develop modifications and send each other patch files, as long as you are permitted to put the patches in your future releases.
Sell peace of mind ... (Score:2)
But basically two models immediatelly comes to mind. Sell the peace of mind aspect, garantee (Don't have a clue how to spell this and no time).
And the other possibility is the expertize, people are willing to pay because they trust the person that sell's or supports the project.
Again it all depends on the project and the market. Make a deal with another company that have a complementary project let them pay for the development or alternativelly sell bundles with your stuff included.
Eg. Development project sell a Redhat CD with your product included a nice smile and support for the whole set of product for 6 month with direct access to experts in the field. Keep a constant contact with your customers ad I promise you they will be hooked. Add to that the possibility that you can sell the installation and the training for the product (training is kewl because even if the product is very easy to use people will still pay for it.)
Suffice it to say it is possible to sell alsmost anytnhig related to the product. Just think of it as a service industry and your home free. Sell your time your services.
Cu
jacobus@firsttech.net
Re:This project remains half-baked (Score:1)
Re:This project remains half-baked (Score:1)
I have to disagree with your last point there. There is definitely a case for considering the licencing before or during the coding phase.
You need to consider the licence implications of whatever development tools, utilities, and so on that you use.
For example - you may use a development language which requires annual run-time licences for all your users...
or you may want to use a third-party graphics library which requires that any project using it has to be entirely open source...
The point here is that you really do need to consider the licence implications of everything you use for development, from languages and APIs to editors and operating systems. Of course, not everything will restrict you, but you'd be suprised at some of the things which do.
Re:Another Wrench (Score:1)
By this token shouldn't products like Star Office and Corel Draw be GPL'd?
Actually, to be honest with you in a way I wish this were the case - if StarOffice were to be GPL'd something could probably be done to make it run acceptably. Unfortunately, according to my reading of the GPL a program doesn't have to be GPL'd unless it is a derivative work. The way I see it goes as far as this : if you writen arseware v1.0 and release it under the GPL, then completely re-write all the code for arseware v2.0 even if it looks pretty much exactly the same and does a lot of things the same way it doesn't have to be GPLd. Of course, IANAL.
Re:Obviously you are not a GPL expert (Score:3)
Imagine that it is. Then no one can use any compiler that does not give an explicit permission to copy compiled binaries in its license. Now check out any compiler license from Microsoft, Borland, or Sun. Is the permission there? Check out your Notepad and Word licenses too. Do they give you an explicit permission to copy text files that were processed with these tools? No? You're SOL.
--
Random thoughts (Score:2)
If you are aiming at a large enough market, it is quite possible to get the benefits of open source without giving up the benefits ($$$) of non-free software. Put the source on the CD, shrink wrap the box, and stick it on the shelf in all the chain stores. It'll sell same as any other commercial product. After all, source code's only useful to programers, and we're a very small slice of the pie.
Likewise, if your taget market is very narrow, what do you lose? Chances are you were only going to make a few hundred sales, and in most cases those would be from larger businesses. In this case, you go on a support model.
Will some unscrupulous bastard give it away online? Sure. That'll happen with or without you opening the source. But by opening the source you've developed a rapport with the Open Source community, with all the benefits therein.
The only place I can't see Open Source non-free software working is in the mid-sized markets, but those are rarely where you find big money anyways.
Neu
Re:Another Wrench (Score:1)
Well, if you write it, then you can release arseware v1.0 under a proprietry licence. But yeah. There is no reason you couldn't write a closed source clone of gcc, or Linux as long as you were to make sure that you didn't copy any of the code. A clean room implementation would be the safest way of doing this.
Re:five nines ? Support! (Score:1)
> value in reimplementing your stuff than buying
> it from you
>
I would have thought the problem would be with
competitors free riding on the expense involving
in creating a market for implementing these
particular APIs.
similar question (Score:1)
a company (publishing house) wants me to write a program for them. i told them i wanted to gpl it, when it is finished. and they seem to have no problem with that.
there are multiple reasons why i want to gpl it. anyway... the question is: can i get paid for writing the program, while still making it free software and open-source (gpl)? so what i want to do, is selling my time, not selling the program.
especially i would like to know if this is ok with gpl, since i really don't want to violate this important license.
even if my program is not very usable for others as a whole, there are big parts in it that could be "recycled" in similar programs.
the answer is out there -- it's looking for you -- matrix
Re:This project remains half-baked (Score:1)
Alternative models (Score:2)
- Why not release it as open source, but as shareware, so that if people want to use it they can and it is up to their conscience to register and send you the $50 or whatever you feel is appropriate. Remember, though, the more you ask for, the less registrations you'll get.
- You could offer rebates for people who have registered and then send in bugfixes.
- Alternatively, release as open source, but only charge for commercial use (like MySQL - http://www.mysql.com [mysql.com]), so again, it is up to the company's conscience to send you $100 or whatever you think a company will think it is worth. Non-commercial users don't have to pay, but will quite likely contribute bug fixes and improvements.
- You could have a stable, bug-free version, and a development version that the contributors will help iron the bugs out of.
- Combining these approaches further, you could charge for the stable version (maybe release as binary only?), but allow free use of the development version to encourage bugfixes.
Well, you may agree with some or all of the above, or even none of it. I am interested in what others think.J
Open Source and Guilt (Score:3)
Seems to me that most OS code has been developed by coders who have been supported in whole or in part by universities, benevolent corporations (large enough that they can't keep track of what some of their employees are doing, perhaps
Because circumstances allow this code to be developed for "free" -- it seems right that it should be released (with source) for free.
Code developed in the marketplace -- where the software developer assumes all of the risks and costs of development should have some rewards. Developers should not have to ask for remuneration by dangling support, upgrades or plain old begging. Whether or not the source can or should be released to the end user depends on the application/cost etc.
In any case, why should programmers feel guilty about selling a good piece of code?
What about the "millions of eyes" benefit of Open Source? No question that a large number of programmers have helped turn Linux into a viable server platform (I think the jury is still out for widespread desktop use).
I submit that for some applications, software is best improved by setting up a feedback loop with millions of CUSTOMER eyes -- not PROGRAMMER eyes.
So, if your company can muster the resouces to sustain the development of its software, then setting up a feedback loop with customers to further development seems like a good strategy. Let your customers "direct" the development by providing feedback on the features and functionality they desire.
Depending on the product, opening up APIs or code (with some reasonable restrictions) may turn out to be a requested "feature" -- or not.
Re:Another Wrench (Score:2)
--
Re:Random thoughts (Score:1)
I've been tempted to use this method with GCC for windows port. Write a quick and dirty IDE, and throw in Java, and you can undercut anyone. Except other people who copy your strategy.
Look at the Embedded scene! (Score:1)
Re:Why open source? (Score:1)
"What Do Users Owe to Developers?
There is a good reason for users of software to feel a moral obligation to contribute to its support. Developers of free software are contributing to the users' activities, and it is both fair and in the long term interest of the users to give them funds to continue.
However, this does not apply to proprietary software developers, since obstructionism deserves a punishment rather than a reward."
Presumably we should be "punishing" Frustrated for even considering a proprietary sales model -- and yet half the respondants here seem to be advocating one!
I've always considered Stallman's philosophy specious -- it explains how "free software" benefits society, but provides no mechanism through which society may fund the development of such software on a large scale. As such, it's a bit like a perpetual motion machine -- lovely for society to have one, yes, but providing no blueprint for its design.
Apparently I'm not alone among Slashdotters in my my skepticism of the "free software" model?
Re:Support Contracts are not Evil (Score:2)
It takes no wizard to see that they will find out they're paying the price for every freeloader that you have on your product. Now, if the bugs in your product gets fixed, they will have no incentive to further support you. Especially when they got all the features they need. The companies will review their budgets and find what to cut down, and believe me, they'll cut whatever they can in bad financial times. Regardless if they "support" the Open Source movement or not. Note that this will only happen if your customers see your product as "finished". (Side-note: Quite the opposite is why Microsoft and other companies is such a big success. With a big enough smirk, you can fool anyone into buying glory promises, and forget the gory truth.)
So, all in all, there is money in this. You just can't expect to live on it forever. There's also less money than if you make it big proprietary. On the other hand, you may get support from freelance coders, and you will get good PR through the geek community.
Successful Open Source projects tend to start living lives on their own. Proprietary projects tends to get cloned by a competitor, though this is more costly and difficult. There's no guarantee for making money either way. To make sure your code is not used by competitors in their proprietary applications, I would recommend a license aka GPL. Public domain or BSD-style licenses is not something an egotistical company should use on software they have developed.
On the other hand, if the initial code or concept is so simple it can be cloned or extended by any competitor in the market. You're in big trouble from the beginning on. As a small company you don't really have much to say, and a big competitor may use lots of more money than you just to catch on and get in the leading position. So I would make sure I had plenty of deals with companies before making the bold decision to Open Source the wares or even go public with your products.
It would also be wise to patent whatever you can, otherwise you may very well find yourself in a patent-infringing lawsuit. Don't listen to people who tell you not to patent, because the system is just not willing to listen when you complain afterwards.
- Steeltoe
oh god, not this old chessnut again. (Score:1)
2) advertising revenue
3) "gold" packs with better features
4) market capitalization (must assume your product is worth something)
5) consultancy.
*yawn*
Re:Support Contracts are not Evil (Score:1)
- Steeltoe
Why not just use a regular license? (Score:2)
I don't understand why developers who feel secure releasing binaries are always so anxious to accompany the binaries with source. The assumption seems to be, "If I ship the source, some nasty bootlegger will come along and copy my stuff." But obviously it is considerably easier, rather than copying the source and recompiling it, to simply copy the binaries, or even to make a perfect duplicate of the entire install CD.
Look at Microsoft; they do not copy protect their software. Technically speaking you can duplicate, for example, the Office 97 CD. Has Microsoft gone broke? Hardly! They're the richest software vendors on the planet, but the only thing that prevents them from going broke is the respect end-users have for the terms of the EULA, or their fear of liability should they get caught, or whatever.
If a simple EULA is good enough to make Microsoft as rich as they are, why isn't it good enough for you? Simply draw up a license that says "you, the end-user, are only allowed to install as many copies of [your product] as you have acquired paid licenses therefore" and put it on the sleeve of the disc with the binaries and source. Yes, it doesn't protect you from a determined bootlegger, but then neither does withholding the source code - that bootlegger will simply copy the binaries, which are all that ninety-nine percent of users want anyway. If you're still upset over the possibility of a handful of illegal copies, then the only realistic solution is to close your code and ship your product with a parallel port lock or something like that - and even that will probably be cracked by some warez d00ds somewhere.
Yours WDK - WKiernan@concentric.net
VC's also want to earn money (Score:1)
--
Re:GPL4F (GPL for Friends?) (Score:1)
Ummm.. why... if you are going to use a GPLed piece of code, you need to GPL the program you are using it in, so that prety much already takes care of all of those requirements.
Of course it seems that you don't want to even make it available unless those requirements are met, unlike the GPL which would let you see it, but not use it in something.
Or maybe you would like to allow companies that meet those requirements to use the code in a closed-source project... definitely not going to happen, not my code anyways.
If I release something GPL I am letting anyone use it so long as they grant everyone else the priviledge. That is fine by me. I have also released code under the X11 license (basically free for all). That is also fine for me, and I actually would prefer to see more X11 licensed code, especially for really simple stuff.
Honestly, I don't exactly see the point of what you are proposing (and it almost seems like you are just trolling, but I'll give you the benefit of the doubt that you are just ignorant).
Don't get hooked on Open Source (Score:1)
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
Re:Hard Topic to Resolve (Score:2)
Economically "public" goods are those where my consumption does not stop your consumption, and consumption does not diminish the supply.
Economically "private" goods are those where consumption by me excludes your consuming the good, and diminishes the supply.
Information is a "public" good, software is therefore also such.
Money is a "private" good, as is your working time.
In selling software you hope to set up an artificial economic inefficiency (I take your of "private" goods, i.e. your money, if you use my "public" good i.e. software) in the hopes of leveraging your expenditure in "private" goods. You want more money for developing the software than someone gave you for doing the development.
It's hard to maintain that sort of inefficiency, especially against competitors who don't want "private" goods for distributing "public" goods (e.g. someone giving away similar software). Usually this inefficiency is maintained by preventing the recipient from understanding the software (e.g. providing an opaque, compiled form) and/or legal structures (licenses, legally enforced rules on behaviour).
Unfortunately, if everyone decides they want a piece of information, legal remedies will disappear, since these remedies are just agreements about what everybody wants. If someone also understands your code (decompiles it, gets the source), you are left without a defense of the economic inefficiency. Furthermore, since you cannot guarantee that the software does what you say it does, (that's an NP complete problem) you face the problem of trying to sell someone something but being unable to guarantee that they actually get what they believe they are buying.
Resolution?
If you program for a living, then don't program unless someone is paying you for it. Sell your time, not your information. You can enforce selling your time because you can withhold the goods if payment is not forthcoming. You cannot do so with software.
Remember, F=ma. You can't push a rope. Also laws of the universe...
This is also why 95% of software is written by people being paid to do so.
Re:Obviously you are not a GPL expert (Score:1)
(-1, hilariously misinformed)
(-1, obvious MS shill)
(-1, software bigot)
(+1, unintentionally funny)
(+1, good haiku)
or, in this case,
(-1, total nonsense)
Re:This project remains half-baked (Score:3)
Surely, JSM, you will have permitted me to hate Herr Hitler way back at the original publication date of Mein Kampf rather than withholding judgment until he began to transform those lurid thoughts of his into concrete actions.
(Don't you dare give me that "Godwin's law" crap. I won't put up with it; it censors out discussion of mid-twentieth-century history and politics unconditionally.)
At any rate, the true reason "geeks" hate "suits" is because whenever unopposed, "suits" eventually start to insist that the "geeks" must dress themselves in "suit-wear," to be specific, neckties. And neckties are evil. They strangle your respiration, they appreciably choke off the vital circulation of arterial blood to the oxygen-hungry brain, and insensibly but surely they misalign one's delicate neck vertebrae. You all legal hotshots and rich execs can afford weekly therapy at chiropractors or massage parlors, but the rest of us, if we do not vigorously resist the abomination of neckties, eventually end up hopping crawling and limping like Igor, decerebrated to the tragic point where all we are capable of is watching TV.
A fate worse than death, I tell you! Burn those neckties, burn them all! If the "suits" refuse to take theirs off, no matter, burn them as well! You tight-squeezed and breathless ladies are welcome to throw off your garments of oppression and fling your brassieres into the bonfire as well.
Yours WD "hack in the nude" K - WKiernan@concentric.net
Re:Obviously you are not a GPL expert (Score:2)
I'm too lazy to type Sun's license agreement, but apparently it seeks to regulate distribution of compiled binaries only if the binaries happen to use "Tools.h++". This makes perfect sense to me. Tools.h++ is a library distributed as source code (by Rogue Wave I think). Software that uses Tools.h++ is a derivative work of Tools.h++. Compilers have nothing to do with it.
Oh well. Apparently all those companies that release closed-source stuff for Linux don't have legal departments, or use some super-sikr1t non-GPLed compiler. And the whole *BSD family is screwed, too.
--
Making money in software (Score:3)
Sell add-on modules to the basic package.
Sell interface programs (from your package to other software packages).
Sell pre-loaded database of industry-standard (non-copyrighted) data.
Sell pre-loaded database of specific (licensed) data.
Sell pre-loaded database/catalog of vendor-specific data with an agreement from the vendor paying you a comission on product sales due to your software. (Major opportunities here.)
Sell custom code modifications.
Sell installation and training.
Sell services (remote application/data hosting).
Sell the associated (and required) big-buck database package (i.e., be an Informix, or Oracle reseller).
Sell software upgrade contracts. (Send notice/cd-rom when software is updated.)
Sell software support contracts. (Dial-in and telephone.) Assumes basic package is limited or no support.
OK, that took less than five minutes to come up with.
Thing is, figure out which you can do for least up-front outlay. Then offer that product/service. If it costs you nearly nothing, you don't lose big if nobody wants to buy, and you still have an impressive product/services list. The fact that not everybody will buy a particular product/service does NOT mean that NOBODY will want it.
Add to your product list. Keep adding to it. Don't let people think that you are a "one-trick pony". There's a world of folk out there who only want (for example) general ledger and accounts payable but who will not buy unless your product sheet shows payroll also.
I spent over eight years learning these lessons. If the moron who owned the company had learned any of them, we'd have made big bucks. He didn't; we didn't.
Good luck.
Stuff and nonsense (Score:2)
Which is to say: a suit (dark grey, navy blue, or pinstripe), a shirt (white, windsor collar, or button-down for Yanks) and a tie (regimental, polkadot, or City silver). Black brogues and socks.
Pop quiz; where is the greatest concentration of suits and ties? Japan, that's where. The reconstruction of Japanese society after the war can be directly traced to their adoption of Christian dress codes. Meanwhile, the decline and fall of America, Britain and practically everywhere else into a moral cesspool of drugs, casual sex, guns, and liberalism can be traced to the 1960s decision to shun the tie.
I think of the open collar as a "gateway drug", leading on to harder substitutes. From the open collar, it is but a small step to being jacketless; thence to the round neck; then the (shudder) short sleeves and than (I can scarcely bring myself to say it) "Genoese cut trousers of Serge de Nimes"
You will note that your own Mr. Hitler, while often seen in competent (if ugly) German tailoring, could never get a really good four-in-hand not to stay in his tie (often resorting to vile swastika tie-pins). Indeed, at the first chance they got, the whole mouldy bunch of them trooped off to the Black Forest, collars flapping open like so many deaths' head flags! Lederhosen! And the Tyrolean hats were hardly bowlers. You were quite right to hate them on sartorial grounds alone.
Remember, (if I may be permitted to avoid the invocation of Godwin's Law as well), that history has shown us that those who begin by burning foundation garments will later burn people. And the necktie is a foundation garment. It is the foundation of honesty, morality and decency.
On a more practical note, a well-cut suit conceals a multitude of sins, from a too-much-Chinese-food-and-Mountain-Dew belly to a pair of too-much-Quake-and-not-enough-rowing sloping shoulders. Geeks and coders are precisely those who are most in need of them.
thank you.
Re:Support Contracts are not Evil (Score:2)
What makes you think there is a price to pay for the "freeloaders"? The non-payers won't be using valuable support time. There might be staff time spent looking over the "unsupported users mailing list" for real bug reports and fixes, but if you get any reports or fixes then that has more then payed for itself (for a low volume, this is a single intern's job, almost free by corprate standards). If you don't seem to get any reports or fixes, you don't pay anyone to do that job.
The other "freeloaders" frequently would not pay for your product anyway, they are poor studants, super cash straped start-ups, and places where you product is super-over-kill. Those cost you nothing, you wouldn't have lost the sale, but by giving away the software you get free training, free bug reports/fixes, and free advertising if any of those studants should graduate and go somewhere that needs your software, or if the cash-strapped startup gets a big contract and suddonally needs your product to be gaurenteed to keep their cash flow!
There are a vanishingly small number of customers for a corprate product that would choose to have no support. They buy Red Hat at $60 a box, not the identical CD from cheep bytes for $1.99 with no support.
My guess is that this vanishing small number will be ofset by the extra sales your "marketing" move of giving away free copies with source will bring in. Plus bug reports/fixes (if any).
Depends strongly on the product's market. Componies will pay for support on mature products that havn't been observed to break if their breakage will cause a large loss of money, or if the support contract is quite cheep. How many places that have never had a disk failure buy RAID arrays? Or support contracts on new hardware? Support contracts on the RAIDs even?
Think of it as the software equivolent of an extended warrienty. They may normally be crap, but most people buy them. Componies arn't any smarter then people. In fact they are a lot lot dumber sometimes.
I don't see where there is clearly less money involved for a bisness targeted product. You are right that you can't count on getting free bug reports and fixes just by open sourcing something. But you definitly increse the chances from 0% to something possable (for bug fixes/free new features).
It doesn't make sense for some products. I don't see any way a OSS family tree product could make signinfigant money. That would have to be done to "scratch an itch", or for the "glory". But that doesn't mean all OSS trades dollars for glory.
I'd wait if I were you. (Score:2)
Re:Don't get hooked on Open Source (Score:2)
>>>>>>>>>>>>>
This is a very important point. Open Source is meant for the common good of software users. As such, it enables anyone to take a piece of work, and improve on it. However, this very fact makes it impractical for a business. Consider this. RedHat spends time gussying up Linux for the mass market. It spends actual money make these additions. However, if they release them under the GPL, a competitor can simply come, take their changes, add something little to it, and end up with a better product. This isn't seen much in Linux, because the product is essentially already developed. However, say I write an application. I GPL it and make money by selling technical support. A competitor can immediatly come and make some improvements, and sell the resulting product. He now has a better product, and thus gets the sales. However, he did very little to "create" his product. This doesn't happen in the closed-source world, because instead of just taking your code, your competitor actually has to do work to create a competing product. It takes a lot less work (read: money!) to make small improvements to a product than to create a better product.
Promise GPL after _X_ years? (Score:4)
You could put something in the license, though, that says "in 2002, this license will be null and void, replaced by the GNU General Public License (see Appendix A)"
That way, people have a warm fuzzy that the product has a life even if _you_ choose to move on to other things, they get the source right up front if they need it, and it still looks like you "get it."
What do you think?
---
Why did you write it? (Score:2)
Why did you write a product, before thinking about what you were going to do with it. The best fit for Free Software is stuff which you do not intend to sell -- for example, you may have been contracted to produce a POS system for a retailer. Once you have fulfilled that contract, and got paid, *then* you are in a position to GPL the source (unless the contract forbids it).
If you "just wrote it" with no real use for it yourselves, then selling it, closed license, is probably the only way you'll make any money. The best Free Software products were written because the author needed the software to do their job: take Apache; writing software was not the author's job description -- running a tight Web server was. Writing Apache made their job easier; giving it away (and developing an Apache community) made their job easier still.
--
Open Source may be nice, but GPL won't work. (Score:2)
Keep It Open But Charge A Lot. (Score:2)
After someone on USENET mentioned some version of gcc that was modified in a very specialized way, and sold for $5000, that got me thinking. Under the GPL (and many other open source licenses), you don't have to reveal source unless you distribute. If the price point is really, really high, the fact that you are giving the product away (after the sale) won't matter.
Think about it. Sure, people burn red-hat CDs and give them to their friends all the time. It's only a few bucks. Pizza money. What's a pizza among friends? OTOH, some business that payed $5000 for a system is not gonna just burn it and give it to a friend.
This obviously only works if the system you are selling is worth that kind of money. What you are describing sounds like a fairly specialized mission-critical business application--the niche for which I've anticipated that this business model for open source could be successful.
This model obviously fails for small, general purpose, consumer applications (drawing programs, spreadsheets, word processors and the like). Nobody will pay $5000 for that kind of stuff.
I have also toyed with the idea of anouncing that all my software will be Open Source. But it will cost you $200,000. Hey, Free Speach is what matters, not Free Beer, right? :)
As a salesman for your company, I'd approach customers and sell them a system which includes software that they will be allowed to modify and customize without legal restrictions. Sounds like a good product now, eh?
Re:Why is *BSD screwed? (Score:2)
Oh wait...you probably are that AC. Must be pretty hard to troll without contradicting yourself, eh?
--
You can open just part of it (Score:2)
Troll Tech got it right ( with a few bugs ) (Score:2)
If your product is a software library that can be used as part of other products then do exactly what Troll Tech dose with the QPL license too.
If your product is a server that dishes out content over the web ( AKA Real Player ) You make provisions that people must pay you or fully allow wholesale copying of all the content they distribute.
There are other solutions for other situations the key thing is to make your software free for those dealing in free content and free software. If it is done that way while remaining open source there will never be enough incentive for competent people to produce a free ( bear and speech ) clone.
You see people who live by copyright will find it simpler and perhaps cheaper to pay your license fees. Meanwhile those who live by Free Software and Open content will have no need to clone your stuff once the original works OK and you accept patches.
For proof of this just read of on the QT history. Ohh.. and try not to have any GPL compatibility issues even if it means saying "Thou shalt not write GPL code with our software"
Customers fixing code (Score:3)
However, they will become more and more knowledgeable with the software, especially from the user-side. This will extend codewise if they can get the source easily. There'll be situations where they want to fix stuff themselves, in order to meet deadlines and other things.
I don't quite agree. The time it takes to determine that a bug exists, locate the bug in the code, figure out what the fix should be, test the fix to make sure it works, test the fix again to make sure it didn't break anything else, then to implement the fix, is just too much for most people.
It's not that they aren't intelligent enough to read code and see the problem -- I can usually do that, and I'm not a professional programmer -- it's that it often requires a significant amount of time and mental energy to wrap your mind around a problem. I don't want to take *my* time fixing *your* code, even if it's something that I need done quickly. I have more important things (to me) to do. Instead, I would prefer to call you up, describe the problem, perhaps give a rough explanation of what I think the bug is, and then be able to say "Our service contract says you'll take care of this. When might I expect an updated version?"
I don't think that open sourcing would drive companies away, unless they had enough resources to dedicate people to understanding and maintaining the code in-house. In that case, they're not buying the product anyway, and wouldn't be interested in a service contract either. However, it may pull in some people who would like to know what's going on inside that box on their desk -- people like me who like to tinker around with the code, but don't want to have to rely on my own skills to get some jobs done.
kipli
Re:Obviously you are not a GPL expert (Score:2)
--
Re:Obviously you are not a GPL expert (Score:2)
--
Re:Obviously you are not a GPL expert (Score:2)
--
Re:Obviously you are not a GPL expert (Score:2)
--
Suits are overrated. (Score:2)
I see no problem letting people dress the way they want- as long as they get work done! Would you rather have an office of slightly agitated coders or happy, relaxed coders, assuming both groups get the same amount of work done? If someone isn't working, fire them. If they won't work without a suit, they won't magically be motivated to work with one.
Before you start complaining about our style of dress having such complete control over productivity, give us some facts. Prove to us you are right.
I seriously doubt that a particular style of dress is the "real reason that so many of these Internet startups have failed." It may have a slight effect, but I'm guessing there are other, more significant things that cause the failure of a company.
You are probably right that a suit conveys the idea that you are there to work, but the lack of one does not mean that you cannot work.
Not wearing suits does not mean "insisting on comfort over results." No one ever said the two can't coincide. No one ever said that this industry was full of lazy, irresponsible geeks, either. If it was, the internet would work as well as a Microsoft application, and all the cell phones, pagers, videoconferencing equipment, office computers, and other office equipment used by who the geeks call "suits" would be about 10 years behind what it is now. I'm not saying there aren't lazy, irresponsible geeks out there, they're just not the ones running the industry. And wearing a suit has never been proven to turn a lazy, irresponsible geek into a stress-free, higly productive worker.
Not a moral imperitive... (Score:2)
1. The Million Eyes. If you compile it they will come. If you open source it they will come... and fix it. At least that's the plan. Naturally "sexy" products get more attention in this model.
2. PR. Ugly, but true, a big chunk of OSS's benefits come from the PR boost it gives. Sure the stock-frenzy has calmed down a lot in the last while, but investors and customers still think that those of us in the open source camp know something they don't. Gosh, they say, they're giving their stuff away as a business model... they obviously know something we don't... buy their stock/product.
If you need a dose of 1 or 2, open source is for you. If not, open source is still an option as long as it doesn't put you out of business (or if you were never in business in the first place).
So, let's look at both: Number one (million eyes) can be an advantage. If your clients are 5-9s systems (I hear they exist, but working in a system rated as "an 8, a 5 and two 9s" I have a hard time imagining it) a million eyes may be regarded as a bonus. However, if your software is highly priced (as 5-9 stuff tends to be) you may be shooting yourself in the foot. Keep in mind, however, people will pay for the package to appease their boss. Witness my network. We run 250 Mac clients off several Solaris boxen. We use ethershare (about $12k). Netatalk is free. Fortunately for Helios (makers of ethershare) our uberboss would have an aneurism if he thought our workflow was entrusted to "something we downloaded off the net". It's not even a support issue... 80% of support is available in German only. Zum tuffel! ich ein komputererror! The question is: do the number of customers who will pay for peer-reviewed software outweight those who will download it for free. Get out the ouija board.
Does OSS PR matter? The question here is, do you believe that putting the GPL stamp of approval on your company brochure will move it closer to the top of tbe in box on the customer's desk. The PR game is tricky because you have to account for positive and negative publicity. You can have a great product, but if it's not open then all certain reviewers will discuss is your license.... not your software. Open sourcing avoids this bad PR. The good PR is trickier. For some customers it has a strong positive effect. For others, none at all... and for some it's a Bad Thing. If my Dad was shopping for serious corporate software (and god forbid he may one day...) he would definitely be adversely effected by open source. Sure he knows almost nothing about computers, but the vast majority of corporate budget-holders don't either. FUD is reality.
The bottom line IM(sometimes)HO is that you need to poll your customer base. The question is not "do you want open source" but do your customers want open source?
Re:Why open source? (Score:2)
>>if i had to deploy something mission critical i'd use Sun and Oracle
What about using apache in a mission-critical environment ? Your example does not support a comparison of open vs closed source. I think that anybody who's been using Linux and Solaris long enough would agree that at this point, Solaris is more robust and scalable. Same with Oracle vs the various open alternatives. However, Apache is proof that the OSS model works; it is the BEST web server out there. I tend to believe that eventually, Linux will blow by Solaris, and mySQL will surpass Oracle. Or maybe not. =)
Re:Why open source? (Score:2)
Notice he didn't list a webserver at all in the second set - and in fact, Oracle's *own* webserver is now a modified Apache....
--
embedded system royalties, other.... (Score:2)
Then why do many embedded system compilers charge per-customer royalties? Why did (does?) Microsoft include restrictions on the use of its compiler, e.g., you couldn't use MS C to develop a competing operating system or compiler?
This is one of those questions that can only be definitively answered by case law, but as I understand copyright law there is absolutely no doubt that the output of a <b>compiler</b> (but not assembler) is copyrighted. That's because compilers involve a significant amount of creative expression - do you unroll or optimize code, color registers, eliminate dead code, perform keyhole optimization, etc.?
A standard analogy is that assemblers are akin to transliteration of text, while compilers are akin to translation of text. Unless your lawyers are incompetent, they'll assure you that translators *always* have a copyright on the translated text.
(Historical sidenote: sometimes the translator's rights can exceed the original authors! In the 30's someone published an honest translation of _Mein Kampf_ and Hitler sued to cease publication. For some odd reason he wanted English speakers to see only a gutted version of his ravings.
Even if we posit that all of this work is unworthy of protection, there's the pesky fact that compilers rarely stand alone. Even if *your* code is unencumbered, you're gonna link it to startup code, standard libraries, etc.
Finally, your argument seems to come down to the compiler company's lawyers writing licenses that benefit the consumer. This is an... interesting idea. In the real world I doubt any of these lawyers would lose sleep over the fact that, *oops*, they forgot to include that clause and the customer needs to send in a check to get a license to distribute their own product. The major customers will always negotiate their own license terms (instead of being forced to accept the offered one or get lost) and I'm sure *those* licenses included the right to redistributed derived work.
(P.S., any usable text editor or word processor should give you back exactly what you put into it, so copyright law is not an issue. However, if you print to a file look at it carefully - you'll probably find a copyright notice in generated PS, PDF, or any other format that allows comments.)
Re:Open source not good for small companies (Score:2)
Nope, he covers that as well in one of the later papers - see Th e Magic Cauldron [tuxedo.org] for an example of when NOT to open source something.
--
Mass-market busking is the answer. (Score:2)
The theory behind it is that groups which pay more will have more buskers trying to please them and get their money, so there is a direct benefit for paying.
It makes the whole process open and honest. You can tell people "I want your money" because the only way you're going to get it is by making something they like well enough to pay for after having tried it. "I want your money" becomes equivalent to "I want to do something which benefits you", because you can't get their money by tricking them into paying for a bad product sight-unseen or slipping in bugs and making them pay for the fixes later.
Paying is effectively saying "I appreciate your work, and I want you to continue with it, but I'm also willing to make similar payments to others who do useful work for me". Instead of hearing about a great company going out of business and thinking "too bad, I wish they could have found some way to force us to pay them the money they needed, I guess they just had a bad revenue model" you can think "hmm, I value their services, how much am I willing to spend to keep them going?".
I think a lot more people will pay if it's okay for them to pay $20 or $5 or $0.50, instead of paying $50 or nothing. I think this article from the mushroom [themushroom.com] makes my point fairly well. And, of course, it makes sense to pay more than once, depending on how long you use the product.
It is efficient, because there are no middle-men involved. Product goes directly to customers, payment goes directly to producers. Forget advertising costs, the customers seek out worthwhile free stuff and tell their friends about it. No distributors, no salesmen, just programmers, artists, writers, and other creative people. It will probably only cost about a third, and in many cases less, to make and release products of the same quality.
And, of course, it allows you to open-source your product. The users will make it their business to pay only those people who are really responsible for the development, so anyone who puts a stupid little wrapper around your product might get a small amount of payment appropriate to his own effort, but generally won't manage to usurp the rewards for the bulk of the work.
Right now, there are two good services for buskware payments: e-gold [e-gold.com] and paypal [paypal.com]. Paypal is extremely easy to use but only available to Americans; e-gold is less efficient, but internationally available (and, being a gold exchange rather than a dollar exchange, is more suitable for international trade). Both allow all accounts to both give and receive. They are compatible, because you can buy e-gold with paypal, and then send it out of the country, very simply.
Yes, it will probably take some time for everyone to come around, and get used to paying for some future benefit, rather than to access things they would otherwise be cut off from, but somebody's got to start it.
Nonsense. Selling copies is perfectly valid. (Score:3)
You don't need to license software you sell.
You don't need to license software you sell.
You don't need to license software you sell.
If you own the copyright, and don't give out any licenses, only you can make copies. Copyright law allows certain uses by anyone who buys a copy of software: installing it, running it, and making a backup. Very simple. No need to involve vicious packs of lawyers who piss off your customers and chew your profit margin to bits.
The standard practice of shrink-wrap licences is both unnecessary and legally questionable. Go ask a lawyer and he'll tell you that you should pay him more, every time, as long as he thinks you can make the payments (here's a hint: they ain't in it for the satisfaction of helping their fellow man). That's why everyone ends up with license who asks a lawyer, not because it's in their interest to have one, but because it's in the lawyer's interest to tell you to pay him for one.
Study the damned law yourself! Trust lawyers to tell you how much you should spend on lawyers, and you'll end up watching them suck you dry. (definitely don't trust me to tell you what to do. go check it out yourself. I could be lying, but I'm only telling you things you can easily check yourself)
Re:Suits are overrated. (Score:2)
And it works great until all your smart employees quit, or rise up against you and crucify you against a cubicle wall.
Discipline and a clear delimitation of duties are vital, but the respect and well being of employees cannot be abandoned in the quest for the bottom line, or else all gains will be very short term.
As far as the fashion issue goes, I can only sneer at my fellow employees who wear unwashed T-shirts that they got for free with their dirty jeans and sandals. It's ok to dress decently and have taste.
Only works for libraries (Score:2)
If your product is a program and is open source, then you cannot prevent its free use in for profit applications.
Re:Open Source and Guilt (Score:2)
Re:Open Source may be nice, but GPL won't work. (Score:2)
PS, the GPL does not allow another company to take your R&D and resell your product out from under you; you're mistaking licensing for Copyright.
The license may allow them to use modify your code, but not to copy it without credit -- which gives your company what it needs to say "our product being sold by 4 competitors -- get your support from the people who created it"
... I can name a lot of companies who buy MS support directly from Microsoft instead of independant MSCE-based companies for that reason.
Note: I hope your product doesn't require as much support as MS's do
Re:Apache is a bad example (Score:2)
Sorry, I don't buy that. Apache was a great free software success before Sun and IBM leapt aboard -- indeed, it was Apache's ubiquity that led IBM to go with Apache rather than continue developing their own proprietary http server.
Yes, Apache would lack some key functionality without IBM/Sun's input, but without them, someone else would have done it.
--
Not shareware. (Score:2)
I suspect that pretty much everyone who uses the software wouldn't care about parting with a quarter or fifty cents, and most would give several dollars for a product they use often. Wealthy individuals or companies would likely be willing to pay a lot to get special attention paid to their bug/wish lists (look, here's a wad of cash, there's more where that came from if you make these changes).
There's pretty much nothing to make people pay for any software. The risk of being caught and punished is virtually nonexistant. Copying is easy and cheap.
Those who pay do so because they believe that it would be wrong not to, ultimately because if everybody did it, the products wouldn't exist. I believe that if you give people more freedom and control in this process, they will respond appropriately, and protect their own interests.
The penalty for not paying (or paying too little) is: being ignored by the mass-market buskers when they choose what to make. Broad appeal isn't always necessary, appeal to a profitable market is.
Mass-market busking is not appropriate for non-reproducable products and services, for obvious reasons. Things like HTML text, computer programs, and recorded music are special products that have unlimited supply once created. The only influence the user needs is over what is produced, and they could gain this influence by rewarding (with donations) the behavior which benefits them, effectivly training the system to serve them.