Slashdot Mirror
Developers Lose With Proprietary Software
An anonymous reader writes "Appgen looked like a nice cross-platform accounting program independent software developers could use as a base for custom applications, and lots of them paid $2000 or more for the company's development kits. Then Appgen went out of business and left all those developers stranded. They can't even generate license keys, and their support has disappeared. Nobody knows who now owns Appgen's code, so it looks like all those developers and their clients are screwed. This couldn't happen if Appgen was Open Source. There's a strong lesson in this story for those who choose to listen." Newsforge and Slashdot are both part of OSDN.
Don't be a Sharecropper.
Save your wrists today - switch to Dvorak
sPh
We gave our source to our paying customers when we decided to drop the product and switch directions.
Everyone seemed pleased with the arrangement, even though I doubt they were pleased when they got the gazillion lines of C++ code without support.
And to think my idea of going open source was ridiculed by management 6 months before we flamed out.
Sheesh...
The place where I work used a proprietary closed source library for Borland C++ Builder. The project was developed 5 years ago and the library was purchased from some vendor whose name I forgot.
When faced with updates to the version 2.0, we found out the vendor went bankrupt. Luckily, they open-sourced the libraries and just put them up on SourceForge. I didn't really use their source code, just was thankful the libraries were there andfit the project under Borland C++.
This is a ripe story for a weblog which covers .net more than any other framework. Funny how no-one ever questions whether the .net we've been getting told to learn or face certain doom might be canned and never heard from again by its owner.
For those looking for insight on this might look here:
http://www.aaxnet.com/product/appgn.html
--------------
10-Oct-03 - the Appgen company has closed - the Appgen product is expected to continue. There are groups currently working on acquiring rights to license the product and this issue should be resolved soon. Nothing is yet resolved about terms, pricing or VAR support.
18-Oct-03 - people are still working to put together a deal, but the process has apparently been stalled a bit by the volume of badmouthing and threats (legal and physical) against those who were involved with the Appgen company. Cooperation would seem to be a much better tactic right now.
You may contact me by email at aax@aaxnet.com and I will keep you updated on whatever I learn about this matter.- or just watch this space
For people with licensing problems with Mybooks purchased directly from Appgen, this temporary solution has been proposed by an Appgen VAR.
continued...
#1 - serious question - how many serious accounting packages are being worked on in the open-source world? It's exactly the kind of software hackers usually denigrate...
:)
#2 - I think this is as much about poor planning (contract negotiations on the part of the developers, defining and/or selling and/or making a "will" for the software on the part of the owners) as it is about IP. And I'll bet somebody knows who owns it, they just haven't settled it yet.
#3 - How many abandoned Open Source apps are there? I mean, sure, you won't have the key problem, but still. The grass may be greener, but it isn't self-mowing, self-watering, and immortal!
Obligatory Criticism from Merovign.
1. Modify an open source software package to fit a niche market
2. Sell installations, manuals, customization service, and support to that market
3. Profit!
Unfortunately I haven't seen many Open Source businesses manage to achieve point 3.
I'm sure everyone can mention a few that have done so (Redhat and Cygwin spring to mind) but there are vastly more that have either fallen by the wayside or are resorting to begging for money (Mandrake?).
Open Source is great, but it too isn't perfect ...
Avantslash - View Slashdot cleanly on your mobile phone.
There seems to be a working Appgen web site here, although the for-pay downloads aren't working.
This post expresses my opinion, not that of my employer. And yes, IAAL.
Er.... the Java programming language is a specification, and an open one at that (IIRC). If Sun went under, IBM still has a kick-ass VM and SDK. And a great IDE in Eclipse, too. If Sun went under, Java would continue unabated; it's a programming language, not a library or modifiable application.
From the article it seems to me that Appgen (which I'm not familiar with) is either an IDE/Library/ProprietaryLanguage, or a full-blown application that developers can modify for their own use. It's a far cry from Java.
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
It probably would cause a shake up but with java there are several eggs in different baskets. What would perl do without Larry Wall? They would get over it and move on. Besides Sun is more likely to be an aquisition target than it is to flame out.
In Republican America phones tap you.
It's called bad business practices and a risk everyone takes whenever they buy anything and do not research what they are buying and who they are buying it from.
The real tip-off in the article is the fact they did the same thing with a previous program...I can't feel too much sympathy with individuals or companies doing business with a company but not doing a through check of who they are doing business with.
"Learning is fun!" - Bender, Futurama. If you know this quote, you know that these people just learned an important lesson.
"Code Escrow"
If I am going to purchase components or make a decision to commit, I make sure that there is some sort of safety-net just in case the company fails. Often this comes in the form of a code escrow service. Every X days, the company ships off a copy of all their code to the service. If the company fails or there is a serious event, the escrow company releases the code.
As a small developer that is a large expense, so for my customers, they already have the contact info for my off-site backup person. If anything happens to me, that person is instructed to freely distribute all source code. It is someone I trust.
Or you could use your attorney.
Off-site backups are a Good Thing(TM), and it only takes one extra small step to ensure that, should you perish, your work isn't left inaccessible. Whether that means a closed-source app or just your notes on an open source project.
Natural != (nontoxic || beneficial)
If it was open source and GPLed then you wouldn't be able to use the code in your own commercial product.
Isn't this the problem that the LGPL is designed to solve?
#1 - serious question - how many serious accounting packages are being worked on in the open-source world? It's exactly the kind of software hackers usually denigrate...
In my analysis, it isn't that open-source developers don't want to work on this sort of thing, it's that there is a certain amount of infrastructure that needs to be in place before projects like this can proceed. Several enterprise-class accounting projects have been started, but few finish; it's because the tools aren't in place yet.
The FOSS community doesn't avoid doing corporate-type projects, as a lot of people claim. FOSS software is written because it is positioned properly to fullfill a need. Until very recently, FOSS was not accepted in the enterprise. Now, as more and more corporations are depending on various FOSS software, you will see many projects targetting medium-to-large corporations.
For instance, look at the relatively-new GNU Enterprise project. This is a major undertaking which has begun by creating the tools required to build an enterprise management infrastructure.
As FOSS software penetrates various markets, you will see many FOSS projects building finance/hr/materials-management/analysis tools. I predict that 2004 will be the year of the enterprise for FOSS (Linux,*BSD,GNU). You'll see prepackaged medical management software, ERP software, etc. By the end of 2005 I believe you will see a complete enterprise management system, from supply chain to finance to HR to payroll.
But maybe I'm just a pollyanna.
Microsoft is to software what Budweiser is to beer.
Not only will reinstalling a computer takes AGES due to all the products you need to activate (and heaven forbid you changed some hardware - time to call them all up one-by-one and plead your case), but you won't even be able to install any package from a software company who has gone belly up.
When companies sell closed source solutions that other companies build on top of and come to be dependent on it's true there's big risks. The solution that seems to be suggested here is to build on open source projects. The problem: good luck finding a good, well documented, open source accounting system. Another solution is code escrow. Before you buy into a system like that make sure the vendor puts the source somewhere where the customers can get it if they fold and grants them the right to do so. There's several companies that provide services like this and if software consumers start insisting on it we can see problems like this become less frequent in the future. Even for closed source projects.
Meet gcj, smart guy.
There are no trails. There are no trees out here.
ugh.. as nice as it would be to say proprietary software is bad, these are the results. That just is not the case.
/. analogy, when I buy a ford car, I have no guarantee that I'll be supported after ford goes out of business.
Proprietary software failed in this case because the people using it (stupidly) paid a lot of money for software that had no contingency plan or guarantee.
To use a popular
When you pay a lot of money for something with no service guarantee of any kind, stuff like this happens. Sure using OSS may have helped with this problem, but OSS has a whole slew of other problems.
If its merely a license key issue, I'm sure these "developers" could get around that. Judging by the number of keygen programs for other software packages that come out the same day a program is released, this is a non-issue.
They still would go out of business, they just wouldn't screw their customers in the process.
Yes, the lesson is: don't buy a propriatary app without a 3rd party source-code escrow agreement. That was figured out around 1965.
So, you have a contract that specifies software escrow. And when the company goes bankrupt and you find the source is not in escrow (or not all of the source is in escrow, or there is third-party IP in the escrowed source, or ...):
who are you going to sue?
An escrow agreement is likely to be enforceable right up until the moment you need it.
The difference with open source is that you have the source in hand now and so if the company disappears you don't have to sue a non-existant entity to get the code.
One reportedly paid $10,000 to have Appgen ported to "SCO and UnixWare" in September, only weeks before the company went away.
And now, Appgen dissapeared too!
That's okay. Those VARs can now approach whoever acquires the code, and show it to them, and say "give me the source or I'll sue you into oblivion" - That escrow agreement is a legally binding agreement, right? Any agreements are transferred along with the software.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Everyone has the source to Java. Well enough other people that it wouldn't matter if Sun went away. IBM has their own Java VM and Compiler (The rules for looking at Sun's code inside IBM are very strict.) The Blackdown people are allowed to compile it for Linux although I don't know the details of their source code license.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
But this has already been covered once WRT Java, which is precisely the same thing. Java and .NET are both open specifications. There are a couple replacements for each (Java: IBM JDK, gcj; .NET: Mono, DotGnu) so if one of them should drop off the face of the earth there is a free and open source replacement.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Lol, I'd be willing to bet if Sun went under there would be some major difficulties in the industry.
How much money are you willing to lose on that bet?
There are plenty of free or open source and third party sources for Java compilers, JVMs, bytecode compilers, class libraries and related apps.
Sun could disappear tomorrow and Java would continue.
-- Alastair
Even if you cannot afford the developer effort needed to completely take over a dead project OSS still gives you some additional options:
1. Work with other stranded customers/users to share the cost of development.
2. Hire just a single developer to handle immediate problems and buy some time.
3. Find a replacement OSS project and pay one of the developers a months wages to create a conversion tool for your data.
I am sure there are those in the mega-corp world would see this as an example why you need to use Microsoft,Oracle, etc. because going with a smaller startup company could leave you stranded. Just a thought.
A "written escrow agreement" is meaningless unless there is actually a third-party escrow trustee involved from the beginning. This is what escrowing is. (See http://dictionary.reference.com/search?q=escrow)
The VARs and SIs should have known better.
--Slashdot: News for Turds. Stuff that Splatters.
Moneydance, a pretty good pfm written in java was acquired by Appgen some time back. They may have seen it as a competitor. It was released to its original author and was reborn as Moneydance 2003 in June of this year. It is supported and for sale. It is lucky to have survived, Appgen had stopped supporting it, and it all but vanished.
Get a free ipod.
Someone needs a hug .
The paradigm where things start and end free just means developers never get paid.
My last job paid for writing and supporting Free Software because that's what the company did (and does -- they're still around, and I understand in better financial shape now than when I left). My current job is at a company that writes proprietary software -- but we use Free Software to do it, so when we need a bugfix or an extension, my present employer, a proprietary software company, still pays me to work on Free Software.
My employer before the last two was a car dealership; they hired me as a contractor to move their base platform to Free Software. Before that I spent some time helping a school district set up some servers running on (you guessed it) Free Software. Same kind of business: They hit a bug or need a feature, I'm the guy to write it. (Not that either of those two *did* hit bugs or missing features, but the capability was one of the things they got when they hired me).
This myth that folks never get paid for working on Free Software is just that -- a myth -- and needs to die.
My assessment of open source is that it is, at its core, a software development methodology; one that is closely related to methodology of science.
Now, if this assessment is even half accurate, it would be quite absurd to blame the failure of a certain business model to the development methodology it favoured above others. In fact, methodologies cannot themselves be attributed any value; they may, at most, have different degrees of fitness for a particular purpose.
I think labeling a certain business model or a company as "open-source" is not only incorrect - it causes a lot of unneeded confusion. It is easy to get the impression that when an "open-source" company fails, it is a blow to the whole "open-source community", when this clearly cannot be the case when we view open source as a development methodology.
I know that Eric Raymond, Bruce Perens and others have done a lot of work to make us think warm, fuzzy, positive thoughts when hearing the words "open source", and I understand their reasons for doing it. However, one of the drawbacks of using that kind of tactics is that we will continue to see "open source" applied where it does not belong, taking blame where there is none to be taken.
A monk asked Joshu, "Does this company have the open-source nature?" Joshu retorted, "Mu!"
For software escrow to really work, the escrow company has to be in between the developer and the end user. Whenever the developer wants to ship a new release, the escrow company should check it out of the source code control, build it themselves, and they should ship the binaries to the customers. This is the only way to ensure that the binaries the customers run are fully covered by escrow. But no one does that -- it is too expensive.
A proprietary software company goes out of business and screws its' customers along the way.
Thus, proprietary software is by nature a bad thing. AND, by the linked story's own formula, you're more likely to profit by going with open source.
This is simply foolish. If all proprietary companies did this, then yes, you could draw this conclusion. But this was one (very badly run) company, and a small one at that. Small businesses close their doors all the time, sometimes leaving their customers high and dry. You think Appgen is the only one that's ever done this?
How about all of the software companies that have suceeded? How about all of the companies that have supported their customers in good times and bad? For God's sake, IBM supported OS/2 for years, even when it was clear that few people were using it. There are hundreds of other examples I could give of software companies doing the RIGHT thing.
Open Source is a software development model and philosophy.You can argue that it's a morally superior way of business, but not a more profitable one.
And even if Appgen's code was open, that still doesn't get their customers off the hook. Where will those customers go for support? The VARs? There's only so much they can do. Even if the app was turned into a large coordinated open source project, it would still take time to assemble the proper volunteers and get the app back on track. And the customers are STILL screwed out of paid support.
I have to agree with some other posters here. Mod the article -1 GNU/Preachy.
Life is hard, and the world is cruel
It's a better situation than most proprietary situations where you don't have any access to the source code whatsoever.
The customers don'thave to do free R support is part of their paid contract. The modification stuff is just a clause in the license in case they do decide to do any modifications themselves. Normally they'd request features from the developing company.
Of course the customer isn't allowed to give the modified code (since it's still a derivative of the original company's code, which they still own) to other people. You can't buy a DVD, make copies, and hand those out to anyone and everyone either.
Since most customers aren't going to waste their time making modifications to code they don't wholly own, this isn't a sweet deal for the original company; it's an added bonus for the customer in case they want to see the source, or (especially) if the original company folds. This is the big reason everyone on here is yelling about how using open-source software would have avoided this situation in the first place.
Next time some one talks about how it is better to buy proprietary solutions because of better 'support' point out that the following;
of all the technologies traded in th NYSE in the early 1970s, only IBM is left.
Sperry - gone.
Burroughs - gone.
DataGeneral - gone.
CDC - gone.
The list goes on. Thier proprietary solutions by and large are dead. DEC merged with Compaq which got bought out by HP and now the Alpha and VMS are orphans.
HP is in a death spiral.
MS is a new kid on the block (Burroughs for example was around for 50 years or more), and so should be regarded as shaky.
Other companies made forays into computing but pulled the plug in the 60's and 70's. Technology is a VERY volatile industry, the only way to really cover yourself is by getting the source code.
putting the 'B' in LGBTQ+
Why do you think businesses exist? If you walk into a marketing meeting of any business of a relatively large size, what is the key word you hear: Market Share. And what is market share? A partial monopoly which gives the company partial control over the market price of something.
.
What if there was an industry that prevented anyone from gaining a lot of market share. What would it look like? Such industries DO exist:
Doctore
Lawyers
Accountants
Plumbers
etc . .
There are exceptions to each of these examples (HR Block, Large auditing firms, Large law firms), but the great MAJORITY of these professionals make their living as PRIVATE entities, which means you'll never know how profitable they are.
These professionals can't gain market share because, though it takes time and money, the barriers of market are far, far less than, say, competing with MS on THEIR platform. Hence, when standards are OPEN, competition increases and the needs for financial leverage decrease as a result of smaller barriers to market.
So, your observation of just a view PUBLICLY OWNED (or business large enough for you to note their existence) entities making profits from OSS are correct. However, your inability to observe the earnings of PRIVATELY OWNED entities (or individuals who can live comfortable with just a dozen clients) using and creating OSS is not reason enough to come to the conclusion that OSS is flawed in the area of profitability. Our current system is simply limitted to requiring only public entities to publicly release their earnings and the majority of those benefitting by writing OSS are too small for you to even take notice.
Sdelat' Ameriku velikoy Snova!
As a prior post points out, you can still sell licenses. Open source != non-proprietary (though even I tend to muddle it up at times).
As an example, I used to work in a OS390/COBOL/IDMS system for a large institution. When I was hired on I signed an NDA which covered not only thier internal IP but also that of their vendors and clients. We go the source code from our vendors (usually COBOL/JCL, but just before I left they were 'webifying' the mainframe using a vendor provided system running C/Perl/Cobol/JCL and also got a source code license).
It worked like this:
1) Vendor dlivers source code with install 'scripts' (JCL).
2) Maintenence programmers install system, customized to their installation.
3) If company decides they need a modification (mod), they can FREELY modify the source.
4) Unless the vendor accepts the mods, the mods are supported by maintenence programmers.
5) If the vendor accepts the mods, they take over the support of the mod.
6) If the mod is supported by the vendor, the vendor releases to ALL thier clients, often giving the institution which developed the mod free training classes, discounts on licensing etc.
7) If the user finds a problem, they are free to debug. Often programmers from several institutions would cooperate and find and fix bugs fast.
8) Vendor would check the patch before releasing as a supported fix, making any mods on thier end as needed.
I have come to believe this to be a VERY powerful business model. Instead of a confrontational business model (e.g MS) it is COOPERATIVE. The clients got what they wanted (usable/stable software) and the vendor made money.
putting the 'B' in LGBTQ+
A couple interesting stories from our past and our present along these lines:
The 1960 and 1970 US Census tract level data (tract level means a subdivision of a county) are available only in a proprietary compressed format. This is because the US Government hired a programming firm (Dualabs) to write a compression scheme to be used on this census data. Dualabs wrote the program, compressed the data, and distributed the decompressor program. Census data archivists around the country only got the compressed version of the data. The US Government never made it a point to get the complete corresponding source code to that decompressor program, nor did they get a license to share and modify the program (which would have required source code to do well). The computers people initally used with the decompressor program became outmoded and the decompressor program only ran on that obsolete platform.
Dualabs went out of business in 1974. Therefore, we, the public, paid for Census data we cannot completely read even to this day without reverse engineering the compressed data format. Census data is unarguably important and few people know about this lack of foresight on the part of the US Government and Dualabs. This story has many lessons, most of which still have not been learned.
Recently the University of Illinois at Urbana-Champaign switched from using 5 web-based programs to do class-related stuff online (display student's grades, allow students to receive class material, discuss class projects with each other, etc.). Not long ago, UIUC dropped support for all of these programs and began supporting only Illinois Compass ("powered by WebCT Vista", as the program's proprietors tell us). Illinois Compass is non-free software and costs UIUC one million dollars a year (which UIUC is paying).
UIUC is widely known for having talented software programmers and a highly regarded college of engineering. For orders of magnitude less than $1M/yr UIUC could have paid a few students to leverage the huge pool of capable, tested, and time-honored Free Software out there in order to make a web-based bulletin board system to replace the 5 programs UIUC dropped support for. Now, with Illinois Compass, UIUC pays a team of local support staff (on top of the $1M/yr program fee) to support the new program. UIUC has no source code for Illinois Compass (let alone a license allowing them to share and modify the program). So now UIUC risks running into the same problem the US Government ran into should the proprietor's support for Illinois Compass disappear.
Sometimes these lessons take a long time to learn and cost the public a lot of money.
Digital Citizen
Our supplier companies have been bought out, dropped production, decided that just stopping and giving us source was more cost effective than making all the fixes our contract demanded, etc.
Due to the enormous length of our software development life cycle (10+ years!) we end up supporting a LOT of CAS.
And we do it by buying the source.
In the future, I would want to not be isolated from my friends in the Space Station.
So why don't some of the biggest VAR's just get in contact with eachother with a posting in some Appgen mailing list and form a holding company. They each buy equal shares in the company and use the resulting money to bid for the AppGen intellectual assets. All of the shareholder VARs in the new company get a copy of the source code including the key generator. They then sell shares to any smaller VARs that also want a copy of the source/key generator and redistribute the share income back to the shareholders as quarterly dividends. As the number of new shareholders increases, the cost of a share drops. Eventually you'll spend more money operating the shell company than you will get back in new purchases so you just close the company and six months later release the source generally as open source (make it part of the corporate charter, with source escrow this time of course).
What I don't understand in all this is why some people are saying that there are ego issues in the negotiations. Why would any of the AppGen executives (with egos on the line) still have any say in this? If the company is no longer operating, shouldn't there be an independent (court-appointed?) receiver handling all this? If the old executive and directors are still involved and causing problems, then include them in a class action lawsuit against the company for breach of contract and see if they smarten up. If a receiver is handling the liquidation, then the receiver should be open to a reasonable offer.
Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire