Adding new features to NeoOffice

[pluby]

Problem:

Over the last two years, the number of NeoOffice users has been growing exponentially. This has also caused our costs to run NeoOffice, both in time and money, to grow exponentially as well. As Ed and I have mentioned in previous posts, we have managed to fit these costs within our very limited time and donation budgets by severely restricting the scope of the NeoOffice project to only one thing: making OpenOffice.org run natively on the Mac.

The dilemma that Ed and I face is that there is a constant stream of requests for us to add new features or change OOo functionality. While we really hate having to tell everyone that our scope is very limited, the reality is that new features require significant amounts of time and money that neither Ed nor I have. In other words, to do any significant new features, we have to do some combination of hiring engineers on contract, of Ed quitting his job (his only source of income), or of me giving up paid work (my only source of income).

Since Ed and I working for free for large stretches of time is not feasible for either of us, the main problem is that fundraising must be done to fund any significant new features or changes to OOo. Even if we could raise a sizable sum of money, a second problem is determining which features should the money be used for and which must be deferred until additional funds are raised.

Solution:

Fortunately, we have come up with a flexible solution that addresses these two problems: on our website we will post the estimated total engineering and support costs for a short list of the new features or changes to OOo that our users say they want the most and users can make donations to the specific new features that they want to fund. I found that we can track donations by feature fairly easily so that users can see, in near real time, the total donations received for each new feature. The real key part of this solution is that if users donate only a small portion of the estimated cost of a new feature, we will simply refund all the donations for that feature and replace that feature with another new feature proposed by our community.

No solution is perfect and there are some benefits and risks associated with this approach. Below are the benefits and risks that are associated with this approach:

Benefits:

- Users get to control the scope of NeoOffice - Up until now, the scope of the NeoOffice project has been controlled exclusively by Ed and I. By letting the community propose new features or changes to OOo and then allowing users to pick which ones, if any, are worth a donation, Ed and I have basically given the NeoOffice users direct control over the scope and future direction of NeoOffice.

- Ed and I no longer need to guess what work needs to be done to keep NeoOffice viable - A huge number of new features and changes to OOo are continually requested on this site and in Bugzilla. We know that some of those requests may be really good ideas and some may even be fundable by the user community. However, the sheer volume of requests makes it extraordinarily difficult to identify what is really critical for many NeoOffice users from what is nice to have but not critical. By giving the community some means to fund their request (Ed and I have many years of experience estimating engineering and support costs), the most critical new features or changes to OOo will float to the top and get added to the web page where other users can either donate to or ignore the new feature.

- Users have no financial risk - Since we will refund any donations for a feature whose total donations fall short of the estimated cost and, just as important,Ed and I will not spend a new feature's donations until the estimated cost is funded, users have no risk of donating to something that will never materialize.

Risks:

- New feature donations may reduce existing donations - In the short term, this risk is a real one. However, in the longer term, I believe that unrestricted donations are likely to decline significantly even if we did not implement this solution. My belief is based on the fact that nearly every open source project, online press, blog, and hobbyist now solicits donations. This, in turn, is causing donation burnout among users. If my thinking turns out to be correct, most sites that are funded by donations are going to see rapidly decreasing donation revenues and to somehow bridge the gap. With that in mind, allowing users to donate to specific new features or changes to OOo seems to like a nature progression of our existing funding mechanism.

- Users may think our estimated costs are too high and not donate anything - This is one of those risks that is not really a risk but I included here because I suspect that some percentage of users will complain that our costs are too high. To put it bluntly, our estimates are very conservative and include the full support costs that are associated with the new feature so if people think our estimate is too high, we encourage them to not not make a donation to that feature. Both Ed and I incur a lot of risk by promising to develop and support a new feature. By not funding a particular feature, our very limited time is available to work on other new features that users are willing to fund or to work on other business projects that may indirectly benefit NeoOffice. In other words, Ed and I are neither hurt nor offended if a new feature does not get any donations. In fact, if no new features are funded over the next year, Ed and I would still get the benefit of knowing that the existing NeoOffice features mostly meet the critical needs of our users.

- We can only accept donations for a new feature for 50 days - Unfortunately, PayPal only allows no cost refunds to be made within 60 days after a payment is made. As such, we need to limit a new feature's open donation period to only 50 days so that we have enough time to refund everyone's donation before the 60 day deadline passes. The risk here is that some new features may get rejected because of lack of awareness of it among users. Fortunately, this risk should be easy to manage as we can always repost a feature that has previously failed.

