Getting Software Added to Unix Distributions? 267
suso asks: "I've been working on a set of programs called num-utils that I would eventually like to be considered for inclusion in some of the many free Un*x distributions (on the install CDs, etc). So my question is, how does one put their applications on the track to be included in the main distribution of Red Hat, Debian, SuSE, *BSD, and so on? Is this just something that is up to the maintainers or are there submission forms of some kind?"
Feedback forms (Score:5, Informative)
GNU? (Score:3, Informative)
Your program will then automatically get into *all* distros
Nandz.
Get eyeballs.. (Score:4, Informative)
The larger distributions will not carry your tool until it's become widely adopted by the Linux community - be thankful, otherwise RedHat 9 would require a DVD or two, instead of (just!) 3 CDs...
These utilities you have here, while useful, will probably not see much user adoption. However they would be very useful in shell scripting. If a more mainstream user application requires your utilities to function, the distro will be forced into including your stuff - as a dependency.
Make your own binary packages (Score:2, Informative)
This way you (or someone you know) can be an inofficial maintainer for your package. When your software becomes popular enough, it may eventually be included with the major distributions.
So my advice is basically: patience =)
Money talks but here's some free advice... (Score:4, Informative)
But, of course, that's not what you wanted to hear. I'd check out their FAQs, ask questions in their relevant forums, usenet groups, etc. I'd imagine that each distribution has its own criteria for inclusion so your approach to one vendor might have to be completely different to your approach with another.
Whatever you do, bear in mind two (slightly paradoxical) things:
1. They probably get asked to include lots of software, some good, some bad and some downright ugly.
I know of one major magazine that was sent an application for inclusion on its cover disk that calculated sales taxes for you - by taking the figure you gave it and multiplying by the relevant amount. That's the chaff. You need to be the wheat. So make sure that your software is truly worth inclusion (Does anybody already have a similar offering in their distribution? How does yours differentiate itself? How is it superior?) before you start investing serious time and effort into promoting it.
Also, remember that there will be great pressure, both internal and external, for vendors to keep their distributions free of bloat. Even if your software is unique, does it really offer something that a significant proportion of the target audience will want and use? You could develop the best doll's house design software for Linux ever but if nobody wants to design doll's houses on their Linux machines then you're screwed.
2. If you really do have a product worthy of inclusion then persevere.
Once you find the distributions' relevant contacts, harrass and hassle them about it until you get some sort of feedback. If they say 'yes' that's great, but if they say 'no' ask why it's a not a go.
But remember, although it might be their jobs to deal with new submissions, it isn't their jobs to deal with crap. Don't be offensive, advesarial or overly aggressive and don't become a stalker (leaving two voicemails a day is a no-no) or the only answer you'll ever get is 'no'.
Good luck.
Debian (Score:5, Informative)
Or, you could file an RFP (Request For Package). See instructions [debian.org].
I don't think it's really all that hard... (Score:4, Informative)
- It should fulfill a genuine need. If you're aiming for wide distribution you can't expect to achieve it with a something that's only relevent to a few people or in a few circumstances. You should also have some sort of document that shows how someone would save time or accomplish new things with this tool.
- It should be small yet robust, minimalistic yet powerful. I don't think anyone would consider adding a tool to a default install that is either too large for the features it offers, or two pedestrian in the type of features that it offers.
- It should be packaged well. Ideally it should compile and install in the proper locations out-of-the-box on a variety of systems. Make sure that it uses well-known methods, such as autotools (i.e. "./configure --prefix=/usr/local") or some other well-know "make; make install" type of setup.
- It should be well documented. At the very least you should have full manpages that your install script puts in the right place. Also consider man2html output on a web site, an possibly texinfo for the purists. You can't expect to get away with "just run --help and figure it out" or "look in the README."
- It should be licensed sanely, and should have reasonable dependencies. No one like a bizarro license, and no one likes a tool that takes sixteen different libraries of particular versions to compile.
- It looks like you're trying to get these tools standardized so that they could be relied upon for scripting... this will always be very hard to accomplish, but you might look into getting them merged with some popular packages, i.e. 'fileutils'. If there's a particular program that they are well-suited to being used with (like awk or something) then see about getting them added, perhaps in a "contrib" dir, to a project like that.
Frankly, though, your post was a little worrysome... in the sense that it almost seems like you're trying to get everyone to use these tools because they're there, not for some intrinsic reason. That just won't work, they have to do something really well or make it much easier to do some other task, etc.... You can get the word out and announce to various interested parties, but you will never be able to force anyone to do anything. In other words, view the situation as one of wanting to make the best programs you can, and if they receive universal support that's icing on the cake.
Step 1: Write something useful... (Score:2, Informative)
Just let nature take its course. If no one wants to include your package, there is no point in having it included for the sake of vanity.
If you are fairly confident of its usefulness, include a debian directory, and a rpm spec file in your source. That'll make it easy for people to package.
Build Mindshare (Score:3, Informative)
Just submit a new ebuild as a bug report. (No, that IS actually the proper way.) After a few weeks in the mill, your package will be out and about and happily rsynced in with every gentoo user. Gentoo are working on porting portage, their source distribution mechanism, to MacOSx and Window (running CygWin).
Of course, instant gratification is not a hallmark of the portage system.
You are competing with everybody else's widget in portage. So just make sure you get in cahoots with the folks who write the install docs, and have your software be made the subject of a few ZDnet articles. Writing a HOWTO based around your product is also a good idea.
Re:Linux is not Unix (Score:5, Informative)
*nix is much newer (circa mid-90s, rather than the late 80s Un*x started in) and is actually much less accurate. Un*x refers to Unix(tm), I've heard *nix refer to just about anything POSIX. Why don't more people refer to things by the standards they're actually judging Un*x-a-like systems?
How it worked for me .. (Score:5, Informative)
Once upon a time I wanted an MP3 streaming server, none of the ones I looked at did what I wanted. So I did the standard thing and designed my own.
After releasing my first version to freshmeat [freshmeat.net] I had about five subscribers to the project.
These subscribers gave me patches, feedback, and encouragement.
Doing a websearch [google.com] for the project name I discovered by accident that the the package made it into Gentoo [gentoo.org], and similarly Netbsd without any feedback or involvement from myself!
The next step was my becoming a Debian Developer [debian.org] so that I could upload it there - and not worry about other people doing a bad job without me. (Not a real concern; I had wanted to join Debian for some time anyway).
Now life is good - I've no idea if it's in RedHat because I've not touched it for years, but SuSE include it the *BSD's and Gentoo cover it, and Debian gets the latest versions all the time.
Freshmeat lists 120+ subscribers to the project, and it's probably on the verge of becoming an official GNU package sometime soon.
If you use it and like it buy something nice? [amazon.co.uk] </ObPlug>
After downloading it... (Score:2, Informative)
You seem to be working explicitely with files, I tried to type "average 1 2 3" and got a file error, why not use?
cat numbers.file | averageThis would make the commands script friendlier I think.
Also, echo '1 2 3' | average output 1, which confused me, I fixed this by changing line 117 in 'average' to read
while (m/\s*(\-?[0-9]*\.?[0-9]+)/g) {,i.e., the if -> while, and ^ has gone, and the 'g' flag is used, this does all white-space separated numbers on a line. (That can be your first(?) bug-fix)
Also, some countries use spacing to group `thousands` together, where American/English speaking countries use a comma, the French/Germans use commas to indicate decimal points, then there's comma separated values and the locale settings...(at least now I know why your using Perl :)
random, I hope 'rand' uses /dev/null or something internally,numprocess doesn't like me doing ^ (power) first, after the comma, it's fine, expect that (5*1)^2 != 7 and
(5*1)^1 != 4, whatever the carrat ^ does in Perl,it's not power, power is ** (carrat is xor looking at the results).
I'll stop there, sorry for...um, you know..The only other thing I would say (and this doesn't really apply because your using Perl) is if all these functions are supposed to be doing essentially the same thing (code re-use is clear from the source) then the busybox method of compiling all of the commands as functions (saving some space) seems good, then you can softlink the commands to relevant functions. (e.g. 'numgrep file' would call 'all_function --numgrep file', where all_function is the real executable).
(having said all that, numgrep does look useful though, grepping template source code for numbers when the templates have each line numbered is not fun).
BB
num-utils does not look that useful to me (Score:2, Informative)
Re:Don't use the GPL (Score:4, Informative)
Which systems are you referring to? I know the BSDs avoids GPLed code for drivers and core programs, but user packages is a different story. And OSX includes GPLed code. *BSD, All GNU/Linux, and OS X, I'd say that the GPL can get you into plenty of OSes.
-t
Transparent Debian (Score:3, Informative)
Either add your package to the wanted [debian.org] list, or become a Debian Developer [debian.org] yourself.
I'm not saying becoming a Debian Developer is quick or easy (though few would describe it as really hard), but the process is very transparent, and available to anyone. In part, I suspect this transparency, in combination with its maturity, is why Debian has so many more packages than any other software distribution.
Never underestimate the power of transparency.
Re:Publish first to website. (Score:2, Informative)
This is the most important step. You have to have a piece of software that has value for people (and therefore for a distribution). It may be software that is missing, it may be that it does something better than others.
Release your software, work on it. Since it's good people that need it will show up and use it. Open source software gains speed by word of mouth. Eventually someone will package it for Debian and someone will do Redhat packages for your local website or maybe even for freshrpms.
This is a rather important step where some projects fail miserably: Everybody that shows up and says something about your project is a contributor. Take him serious. Even if he only bitches about missing or non-working things. There are probably quite a few valuable feature suggestions and bugs you didn't know about inside his hate mails.
As an added bonus, listening to your users gives you more publicity and word of mouth for free.
The day will come when someone - it's probably better if it's someone else - suggests you for inclusion in a package. There will probably be quite some other suggestions. There'll definitely be one other suggestion: Don't include anything. You'll have to prove you're worth the work for the distributor. Maybe they won't even inform you about the inclusion of your package.
From the GStreamer point of view the big breakthrough was the inclusion into GNOME as the "official" media framework. For the first releases (2.0 and 2.2 I think) GStreamer was only used by the sound recorder. They wanted to see if we are good enough. Since we lived up to their expectations they'll now include a media player based on GStreamer in their next release.
This inclusion into GNOME made other distributions aware of us and GStreamer is now included in Redhat 9 and I think Mandrake 9.1, too.
I have to say though that I had to find out about that myself since I'm not a Redhat user and they didn't come to tell me. They didn't even ask questions which I would have expected distros to do when they want to include a package.
Inclusion into a distribution for me is just "Hey, I didn't know I was in!"
Re:On Perl and command-line utilities (Score:5, Informative)
This seems to be easily misunderstood, probably especially by Linux users where no distinction between base system and third-party apps exists (or in a less visible way, at least).
It did indeed mean that some tools in the base had to be reimplemented, either in C or as shell scripts. Obviously the majority of developers decided that this was less pain than having to keep one version of perl around even when users want a newer one, because you could break their systems otherwise, to have to check various important parts of the systems when you integrate an updated perl etc. The result of all this is that having an up-to-date perl is just one "portinstall perl" away, the system is more stable and modular, and, indeed, that trivial perl utilities like those in the article are unlikely to become base components. Big deal.the FreeBSD perspective (Score:4, Informative)
Re:unique? (Score:1, Informative)
Re:Publish first to website. (Score:3, Informative)
The GNU project does not maintain any contributed software. The FSF does take responsibility for suing GPL offenders, but that requires you to sign over your code to the FSF (nothing scary, they grant you a no-strings attached license back.)
As for the coding standards: they are quite strict in enforcing those, in particular the clause that a GNU program cannot link or refer to non-free software. For example, Ghostscript was recently taken out of GNU, due to disagreements over the linking to the non-free Aladdin ghostscript.
For Mandrake Linux ... (Score:3, Informative)
More and more development is being done by the community, so you may want to stop by the cooker wiki [mandrakesoft.com] which may have more up-to-date documents than those on the Mandrakesoft website.
It's not difficult to just look it up! (Score:2, Informative)
Redhat (last I checked, which was 3 years ago) has a much less formal method, you just email one of the people on the team and they may or may not add it in. Usually they won't, unless you can show that it's worth the trouble since it adds to the cost because they have to test it.
Adding stuff to Gentoo and Debian are generally easier than Redhat and SuSE because of testing costs associated with commecial distributions versus free/community distros.
FreeBSD (Score:2, Informative)
-- Brooks
Re:learn awk (Score:3, Informative)
you wrote 8 apps, in perl, that should take any perl programmer 2 minutes to do (and are so simple, one should use awk for them).
the body of your apps has more text that is dedicated to license and documentation than actual code.
your implementation is crap. i quote from your 'random' man page:
random is slow when dealing with large ranges to randomly find a number from. This is because it creates a list of all potential numbers before picking one. So it can be memory intensive for large ranges.
wtf?? if you were my employee, you'd be fired for writing code like this.
your apps are of very little use to most people. and the ones that do need them likely have just the right variations on what they're doing that they might as well write their own.
i would say your chance of getting included in any big distribution is approximately zero.