First time here? You are looking at the most recent posts. You may also want to check out older archives or the tag cloud. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS. Thank you for visiting! (hide this)

UPDATE: There is a follow-up, which explains what happened in the community after this post: What happened to Lucene.Net? It got forked

Lucene.Net, the .NET version of the famous Lucene search engine, is in a pretty critical stage. The short version is that Apache Software Foundation is considering killing the project because the community behind Lucene.Net is not active enough and since the project graduated from the incubator to a real project on its own, no “official” releases have been made (only source releases) and the site is not compliant to the “branding” guidelines.

For the long version, please read the mail sent out to the Lucene.Net mailing list, Lucene.NET Community Status and the heated discussion that came out from this email:

Lucene.Net is a pretty widely use full-text search library: it is used by many opensource project like Umbraco, Orchard, NHibernate.Search, Subtext and even RavenDB is using Lucene.Net as foundations for the querying side of the product. And it’s is also used by lots of software agencies and consulting companies to build the solutions they sell to their customers.

Since none of the committers have a blog (or at least, not that I know of), since I’m a fan of Lucene.Net, with this post I wanted to raise the awareness about this problem and asking for your help.

If you are using Lucene.Net in your solutions or in your opensource project, consider spending some time helping out with Lucene.Net. Or even better, if you are working in a company that is selling solutions based on Lucene.Net, “ask your boss if you can get paid to help out - then put it on the company blog”. No, starting a money raising page will not help.

If no new people comes to help, the project will put back in the Apache Incubator and a new proposal has to be made and voted, or the project will be put in the Attic and then if someone want, a fork can be created (unfortunately the name has to be changed since Apache owns the name Lucene.Net).

So, if you want to help keeping Lucene.Net alive, please step up now, join the mailing list, and state your intentions over there.

kick it on

posted on Monday, November 1, 2010 7:00 PM

Comments on this entry:

# re: Lucene.Net needs your help (or it will die)

Left by Peter Donker at 11/1/2010 9:45 PM

I use and find it fairly useful. I have never understood the Apache incubator thing. Why is this not on CodePlex? Why bother with something that clearly hampers the project? Call it something else and just forget about Apache as they obviously are not interested in helping out.

# re: Lucene.Net needs your help (or it will die)

Left by Dave Van den Eynde at 11/1/2010 11:43 PM

My thoughts exactly. Who needs Apache to work as a FOSS project?

# re: Lucene.Net needs your help (or it will die)

Left by anonymous bastard at 11/2/2010 8:13 AM

And that is why .net has a shit FLOSS community.

# re: Lucene.Net needs your help (or it will die)

Left by bdaniel7 at 11/2/2010 10:22 AM

Maybe MS should take and further develop it, and use it for its "bing" thing.

# re: Lucene.Net needs your help (or it will die)

Left by Dc at 11/2/2010 2:35 PM

I agree, rename it and move it to codeplex/google code .... these Apache guys seem to have their own small world view on what Open Source software is all about.

# re: Lucene.Net needs your help (or it will die)

Left by Wyatt Barnett at 11/2/2010 2:42 PM

In 2010, you didn't need Apache to work on an open source project. But when Lucene.NET was first born in 2003-4, you didn't have that many. And if apache takes you under their wing, you went.

I think you'd run things differently these days.

# re: Lucene.Net needs your help (or it will die)

Left by andrexx at 11/2/2010 4:25 PM

Read mailing list. Not understand Apache policies and current status.
+1 for fork it on codeplex.
+1 for automate java conversion process
+1 for make it more .Net-ified
Use Lucene.NET on few projects with some custom improvements and I think that participate in the improvement project from time to time.

# re: Lucene.Net needs your help (or it will die)

Left by Anders Lybecker at 11/2/2010 5:24 PM

Apache Software Foundation is not killing the project, they are just stating that the project is not active enough and following the guidelines for a Top Level ASF project. It has the possibility to move back into incubation, which I think is a good idea.

To be fair, they project isn’t very active (last check-in was in July) and the site is hopeless out of date.

# re: Lucene.Net needs your help (or it will die)

Left by Mike Heath at 11/2/2010 5:54 PM

The ASF is not a junkyard for abandoned OSS projects. Who cares who uses the project? The fact of the matter is that no one cares to contribute back to it. It looks like Source Forge would be a better home for this project than Apache.

# re: Lucene.Net needs your help (or it will die)

Left by Jean-Sylvain Boige at 11/2/2010 8:16 PM