Next steps:

In our view, the risks are very minimal and there are benefits even if no one donates to any new features. So we will most likely post the new web page in about a week or so. Since the new feature donation tracking code will be new, we are thinking of listing the following two new features on the web page. We picked these because 1) they have seemed to always be among the most commonly requested features and 2) while the estimated cost for each is not trivial, it is within reach given the size of our user base and both can be released in a fairly short time period if enough donations are received:

Add native Mac OS X spellchecker support - Estimated cost: US$30,000
Add native Mac OS X address book support - Estimated cost: US$30,000

Thoughts?

Patrick

[LemonAid]

Patrick, and Ed,

Very interesting. It is sure worth a try.
This way, users can back up their requests with ... funds!

"I" wonder if it may take one or two cycles to find the desired "feature" that gets those funds out of peoples pockets and into the development cycle. I will be watching, and voting with funds. - these two items would not be the most important for me currently. I'm going to take some time and figure out what my hot request features are.

EXCELLENT Idea.
Note: I would be interested in seeing a list of possible features (even if they don't have complete cost estimates yet) to help me invest wisely for the community.

Philip ( "Money ... meet Mouth!" )

[Samwise]

I'm totally favorable to that approach.

Now, here's my 2 cents about the two proposed features :

#1 - Add native Mac OS X spellchecker support

The feature is one of the top requests, and as such is a good candidate for such a fundraising program, however, as you pointed out to all who suggested this feature on Trinity or Bugzilla, Mac OS X only offers spellchecking for 12 languages or so (IIRC). How are you going to maintain backwards compatibility with the existing spellcheck system ?

#2 - Add native Mac OS X address book support

This has been accepted as a Goodle Summer of Code project which should be carried out by Omer Bar-Or, mentored by Sébastien Plisson :

http://wiki.services.openoffice.org/wiki/Summer_of_Code_2007#MacOSX:_Address_book_integration

http://code.google.com/soc/ooo/appinfo.html?csaid=BE0EB922DE5A4E47

I'm not sure many people would pay for a feature which might be integrated to both the X11 and Aqua versions of OpenOffice.org for Mac OS X ...

[pluby]

[Samwise]

Well, even if the task isn't complete in 12 weeks, the student's work can be completed by the Mac porting team if they decide to. Anyway, I'm not interested in Address Book integration myself, so I can't even imagine whether people would pay to have it in NeoOffice.

Regarding the OS X spellcheck integration, would it be :

a) implement the native spellcheck, and allow it to read the OOo dictionaries as well;

b) implement the native spellcheck alongside the OOo spellcheck, and allow users to fall back on the OOo spellcheck for languages that Mac OS X doesn't support;

c) something different.

[Lorinda]

I think this is an excellent idea. If for no other reason that it helps the folks who request features to really see how much developing them costs. The downside of free open source software is that people begin to expect something for nothing.

Native spell check is not a big deal to me. I am relatively new to OSX, so the concept of separate spell checkers for each app is neither foreign nor bothersome to me.

I would donate towards accessing Address Book; while I can manage with the work around, it would indeed be nice to have it.

At the moment I don't have other suggestions to make.

Lorinda

[pluby]

[LemonAid]

[sardisson]

Patrick, the plan sounds entirely sensible, and the proposed approach to doing the spell-checking bit seems typically well thought-out (though I must say from our experience in Camino, Apple does not make it easy to replicate the native experience without using the entire self-contained NSText* + NSSpellCheck + UI system )

I'm not sure what I might "vote" for; Neo 2.1 is a pretty nice piece of work

Smokey

[LemonAid]

Thanks Patrick,

I leave it up to your wisdom and skills about how to best divide these tasks up.

I "kinda" know Neo supports sound, but have not run any real examples of this.
Could you/anyone be so kind to provide some example ideas how this is currently used?
Maybe there are some Wiki links that I have not seen, yet. Thanks

I'd place US$100 on (your proposal ) #1 to ... Win!
-- and it's an item on the Neo Feature list on the Wiki

[rob_06]

I would just like to see some form of compatibility beyween Neo Office and Thunderbird and Firefox.

I am more than happy with the rest as I am not overly interested in the address book support or spell checker.

The QT support is a good idea.

[Samwise]

[sardisson]

[LemonAid]

[pluby]