Weekly Edition
Return to the Press page
| |||||||||||||
How To Successfully Compete With Open Source Software (MicroISV)
The MicroISV blog has some interesting thoughts on competing with open source. The author makes a closed-source application for teachers and the article looks at six areas where proprietary applications can better their open source competition. While his focus is on proprietary application developers, there is much for open source developers to consider. "However, relatively few people in the discussion mentioned B2C (Business To Consumer you know, the stuff that isnt paid for by an expense account) software, which people often tell me is doomed, doomed, doomed. Seeing as how I run a small B2C software business, and am experiencing a crushing shortage of doom, I thought I would explain why this is possible." (thanks to Patrick Spinler).
(Log in to post comments)
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 9, 2009 15:36 UTC (Mon) by pharm (guest, #22305) [Link] His comments about Sourceforge are spot on. Almost uniquely amongst the websites I use on a semi-regular basis, sourceforge has got worse rather than better from an end-user POV over the years. My base presumption is that sourceforge (and all the other clones) are very narrowly focused on supporting software development. Which is absolutely fine, until the programmers who use it rely on it for deployment as well, at which SF fails miserably, unless the necessary work is put into the project home page to make it easy for end-users to get hold of the software.
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 9, 2009 15:39 UTC (Mon) by boudewijn (subscriber, #14185) [Link]
Oh yes, it's come to a point where I dread having to get something from sourceforge because,
despite being a software developer with the appropriately warped mind and all that, I never can find anything -- I always find myself clicking around like a wild animal trying to get to the cvs or svn tree or the downloads.
And the bug tracker or mailing lists interface...
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 9, 2009 16:13 UTC (Mon) by kirkengaard (subscriber, #15022) [Link]
Blessed are the developers that incorporate direct links on their site, allowing you to bypass the Sourceforge full, versioned download listing and get the file you want. From a standpoint of the geek who wants to know what the most up-to-date item is, and how it got there, I like the versioned download page -- provided the developers involved have done their users the service of placing that information in the accessible spots.
He could as well have titled this article "how to compete with other projects in your niche market on the basis of user appeal." All coders know what an algorithm is, but not as many remember that users don't express their algorithms -- they just want to generate a solution to a problem. Software that helps the user efficiently generate solutions to problems fits best into the algorithmic chain. "Be a good, unobtrusive, efficient, and appealing tool, market yourself well, and listen to your users, and you can beat the other projects in your niche." The "better than OSS" part seems to just be related to the ability to use things that aren't GPL-friendly, but provide a competitive edge over the Free alternatives.
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 9, 2009 17:10 UTC (Mon) by epa (subscriber, #39769) [Link]
I think he is confusing the intended audience of the sites. Places like Sourceforge are not *intended* for grandma downloading software. The project description is not *meant* to be intelligible to nontechnical people. Rather, these exist for the benefit of other developers and for packagers, who can take the software, integrate it into a user-friendly distribution like Ubuntu or RHEL, and (for a fee) offer handholding and support to users.
The faults with the system are that not enough people are providing this service - even the friendliest Linux distributions are still pretty geeky - and that the distribution becomes something of a choke point for getting software to the user, because setting up alternative package repositories and pointing users to them is too hard. And although people are often happy to pay for proprietary software, and companies will pay for support services, nobody has yet found a way to get individual end users to pay for support, so there is little economic incentive to put in the hard work needed to polish an application for distribution and spend time answering phone calls.
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 9, 2009 17:47 UTC (Mon) by drag (subscriber, #31333) [Link]
The package management system can't be the answer for everything.
The problems you run into is that for many applications have a very specific purpose that are not packaged by the distributions.
So like his example.. he makes a application that makes 'bingo' cards for keeping track of students. Before he started there were 2 competing open source applications.
Question: Which one of those was provided by package makers for distributions?
Answer: none.
So it doesn't matter if sourceforge is intended to be for developers... people that have real needs to fill can't always get what they want by default. This is true that this is sourceforge is for.. but it's not really working that well.
There are hundreds of programs like that that are not provided for by distribution makers, but people want to evaluate and use.
----------------------------------------
The problem we face here is that distributions have it backwards.
Instead of packaging software themselves and then only worrying about their own distribution... packages should be created upstream by the original developers. Then distributions should take those packages and figure out how to integrate them, pushing any needed changes back upstream.
Istead of:
it should be:
then those packages are provided to end users through the distributions. Of course not all software can work that way, for example core "linux plumbing" stuff will have to be done by distributions.
For popular packages they should probably be provided for by the defautl distribution package tools, but for other software that the distribution makers are not aware of or lack the manpower to manage themselves then users can still have the option of installing software from www downloads.
Doing it this way will lead to a lot better integration between distributions, better bug tracking, better usability, and much wider amount of easy-to-install software.
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 9, 2009 18:46 UTC (Mon) by tzafrir (subscriber, #11501) [Link]
So you're saying that a programmer not only needs to know how to write good code, but also needs to know how to mess with those wirdows of Debian, Fedora, OpenSUSE, Ubuntu, Gentoo, FreeBSD, and the lot?
Even Mozilla are hardly able to deal with that. And you want to inflict such a problem on each and every project?
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 9, 2009 19:22 UTC (Mon) by drag (subscriber, #31333) [Link]
No I would like to see distributions learn to work together. Also I would like to see build tools provide packages as part of the final product, not just binaries.
Package management tools and package format is essentially a solved issue for people like Debian or Fedora. Sure there are always to improve stuff, but for the most part people are not going to run into dependency issues and the like.
So you have apt-get vs yum, deb packages vs rpm. Both of them do essentially the same thing and require the same sort of information from the people who build the binaries. What are the dependencies, acceptable library versions, licensing, documentation, etc. Having both is a waste of time, waste of effort. One can do the job just fine and it's just a accident of history that we need muiltiple different distro-specific tools to do the same exact thing.
So what is required is a simply a standard way for build tools to provide that information to distribution's package management tools.
And as far as build binaries and figuring out dependencies the people working with projects are going to be much more knowledgable about the issues with various library versions and tested configurations and whatnot.
> Even Mozilla are hardly able to deal with that. And you want to inflict such a problem on each and every project?
It's much better that developers do it then end users; which is the way it's done now for anything that is not provided ready-made by distributions. Having distribution makers do all the work packaging software is a half-solution.
Even people working in distributions will have a weaker sense then the developers what are the requirements and prefered dependencies then the original developers. End users generally are the weakest and have no clue on how to build or run the software so they stumble through it, trying to follow the any sort of documentation (if it exists), and hope for the best to avoid any pitfalls and incompatibilities.
It's not scalable, it's not distributed. Each distribution has to re-do all the work every single other distribution has already done. Waste of time, waste of effort.
So the best thing to do, I figure, is work on migrating from distribution-specific package management systems to a standard package format that distributions can integrate into their native systems.
(if it was up to me I'd just pick RPMs, or a improved version. It's already supported by all the major distributions (including Debian and Ubuntu))
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 9, 2009 20:41 UTC (Mon) by tzafrir (subscriber, #11501) [Link]
There is much more in packaging than the package format. Making it possible for packages to play along with each other is a complicated task.
I've seen many saying it is simple. And very little actual proof that it is indeed simple. Do prove me wrong.
In the mean while I won't waste my time on such promises.
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 9, 2009 21:53 UTC (Mon) by drag (subscriber, #31333) [Link]
I never said it was simple.
I expect that it would be exceptionally difficult and the transission, even if everybody was committed, would take years.
One of the big requirements is that distributions would start to have to give a flying f**k about binary compatibility, and compatibility with other distributions, for once.
Like I said the current model is very labor intensive, each distribution has to re-do all the work that other distributions have already done, and results in programs that are not being picked up by distributions in a lurch and they only exist as second class citizens.
It simply isn't correct and does not make any sense. ALL distributions are using all the same code for it's libraries, for X, for Linux, for everything. It's all based on the same code, yet relatively minor decisions yeild large incompatibilities and cause endless headaches for end users. It's the wrong direction to expect that each distribution should repackage the entire world's software requirements every release.
Does it really make sense?
It could work if there was only one distribution or only one distribution worth caring about, but each major distribution actually has a reason for existance as far as I can tell.
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 10, 2009 5:33 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
Binary compatibility? Now that is nice.
Distributions care very much about binary compatibilities and ABIs.
However would you suggest that, say, Fedora 11 should be binary compatible to Fedora 10?
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 10, 2009 9:05 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
I would just like to add a few comments drawn from personal experience to this thread. First of all, it is feasible to produce packages for a wide range of distributions for a piece of third party software. It turns out that on the whole (things aren't quite this simple, but close to it) the various scripts required for packaging can be split into two parts: a set of application-specific scripts shared between the different distribution packages, and a set of distribution-specific scripts which are not specific to the application. (As I said, there is a bit more too it that that, but not very much). I am speaking about software which is somewhat more complex than bingo cards, but still does not have the horribly complex dependencies that the low-level system bits do (the ones which probably really are hard to package). It would not be hard (perhaps I will do it some day) to develop a generic packing kit which does most of the work for you. What would even nicer, would be if the distribution packaging specialists would work directly with the upstream authors to make sure that the upstream packages fit in with their distributions requirements out of the box.
Binary compatibility accross distributions is also not to hard, once you know what to watch out for. The main trick is to build on a sufficiently old distribution, and to know (and avoid) things that are likely to cause problems (the autopackage people have researched that very nicely, even if their packaging tools aren't to everyone's taste). Of course, a binary package which works accross a range of distributions (producing one which works with all Debians and Ubuntus and one for all Fedoras and SUSEs is also doable) would not be likely to be accepted into the distribution as is, but you can provide source packages too, which can be automatically rebuilt and added.
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 10, 2009 22:29 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
So, what about Fedora 10 and Fedora 11?
Old enough? Fedora 8 is no longer supported (or is it 7?)
So what can I target what I package for Fedora?
When you package inside a distribution you don't create a huge package with tons of statically-linked libraries (just because you can't assume they were in RHEL4)
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 11, 2009 13:26 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
The standard argument against distribution-like packaging is that efforts are massively duplicated. Oh, wouldn't it be nice if it was done once in one place (either by app developers themselves, or by a single lobby-able entity).
What people do not realise is that all packages are not equal. Some can be created in 10 mins and others take months of work.
Usually, the second category, which is the actual resource-intensive time-waster, is composed of material released by the people criticising the distribution model and making the "duplicate effort" arguments. They have problems getting distributed because their releases (in plain words) suck. It's much easier for them to blame distros that won't relax their quality standards and take ages to try to get something to build properly than publishing something that just builds in the first place.
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 10, 2009 22:29 UTC (Tue) by whitemice (guest, #3748) [Link]
>No I would like to see distributions learn to work together. Also I would
>like to see build tools provide packages as part of the final product, not >just binaries.
That is the openSUSE (Novell) build service; and there are hundreds of projects there. It makes packaging much simpler than doing it "by hand" and has support for a wide collection of distributions.
>So the best thing to do, I figure, is work on migrating from distribution-
Your basically down to two: RPM & DEB. That covers all the people who matter [I'm happy to exclude crazy fringy people using things like Gentoo]. Between distributions the difference are really small, albeit annoying, like locating configuration files and the names of dependencies.
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 11, 2009 6:05 UTC (Wed) by tzafrir (subscriber, #11501) [Link]
The build service is a build service. A build system. But it still does not make the packages magically compatible to other distributions. And last time I heard, Gentoo does not use rpm or deb.
Likewise, what Mandriva expects of an RPM package is not exactly the same as what Fedora expects it and not exactly the same as what OpenSUSE expects it.
One example: please show me an init.d script that can be used across distributions and also complies with the policy regarding printing output? It seems that when the standard for init.d scripts was created, printing to the console was not such an issue. So will you stick with the old standard?
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 11, 2009 9:46 UTC (Wed) by boudewijn (subscriber, #14185) [Link]
The build service can currently build packages compatible with:
* SUSE
From their website... Looks pretty magically comprehensive to me. And, Gentoo is of course completely irrelevant to this discussion: it's by definition not a distribution you want to provide binary packages for.
My job since a few months is to actually provide a binary package that runs on as many platforms as possible. They all suck: with windows you get hassles with side-by-side errors and incompativle c runtimes. For OSX you have to cross-compile from Leopard to Tiger and from intel to ppc, which, while doable, gives you packages you cannot buy test machines for. Linux is horrible, totally horrible, especially if you want sound -- the gstreamer dependency of phonon should be killed dead.
(And yes, we also provide a source package. No worries, it's GPL.)
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 11, 2009 9:52 UTC (Wed) by boudewijn (subscriber, #14185) [Link]
Oh... And what I forgot to add: for our binary packages on Linux and Windows we use the bitrock installer. Even Linux users tell us they appreciate that :-).
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 12, 2009 16:47 UTC (Thu) by nye (guest, #51576) [Link]
Apologies for responding to a largely unimportant section of your post, but phonon doesn't have a dependency on gstreamer; it supports a few choices of backend, including null if necessary.
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 11, 2009 17:02 UTC (Wed) by whitemice (guest, #3748) [Link]
> The build service is a build service. A build system. But it still does
> not make the packages magically compatible to other distributions.
It isn't magick, but it certainly helps "make the packages compatible"
> last time I heard, Gentoo does not use rpm or deb.
Which I mentioned; Gentoo and fringe distribution are irrelevant discussion.
>Likewise, what Mandriva expects of an RPM package is not exactly the
Yes, and the build service (a) supports Mandriva and (b) helps compensate for those issues.
> One example: please show me an init.d script that can be used across
init.d script difference are usually small tweaks (as mentioned above) and the build service facilitates applying those based on distro.
> and also complies with the policy regarding printing output?
Eh?
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 9, 2009 16:59 UTC (Mon) by efexis (guest, #26355) [Link]
9 times out of 10, http://www.freshmeat.net ... much cleaner site, not bogged down with java-trying-to-be-clever-script, maybe it's just a matter of taste, but to me, sf.net is merely my "can't find it on freshmeat.net"
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 10, 2009 9:13 UTC (Tue) by DonDiego (subscriber, #24141) [Link] My base presumption is that sourceforge (and all the other clones) are very narrowly focused on supporting software development.My impression is that they are about generating ad revenue. I guess they succeed in the short term by shoving more ads down your throat until you manage to download anything. In the long term, I resent dealing with sf and try to avoid it as much as possible...
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 10, 2009 10:49 UTC (Tue) by pharm (guest, #22305) [Link]
Yeah, that too.
Also, I loath having to spelunk through mailing list archives hosted on sourceforge. Thanks be to
All in all, sourceforge is just about the worst argument for OSS in existence. Anyone who's first
How To Successfully Compete With Open Source Software (MicroISV) Posted Mar 10, 2009 22:10 UTC (Tue) by nix (subscriber, #2304) [Link]
That mailing list UI is truly awful. They seem to have gone to an enormous
amount of effort to produce something many, many times worse than a simple set of static mailman archive pages. Even getting a threaded view of a long thread, or a list of all threads, is absolute agony (not helped by the site's appalling slowness, probably because it blocks all the time connecting to ten thousand impossibly dog slow advert servers).
Anything, even MARC's demented interface, is preferable.
Or... Posted Mar 9, 2009 17:32 UTC (Mon) by dmarti (subscriber, #11625) [Link] You could call this a checklist of items that your open-source project should do if you want the kind of regular users who are used to buying from small-time independent ISVs.
Of course, if you just want the technical elite, make a web site that's just the source code comments converted to HTML, plus a "git clone" line.
Or... Posted Mar 9, 2009 19:26 UTC (Mon) by ncm (subscriber, #165) [Link]
In fact, you don't even need to write the code yourself. Just take some existing program, glam up the UI to the point where the original developer would throw up, package and rename it so the clueless can find it and make it work, and then sell it them that do. It's not even, strictly, unethical.
Or... Posted Mar 11, 2009 0:10 UTC (Wed) by man_ls (subscriber, #15091) [Link] Stop talking subrepticiously about Ubuntu! (Just joking ;)
Or... Posted Mar 9, 2009 20:38 UTC (Mon) by tzafrir (subscriber, #11501) [Link]
It also depends on how you define "success". For the ISV "success" is ultimately selling of usage licenses. For a free software developer: motivations vary and hence the criteria for success varies.
BTW: SourceForge has actually improved in the recent years. For instance, you can now give a direct download URL.
Ultimately, the best way to offer native installers is to get your package into distributions. You just can't beat the simplicity of 'aptitude install foo' (or whatever native method for the user). Your packages will never be as good as those QA-ed by the distribution.
Or... Posted Mar 10, 2009 3:07 UTC (Tue) by nlucas (subscriber, #33793) [Link]
This would be true if the QA was good, but sadly this only happens with the popular packages.
Or... Posted Mar 10, 2009 5:29 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
A typical proprietary rpm/deb package is something I truly fear (quality-wise). They invent their own creative ways to do interesting stuff in the post install scripts that can break your system in interesting ways.
At least with Debian (and AFAIK also with Fedora. not really sure about other distributions) a package goes through some review and QA before it is let into the repository, as (to put it bluntly) the distribution does not want to support junk, and once it is in, the distribution has to support it.
Almost every independently-packaged Deb package I looked at had at least small problem or two.
Or... Posted Mar 10, 2009 16:08 UTC (Tue) by nlucas (subscriber, #33793) [Link]
I agree with you on the basic idea, and I also fear packages not made by the distro developers, but the truth is that most distros don't have the manpower to QA every single package and either resort to only support a few (like Ubuntu and Fedora, with the main repository being the only one they officially support, letting the "Universe/Multiverse" repositories to the community) or having testing/experimental stages (a la Debian and Gentoo), where all packages are maintained by the community.
There are good and bad points in either of this methods and in the end they all depend on how good the packager is.
What I believe is needed is a very strict installation environment, where packager bugs/features are not allowed to proceed if, for example, he decides to enumerate all users and modify user settings directly (as happened with some cups printer drivers, iirc).
Or... Posted Mar 10, 2009 16:33 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
Like installation in Windows. MS have some experience with that, given that they want you to be able to install random apps but still have a system afterwards. Since the average Linux system is very controlled compared to a Windows system, we still tend to trust packages to be installed absolutely, but also create a universe that third party packagers have trouble penetrating.
Or... Posted Mar 10, 2009 22:14 UTC (Tue) by nix (subscriber, #2304) [Link]
World of Goo's packages were well put together.
If a two-person group can do it, big companies have no excuse (other than
Or... Posted Mar 12, 2009 9:42 UTC (Thu) by job (guest, #670) [Link]
But that's about as simple as it gets, a game that has no dependencies outside of the application. It doesn't even need root privileges.
Try for example instead a simple application that counts the number of pages printed for each user, with users in passwd/ldap/nis, printers in printcap/cups, pre-scripts to be installed in different locations, spool-directories with vaying ownership etc. It quickly gets complicated.
Or... Posted Mar 12, 2009 10:14 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
> But that's about as simple as it gets, a game that has no dependencies outside of the application. It doesn't even need root privileges.
Perhaps that is the sort of application that makes sense to package and distribute outside of the standard distribution. The more deeply entwined the application is with the system, the more sense it makes to supply it as part of the system. Often though, the appliation can build on standardised components which are part of the system and can abstract the system-specific interactions.
Or... Posted Mar 13, 2009 0:21 UTC (Fri) by nix (subscriber, #2304) [Link]
Doesn't *even* need root privileges? The set of things that need root
privileges is very small, and any such things should surely be part of the distribution, because distro-specific policy will be crucial parts of their default configuration.
(And it does have dependencies outside the app. They're on fairly stable
Or... Posted Mar 10, 2009 22:23 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
Likewise: most software packages don't have the man power to package well for many distributions.
Those that do, can work with those distributions rather than waste time on maintaining their own repositories that will conflict with those of the distribution.
Or... Posted Mar 10, 2009 7:05 UTC (Tue) by pkt (guest, #53879) [Link]
That is not strictly true. You benefit from packaging when you are either lucky enough that a skilled distro packager is interested in your stuff or you are just so popular that several packagers are interested (which increases the probability that you will hit skilled ones)
Or... Posted Mar 10, 2009 22:33 UTC (Tue) by whitemice (guest, #3748) [Link]
>Ultimately, the best way to offer native installers is to get your
>package into distributions.
Which is next to impossible if you have created something other than yet-another-mp3-player.
Fortunately creating a one-click install link is pretty easy for most current distributions; add the repo and start the installation of a meta package.
Or... Posted Mar 11, 2009 17:32 UTC (Wed) by tzafrir (subscriber, #11501) [Link]
> >Ultimately, the best way to offer native installers is to get your
> >package into distributions.
> Which is next to impossible if you have created something
A number of packages about to enter Debian (a random selection - from the bottom of http://ftp-master.debian.org/new.html
http://bugs.debian.org/377462 - tpclient-pywx -- a client for space empire building
http://bugs.debian.org/512433 - r-cran-vcd -- GNU R Visualizing Categorical Data
http://bugs.debian.org/460537 - blockout2 -- Tetris like game (3D-tetris)
Or... Posted Mar 10, 2009 19:40 UTC (Tue) by iabervon (subscriber, #722) [Link]
I think the real reason that OSS can't compete in these niches is that it's written by people whose motivation is not to compete. The open source developer who writes a bingo card producing program is someone who can write code and wants to produce some bingo cards. This person writes the code, makes their bingo cards, and then realizes that this might be useful to other people as well (or maybe they just don't trust their backups). So they release it, by doing the minimal amount of additional work that's not either writing code or making bingo cards.
He says that his average user is someone who hates to use the computer, and is only willing to deal with it in order to get their bingo cards made. But, really, the average person is not willing to deal with much of anything that isn't part of scratching their itch. Just because someone likes to write software in order to solve their problem doesn't mean this isn't true of them.
The real point, I think, is that you can compete with OSS in some niche if you pick a niche where there is no OSS project that's interested in competing with you when that takes time away from writing and using software in the niche.
Now, maybe it would be possible to solve this problem outside of projects through the application of technology. But that's for people whose itch is to improve sourceforge, not people whose itch it to make bingo cards (or any other particular niche).
|
|||||||||||||