As much as I like all that tool has to offer, it's already a pain just to cope with the API changes.

Please tell us what to do with those many hopeless obsolete attributes, and I might consider helping out.

Also, providing the internal members with actual names could have been a good idea to start with, though I bet it was just ported.

I guess I'm just sorry.

# re: Lucene.Net needs your help (or it will die)

Left by John C. at 11/3/2010 1:55 AM

We use IKVM'ed lucene with much success. Think it must be hard for the developers to keep up with the rapid changes to the lucene code base.

# re: Lucene.Net needs your help (or it will die)

Left by mstump at 11/3/2010 2:19 AM

I think many of you are missing the point. It's not about where the project is hosted it's about the lack of contributions. Moving the project to CodePlex isn't going to fix the underlying issue.

# re: Lucene.Net needs your help (or it will die)

Left by Emmanuel H at 11/3/2010 2:40 AM

someone with knowledge of Eclipse could help automate porting using Sharpen. LLuis Sanchez of the Mono team ported JGit using Sharpen, link from his blog on how he did it (

# re: Lucene.Net needs your help (or it will die)

Left by Anders Lybecker at 11/3/2010 8:52 AM

Right on.

Lucene.Net is great and used by many - It lacks contributions...

Roughly 5 years ago the last port of Lucene to the .Net framework died due to lack of contributions. I hope that history will not repeat itself..

# re: Lucene.Net needs your help (or it will die)

Left by Jim at 11/3/2010 11:06 AM is used in Sitecore CMS. Wonder if you can generate some interest/resources from them...

# re: Lucene.Net needs your help (or it will die)

Left by Simone at 11/3/2010 11:42 AM

ASF is one of the pioneering foundations of OSS, and probably it made a lot of sense when it was created.
I agree that enforcing all the "politics" is probably holding the project back from releasing and probably also pissing off the committers because they have to care about "politics" instead of really caring about doing real development on the library.

Moving to CodePlex would help? Might help because .NET developers are not used to working in such environments where strict regulations are enforced, while Java and Linux devs are. And most .NET OSS developers might be adverse to such "entities" for their own "religious" reasons.

IMHO another thing that is holding contributors back is the fact that Lucene.Net is just port from the Java version: running a tool and fixing the bugs from the tool is not really "fun", and not having an explanation of this is done basically stops people from contributing.

# re: Lucene.Net needs your help (or it will die)

Left by Simone at 11/3/2010 11:45 AM

if you know someone would be great if you contact them and explain the situation

# re: Lucene.Net needs your help (or it will die)

Left by Dave Van den Eynde at 11/3/2010 12:20 PM

"Might help because .NET developers are not used to working in such environments where strict regulations are enforced, while Java and Linux devs are."

I think that's a pretty derogatory statement. OSS developers are OSS developers, in any language on any platform.

In any case, the ASF is mostly made of projects that run on top of Java. It's not hard to see the politics in it.

# re: Lucene.Net needs your help (or it will die)

Left by Simone at 11/3/2010 12:26 PM

Far from me wanting to be derogatory.
I meant that opensource developers that use .NET are not used to such big opensource foundations and projects because most .NET OSS projects are small in size and the big ones are handled by companies.

While Linux itself is so big that has to have politics and strict regulations in order to survive: same goes with Java. I was not being unrespectful just pointing out different experiences of the two group devs

# re: Lucene.Net needs your help (or it will die)

Left by Wyatt Barnett at 11/3/2010 12:53 PM

I'd also suggest that many .NET OSS devs do the OSS stuff because they can play with cool code and not deal with politics or other structures they might well struggle with every day at the paying job.

Personally, I've got a great situation where I can play with the cool toys, but if you are forced to work on some webforms dataset based monstrosity every day would you really want to go home and work on a 2.0 locked mechanically ported java monstrosity at night?

# re: Lucene.Net needs your help (or it will die)

Left by Dave Van den Eynde at 11/3/2010 1:51 PM

I can see that your intent is not to be derogatory, by any means, but I disagree with your views. You're either a developer, or you're not. You're not a Java developer, or a .NET developer, or a Linux developer, or any of the above. That's just the tools that you use, and I don't see how one can be a "different" sort of developer just because they use a different language. There are big projects on all platforms, and ASF is simply another FOSS "vendor" that groups a bunch of projects and put some weight behind it, weight created by being the largest "vendor" of web servers.

Also, I don't think you understand how Linux development works. It's not big politics, nor does it have strict regulations. You see room for improvement, you submit a patch and then it's either accepted or rejected based on a number of terms.

I've been reading through the mail reponses that you link to, and I can't rid myself of the idea that ASF needs a "plan" and "commitment" where there's no need unless they envision Lucene.NET as the little 'translated' cousin of Lucene.

Unfortunately I'm not in a situation where I use Lucene.NET on a daily basis so I'm not in a position to contribute much, but I understand what it does and why it's important to keep it alive, ASF or no ASF.

Given that ASF is a large Java community, how will their backing contribute to Lucene.NET? Even if it were to become a top level project within the ASF community, how will that benefit it? More eyes to make bugs shallow, in a Java community?

Personally, I think it would make a lot more sense if the Mono project would adopt it somehow. At least then it would get some traction.

# re: Lucene.Net needs your help (or it will die)

Left by Simone at 11/3/2010 2:15 PM

Totally agree... I want to work with cool stuff when I come after a day of working with ugly webform coding or writing tech docs, not work on old tech or interact with boards and writing more docs to explain everything about the project to someone that is not involved into the real development.

Developers are developers, no matter which language they use. But a language is much more than the "syntax": it's about the ecosystem of tools, libraries and the community around it.
If you don't like me referring to "developers", change it with "community": the .NET community is not used to such "policies", and people that want to contribute are scared away when they see that in order to release a new version there has to be a voting.

Add this with the "not fun" factor, and I think you get the result we have now.

# re: Lucene.Net needs your help (or it will die)

Left by Dave Van den Eynde at 11/3/2010 3:31 PM

Okay, we can agree on that. It is still my opinion that Lucene.NET does not need the ASF "community" to thrive.

# re: Lucene.Net needs your help (or it will die)

Left by Simone at 11/3/2010 3:35 PM

Sure, my opinion as well :)
Let's see what happens in the heated mailing list discussion now :)

