Leading A Low-Profile Free Software Project

NEdit is a Linux/Unix "point and click" text editor that gets almost no press but has a dedicated (if small) band of devoted users, including rusty at kuro5hin and myself. We get lots of news about high-profile Open Source and free software projects, but rarely hear about ones like NEdit or the people who lead them -- like Mark Edel, NEdit's original author, who is still the project's integration "gatekeeper." This is a good opportunity for anyone who is thinking about starting a free software project to ask what it's like to toil in the shadow of giants. Please post your questions below. We'll forward about 10 of the highest-moderated questions to Mark tomorrow, and will post his answers next week.

Comments

Project coordination

[techmuse]

First, thanks for producing Nedit. I've been a big fan of the program for years, and it's always one of the first things that I install. I'm wondering how you go about coordinating the development and testing of code on an open source project. Do you create well defined APIs for modules to interact with, and then ask people to work on modules that use those APIs? Do you put one person in charge of each segment of the project? How do you resolve disagreements over the features and functionality of the project? PS. What happened to the // or /* */ commenting macro in Nedit? I miss it!

Using Motif/other 'unpopular' libs

[JanneM]

A lot of people are very hesitant to install a whole set of libraries to run only one application -- almost no matter how good the app is -- when there are 'good enough' alternatives for the standard libs they already have.

Do you feel that NEdit has suffered from not using more popular libraries, and does it matter to you?

Users. Developers. And How to Find Them.

[omarius]

I run a small (one developer: me!) project at sourceforge: a text-based web bulletin board called vaxbb.

Although sourceforge says it's been downloaded 63 times, I've received nary a comment or email of any sort. Granted, it needs a lot of work before vaxbb will be an install-n-go program, but I definitely think it fills a niche (I started writing it because I couldn't find a free bb that I liked the look of).

So, after all that intro, my question is: Does a project have to be super-slick before people will use or contribute to it? How does one find developers w/out a huge user base. . .or get a user base without having a fully-developed program?

-Omar

I have to ask...

[pb]

What data structure do you use to store the text internally, and why? What trade-offs exist in your approach?
---
pb Reply or e-mail; don't vaguely moderate.

How do you "advertise"?

[OlympicSponsor]

Reading newsgroups and mailing lists, I occasionally come across people who have problems that could be solved with software I have written and made available. I have a hard time coming up with a way to point them towards my software without coming across as some kind of big-headed, know-it-all, "my software cleans your floor and does your taxes" loser. What to do?
--
An abstained vote is a vote for Bush and Gore.

Common sense of FS/OSS development

[dilger]

Here's two questions:

1. From which (if any) of the commonly accepted principles of FS/OSS development does your project deviate?
2. How much time do you spend writing code vs doing more administrative/moderation tasks?

thanks. cbd.

Software Enginnering for OSS?

[Midnight Warrior]

Now that you've successfully created a wonderful, stable editor, how many of the following software engineering techniques were used on the project, or would have been helpful?

1. Clear, concise statement of work (since NEdit was developed with U.S. Govt funding)
2. A Requirements Management process (measurable details about end-user goals)
3. Requirements Traceability Matrix (did all the planned stuff get implimented?)
4. Design Documents (GUIs plus interactions with black-box libraries or external packages)
5. Work Breakdown/Size Estimates (what are the pieces of the design that need attacked, what skills are required for each, who is attacking each piece)
6. Project Tracking (some automated way of allowing outsiders to see how it's going)

Colleges are teaching this. Companies who want government contracts are starting to do this kind of stuff. Would these software engineering techniques help OpenSource biggies stay on track and on time even though there is no financial interest to do so? The upcoming <cough>Linuxkernel<cough> comes to mind.

License

[angst_ridden_hipster]

First, I want to say that I've been using Nedit for probably seven years, and I've always thought it was the best thing out there. Someone mentioned that it eased the transition from PC/Mac to Unix, and that was certainly true for me. So thanks for your great work!

When I first used Nedit, I was working for a government-related agency, which had restrictions on what kinds of software could be run. Because Mark Edel hosted the source on a Fermi Labs machine, I was able to weasel around some of those restrictions. This, of course, was not before GNU but was well before the Open Source movement gained its groundswell of popularity. When the movement did gain popular momentum, it was looked upon with distrust and suspicion within the agency where I worked. There were offhand references to Communism and anarchy whenever people heard my enthusiasm. Likewise, when I wanted to give out source to some utilities I wrote, I was summarily shot down and chastised -- "this was paid for by the Government!" I was told (which was exactly my point; they just had a different conclusion as to what that meant).

So... how did you convince Fermi Labs (or the DOE) to allow source distribution in the first place? Did you run into any difficulties when you decided to change the license? Did you have to get permission within the organization? If so, what did you need to do to get approval?

Thanks again!
bukra fil mish mish
-
Monitor the Web, or Track your site!

Design and testing

[Grab]

One of my pet peeves is lack of design, documentation, commenting and testing. I'd appreciate your views on how much you believe these are necessary. Do you design before you code, or do you just dive in? Do you like to provide loads of support documentation for users and co-workers, or are you of the "the-code-is-my-documentation" school?

More importantly, how do you enforce any such standard on your project, given that you've got other people submitting you code patches which may be technically perfect but visually obfuscated? And has this caused any friction, since managing coders is a "herding cats" scenario, and criticising someone's coding style is often taken very personally?

Grab.