lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Van Den Berghe, Vincent" <Vincent.VanDenBer...@bvdinfo.com>
Subject RE: Barrier to Entry?
Date Thu, 11 Jan 2018 13:29:06 GMT
Hello,

You are of course entirely correct. If you want an industrial strength search engine, Lucene.net
is pretty much the only game in .NET town. Which probably explains the big user community.
 But contributing is quite another matter. 

I don't know why this is in general, but let me give you my personal experience, for what
it's worth.

I became interested in Lucene.net because I needed to build a search engine at work. I did
have some positive hobby experience with the 2.9 version in the (very) far past, so I decided
to give the latest one a whirl. Lucene.net 4.8 is quite a different beast and I was pleasantly
surprised. All hail Shad Storhaug: he is pretty much the driving force behind all that goodness.
NightOwl888 iz da man. Seriously.

I poked around a bit, did a lot of benchmarking and debugging, and whenever the result of
those looked like they could be useful to the community, I made small contributions to the
project as a result, because it was (and still is) the right thing to do. But there were two
obstacles:

- I have zero experience in GIT, open source projects and how to contribute. Yes, I could
read a book about GIT. I'll put it on the stack of "to read" books. Maybe next year. In the
beginning, I just copy/pasted code to the dev mailing list: much quicker. But unworkable in
the long term, especially if you want to contribute "big". The one time I tried to follow
the rules for something nontrivial (https://github.com/apache/lucenenet/pull/208) it didn't
seem to be worth the trouble. This is quite possible due to my aging brain and lack of flexibility,
more than the technical or procedural issues.

- the test suite of Lucene.net (and I suppose for the Java version as well) is not made to
find problems. It's only designed to generate problems. The presence of decision points based
on random numbers make it extremely difficult to reproduce a failing case, especially when
you are unfamiliar with the code. I spent a lot of time waiting for a test to fail, and then
staring incomprehensibly at the code, wondering why. I'm sure there's a good reason for things
to be as they are. It just makes it so much more difficult. Maybe insert the last sentence
in the previous paragraph about aging brain here.

Over time, there were 2 things more things I viewed as obstacles:
- .NET Core/.NET Standard became "a thing".  As if making it work on regular .NET isn't work
enough. I'm sure it has its uses, but it's yet another layer of conditionals. And failing
tests.
- the project moved to VS2017. This isn't on the list of approved software at work (not even
the community edition), so it basically stopped me of doing anything significant. In time,
VS2017 will likely be put on the approved list, which will remove this obstacle. But not in
the foreseeable future.

Now, I know all of this are just excuses. If I had the free time to solely focus on Lucene.NET,
I would stop whining and start contributing.  But that would preclude me of doing anything
else: for me, Lucene.net is the kind of project you need to focus your entire attention on
if you want to do something worthwhile. Perhaps other people are more talented or have more
free time to be able to contribute to it in addition to the other stuff they do. I'm not one
of those people. 

Lucene.net served (and continues to serve) me well and I realize all too well that what I
gave back to the project is woefully insufficient. At this point in time, I can do nothing
else but apologize.


Vincent

-----Original Message-----
From: Stefan Bodewig [mailto:bodewig@apache.org] 
Sent: Wednesday, January 10, 2018 3:44 PM
To: dev@lucenenet.apache.org
Subject: Barrier to Entry?

Hi all,

it looks as if we had a rather big user community but almost nobody seems to be interested
in contributing. There are occasional pull requests but not that many.

I wonder whether there is anything that keeps people away from contributing. Is it the complexity
of the project, the "port from Java"
aspect or are there technical or procedural issues that we could change to make it easier
for others to contribute?

Stefan

Mime
View raw message