# re: Lucene.Net needs your help (or it will die)

Left by Rumen Stankov at 11/3/2010 4:16 PM

Just move it into a commercial project. Open source just does not work. It means "free" for everyone and your expectations of people involving in massive amounts of hard-core code are... well, childish, to put it mildly.

I see a great potential in this product. Just remove the open source shit and put it into commercial state and move on.

Everyone that does not like that - suck my dick. Like - you write all that and put it free, if you are so clever.

# re: Lucene.Net needs your help (or it will die)

Left by Jean-Sylvain Boige at 11/4/2010 12:17 AM

Guys, where is this discussion going?

I've been reading all this just to see my questions where not slightly addressed. Let's talk concrete stuff.

What IMO makes it hard to integrate: 2.9.x obsoletes many of the important members most people used to 2.4.1 use and It's clearly stated that the 3.0 won't support the wrong 2.4.1 constructs -> I guess that's what you call the linux thing.

I'm probably one of the few who started to migrate from source check out, and honestly it's just endless though happily only a few of the 3rd party extensions broke, but this is already plenty of work for all those integrators here to care with.

Let us make this easier for every one here and you'll have more hands to push the 3.0 to release.

Now what about those problems I mentionned earlier probably related to the port -> no way to understand the hard meat because of natural obfuscation, and please turn those constants into proper enumerations on a personal note...

# re: Lucene.Net needs your help (or it will die)

Left by Troy Howard at 11/4/2010 12:42 AM

@Rumen: "you write all that and put it free, if you are so clever"

The reason Lucene exists at all as a point of discussion is because someone did exactly that... and more of us will do the same.

I run software development at my company, and I don't just "allow" people to work on open source on the clock, I schedule it and give it to them as a task as part of their daily work.

These libraries are critical to our product, and spending some of my development resources time is far cheaper than perpetual licensing of a commercial solution, and the commercial solutions pail in comparison to the value represented by our OSS components.

More companies need to do this... and given the tone of this cry for help, hacking on Lucene.NET might be the next open source thing our team works on.

# re: Lucene.Net needs your help (or it will die)

Left by Troy Howard at 11/4/2010 12:53 AM


API changes are always difficult but the recent Lucene API changes have all represented substantial improvements with no loss of functionality.

The point of the Obsolete attribute is to enable users to continue using code that works against the old API, providing some time and transition period to allow for migration. Your code should still compile and run without changing anything.

The Obsolete attribute is also very clear about what to expect future versions will remove that functionality, and so you should schedule for migration away from it. Upgrades are not forced, so technically there is no reason your code could not continue running indefinitely at 2.0 or 2.9.2 (with obsolete attribute warnings).

Other than general aggravation at needing to do migration work at all, can you comment on what specific issues the Obsoleted APIs are causing you, have you found functionality or a usability scenario that you can't replicate using the new model? Perhaps we can assist with a recommendation on how to deal with those situations, or perhaps the new API can be modified to be more backwards compatible.

# re: Lucene.Net needs your help (or it will die)

Left by Rumen Stankov at 11/4/2010 6:54 AM

I am not quite sure you have listened to what I said. My use of strong language was deliberate and I intended to make a point. I'll now use not-so-strong language.

Look at the comments. This is your typical open source "contributor". All these guys are so smart writing comments, so smart about wasting 3 paragraphs and saying nothing. Is this the audience you are working for? Why.

I cannot stress that enough - put the thing off the open source scene and sell commercial licenses for it. Expensive at that.

# re: Lucene.Net needs your help (or it will die)

Left by Troy Howard at 11/4/2010 9:53 AM


We make for-profit software at my company as well. I'm a big fan of getting an income. I'm also a big fan of software that doesn't have to be subject to the needs and expectation of a business. It tends to be better than software that is tailored to a market and to client's needs.

Phil Haack said a while back that he is not paid to write code. He's paid to ship products and deliver value. This is completely true in a for-profit business. Writing code is a side-effect. Writing good code rarely makes it into the list of critical must-haves to deliver. Depends on your philosophy, and how tolerant your company is to spending overhead dollars on "preventative" behaviours. Good code is what we all want to write, but it's not always what a business needs. Sometimes it only needs working code.

Open source on the other hand can take it's time. As the Apache Harmony FAQ says very clearly "It will be done when it's done". As everything else in the Apache Software Foundation processes and policies state very clearly, it will be done *right* or it will not be part of the Apache Software Foundation.

This commitment to quality is difficult to find outside of the open source world, and for very good reasons. The fact that Lucene.Net is in this current crisis is a good example of what the (good) open source world won't tolerate. Nobody wants abandonware.

The most successful open source model seems to be the one where: The code is open source, but the core committers have formed a "support company" that offers services, support and guarantees for timely bug fixes and feature adds (for a hefty price). This funds the developers, instead of asking them to do the work for free, but the project remains open source. Committers who don't work for the "support company" can still be involved. Decisions can still be made with community involvement instead of *only* behind-closed-doors corporate decision making effecting the progress of the project.

Open source means constant code-review from an infinite global community of developers at every level. This is a good thing. How many people review code in a closed-source product? Commonly only 1, maybe 5-10, maybe 30. Rarely more than that.

Open source is a good thing. Lucene.Net will continue on, but maybe it's time for some new people to be involved in managing the project. Or maybe it's time for George Aroush and DIGY to form a Lucene.Net oriented support company and start getting paid for their hard work.



Phil's Blog Post "We’re Not Paid To Write Code"

Apache Harmony FAQ

# re: Lucene.Net needs your help (or it will die)

Left by Wyatt Barnett at 11/4/2010 12:58 PM

@Ramon: how well would your little venture ( be doing without open source? Do you have the time and expertise to write jqGrid? Or jquery?

# re: Lucene.Net needs your help (or it will die)

Left by Eric Duncan at 11/4/2010 3:17 PM

There was rumors that the Solr bits would be merged into the Lucene core java project (specifically faceted search and caching). That's what I've been waiting on to go back to Lucene.NET over our use of Solr at the moment.

And when I say "Lucene", I mean seeing what I can do to upgrade Lucene.NET to it.

Now that I see the call to action, I have a renewed interest. But, you said it best: working under the Apache guidelines, we most likely won't see those upgrades for a year or two at best.

Therefore, I am stuck.. Keep using Solr now because I have no choice for those features, or try to introduce them myself.

If there were migration instructions for taking the Lucene Java project and bringing it into C#, and "fixing the errors" as you said, I'd give it a whirl for sure. And, I got a blog to boot! lol

# re: Lucene.Net needs your help (or it will die)

Left by Eric Duncan at 11/4/2010 3:36 PM

After reading the "mailing list", Apache sounds like an IRS letter you never expected. And then a person's frugal attempts to combat the giant. Boards? Really?

# re: Lucene.Net needs your help (or it will die)

Left by Mike at 11/4/2010 10:44 PM

+1 Put it on codeplex, it will increase visibility and professional developers might like the VS TFS integration to work on items.
+1 Ask the Outer Curve foundation to adopt it, it will give better guidance from the .NET prespective.

Good luck!

# re: Lucene.Net needs your help (or it will die)

Left by Jean-Sylvain Boige at 11/4/2010 11:29 PM

@Troy Howard:

I am aware my code works on a V2.9.1, which is clearly documented as a transition API before 3.0 will remove the obsolete constructs.
As a matter of fact, our product has been running smoothly on that version for quite a few month already, and as I mentioned above, most extensions like snowball stemmers do behave well indeed.

What I'm left dealing with now is getting rid of the warnings, getting ready for 3.0, "upgrading". This is on everyone's agenda before we can talk about moving on with the trunk. At least we could agree with that.

I already sanitized plenty of constructs in my code and I do understand what the API changes mean in terms of consistency, performance, flexibility. This is not the question, take it for granted.
I still have another couple of simple "add Version" or "path->Directory" updates to apply, but the following ones will get me headaches for sure:

-'Public Overridable Function GetTerm() As Lucene.Net.Index.Term' is obsolete: 'check sub class for possible term access - getTerm does not make sense for all MultiTermQuerys and will be removed.'.

- 'Public Overrides Function GetTerm() As Lucene.Net.Index.Term' is obsolete: 'Lucene.Net-2.9.1. This method overrides obsolete member Lucene.Net.Search.MultiTermQuery.GetTerm()'.

- 'Public Overridable Function Next() As Lucene.Net.Analysis.Token' is obsolete: 'The returned Token is a "full private copy" (not re-used across calls to Next()) but will be slower than calling [email protected] #Next(Token)} or using the new IncrementToken() method with the new AttributeSource API.'.

-'Lucene.Net.Search.ConstantScoreRangeQuery' is obsolete: 'Use TermRangeQuery for term ranges or NumericRangeQuery for numeric ranges instead. This class will be removed in Lucene 3.0.'.

-Same with RangeQuery

Well if you can help I'd be glad. Would you consider reviewing my code?
Once we get our code base stable, I can offer to return the favor on the core.

# re: Lucene.Net needs your help (or it will die)

Left by Troy Howard at 11/7/2010 12:58 AM


I'd be glad to review your code.

All of the issues you listed do have reasonable migration strategies available, but as you said, one would need to see it's actual usage to know the correct way to migrate it.

I typed up lengthy instructions, but the comment section here has some kind of limit and won't let my comment go through. I'll try splitting it up across more than one post.

If you'd like to contact me to work through this, working directly with your code, you can email me directly at thoward37 (at) gmail (dot) com ...

Also, this is the kind of discussion that belongs on the lucene-user mailing list. Perhaps we should move it there? That way others can benefit from the answers here, and others can contribute to answering if there's something I can't help with.


# re: Lucene.Net needs your help (or it will die)

Left by Troy Howard at 11/7/2010 1:00 AM


Regarding GetTerm()... Getting the terms from the queries should be straightforward, but will need different migration depending on what queries you're using and how you're working with the returned terms.

Also, the Next() enumeration should be very straightforward. Following with the best practices we're already used to, reusing instances of Token (as we already do with Document and Field) will be much better for resource usage. In this case, replacing your calls to Next() with a call to Next(Token) that passes in a reusable Token will probably be the easiest route to go.

# re: Lucene.Net needs your help (or it will die)

Left by Troy Howard at 11/7/2010 1:02 AM


As for the ConstantScoreRangeQuery/RangeQuery... Those two classes are essentially the same, but ConstantScoreRangeQuery had better performance, but didn't include scoring in it's analysis. RangeQuery did include scoring. The new API changes how scoring is handled and refactored it into a new system, thus removing the need for different Query classes with differen scoring behaviours. That's now up to the Scorer.

Also, both RangeQuery and ConstantScoreRangeQuerysimply did string comparison on Terms. Your existing usages can be replaced with TermRangeQuery pretty much directly, and it will have the constant scoring behaviour (it's built-in to default to that).

NumericRangeQuery allows you to treat the "term" as numeric data and get different (aka correct) comparison behaviour. Your probably don't need this class as your existing usages would all have used string based comparison in the old API. If your range query was covering dates or some other numeric type, you may want to migrate into this type of query to make everything a bit more sensible (no need to have specially formatted strings to get correct sorting behaviour, and it reduces index size, because your date field data can be stored as a numeric value instead of strings.. Big gains there!).

# re: Lucene.Net needs your help (or it will die)

Left by Jean-Sylvain Boige at 11/8/2010 12:52 AM

Hi Troy,

Thanks for your detailed answer.

As you noticed, those left warnings are those that I thought would need more precision than what our current code base holds. That's also the reason why I postponed them, considering that it works as is for now.

Also, so far as I can remember it seems slightly better that what I had feared, which is relieving. Anyway, we can move any more details to the mailing list as you suggested.

Now about your proposal. I'm definitely interested. I'll send you our code base if that's fine with you, together with targeted explanations so that you don't need to figure out the context by yourself (the main assembly is about 1/3rd in size of Lucene.Net.dll).

However, it would probably make sense if you can step in the code at runtime.
Our product is a DotNetNuke module/provider, do you think you can you get a local instance running to install the package?

Thanks again,

Jean-Sylvain Boige

# re: Lucene.Net needs your help (or it will die)

Left by James Curran at 11/10/2010 10:41 PM

Note that the "renamed it and put it on CodePlex" option has already been put into action:

# re: Lucene.Net needs your help (or it will die)

Left by admin at 11/11/2010 10:21 AM

Seems like the founder of the aimee project nailed down the reasons why Lucene.Net is in such a shortage of contributors: it is not a .NET implementation of Lucene, is just a java application "recompiled" (ok, not really just recompiled, but you get the idea) for .NET.

And also another project started with the same idea:

Seems like developers on .NET care about their API conventions :)

# re: Lucene.Net needs your help (or it will die)

Left by xp registry repairs at 11/19/2010 6:43 AM

I never heard about this before! Anyway, thanks for sharing such informative blog post like this and I'm looking forward to the next one! Thanks for sharing!!!

# re: Lucene.Net needs your help (or it will die)

Left by enjoyLucene at 11/22/2010 8:21 PM

I've worked on Lucene and Lucene.Net (from version 1.9.0) onwards for last 4 years.

I performed several code changes to the Lucene.NET Framework to make it little faster. Finally, I was able to execute all test cases of Lucene.NET (315 of them at that time) in just 6 Seconds with NUnit. Which is even approx. 10 times faster than the Lucene Java .

These are my observations to Lucene.NET and Lucene Java implementation:
1) At Core, it is a nice gem of software engineering effort started by Doug Cutting.
2) I think, the way of deferred executions (for eg., TermEnum and Hits) implemented in Original Java version, is due to language limitation.
It can be smoothly ported to deferred executions offered by CLR 2.0 or 4.0.
3) Analyzers are also needed to visualize as .NET lambda enabled implementation. Currently, because of original java based approach, it is still class based approach.
4) Query and its parsers can also be easily improve by just eliminating Exception based State detection (produced by JavaCC) , by changing to CsFlex grammar
5) I think, current dev version of Lucene Java,i.e., 4.0 is becoming more aware about distributed Computing at its Core. For eg., IntsRef and BytesRef etc. V4.0 is also offering several significant but missing features, (DocsEnum, DocsAndPositionsEnum, Codecs etc.)
So, version 4.0 may be a nice starting point for the reimplementation effort, to achieve maximum benefits from our .NET framework.

Please share your thoughts.

# re: Lucene.Net needs your help (or it will die)

Left by John at 12/26/2010 6:08 AM

Honestly I have never understood why people bother to spend their time on contributing to open source projects. I've never seen an industry so full of people so willing to give away their work for no cost at all... surely your time is worth something? All this accomplishes is cheapifying all of our careers. I don't get it. I really don't.

And it leads to horrifying scenarios too. My company is now obsessed with building our software on top of open source because the bean counters are convinced that is cheaper. So we don't hire enough devs, then make promises based on the underlying software... which is always a disaster. Every time we crack open one of these things, it's just a stupefying mess, and trying to customize anything for our needs inevitably takes far longer than if we had just built it ourselves. But we're the ones who get blamed for it. I don't know what the heck they were thinking... you get what you pay for!!!!

And yeah I've heard the "it's a valid business model, you sell support!" argument. It's bunk. When a company makes all of its money off of selling support for a product, instead of selling the actual product, guess what happens? The company now has an incentive to make their product as incomprehensible as possible, because that'll make more people buy support! Terrible idea. TERRIBLE. As I said above, we end up getting these spaghetti code monstrosities, take forever to figure them out, if it's even possible to do so, and often end up having to fork money over to the company for added support work because their API was documented so terribly or just doesn't work the way it says it should.

Bah. I just will never understand open source. You make a product... there's nothing wrong in charging for it. It's insane to think otherwise. No other industry on the planet is there a comparable mindset.

Comments have been closed on this topic.