Apache NetBeans Proposal
wiki.apache.org
wiki.apache.org
I really think that Apache should stop incubating projects which were essentially discarded by their corporate owners. Successful OSS projects are either community projects from day one (HTTPd etc) or require (at least initially) strong interest and involvement of the company that donates the code. How can you expect a community to magically develop around an abandoned project?
We originally started with Apache. We went that way because we did not have relationships with Eclipse Foundation, the Orion project - a perceived competitor at the time - was already there, and concerns over IBM having an outsized dominance / influence over the community.
When we reached out to the Apache foundation to discuss the ways we could get our software into their foundation, building mentors, and also cross-project collaboration - we really struggled. We were unable to get the necessary endorsements. Apache was really bare bones governance. Because we couldn't get the right mentors, the proposal never made it out of an early proposal phase.
Serendipity at the time had me accidentally meat the Orion project lead at the Eclipse Foundation. Conversations ensued, and a path for how Che could come to be a reality with the support of other vendors that wanted to get involved was laid out. And that lead to our ultimate path into Eclipse and promotion there.
So this is an interesting back story about how one project ended up in Eclipse vs. Apache.
Interestingly, Eclipse is opinionated about the projects they promote. They are topically focused and work for project cross-pollination along with driving marketing initatives and IP policies around driving adoption of their core underlying projects. So that is a bit of a departure from the Apache approach where each product is more autonomous in terms of its underlying promotion responsibilities.
This plays a little bit to @dr_faustus comment on Apache being a place where many large projects are going - they can do that because the community already exists and they need the most structured infrastructure / process.
Maybe whenever there are a dozen or so companies trying to create a business model so they don't fight each other too much? Has that ever worked with the high profile Apache projects that people remember here (OpenOffice, CouchDB, etC)?
The biggest distinction is that Eclipse has an IP Policy where all of the code and assets has to have provenance of the code - either code submitted under a CLA, but if there are links to third party libraries, they are each independently reviewed by an on staff legal team. There are more details beyond this, but that level of human provenance review for every Eclipse project for it to be released, enables certain companies to more readily and easily adopt projects with not only an EPL license, but released as an Eclipse project with signed binaries on their hosted servers.
There are differences around mentoring, release process, hosting rules, infrastructure. But at the end of the day, it's about structure, rigorous rules, mentorship, and community.
"...we were searching for the right governance model..."
I am very interested in comparisons of governance models. Case studies, war stories, analysis, whatever.
I joined a team working on OSS specifically to learn more about governance. The stewards of kuali.org were a consortia. It was a train wreck. Least common denominator consensus based decision making, layers of hierarchy, no accountability, paralysis and inaction, abundance of NIH / reinvention, etc.
Tellingly, kuali is now kaput.
Sadly, I didn't learn anything actionable about governance.
I pick these three as they are foundations that have been long lasting and have proven an ability to retain member companies and a diverse set of projects.
The comparison would take a lot of effort to do but be worthwhile. You need to compare details as minute as around how web sites are hosted, how products are named, trademarking + copyright issues, provenance and IP policies around releases, mentorship, maintenance --- even things as formal as how issues are created, pull requests established, and how projects are organized among the committers.
The foundations can derive policy and rules at any level - and there is a significant variance depending upon the underlying charter of what the foundation is trying to promote. So the best place to start is the bylaws of each foundation, which are open source themselves, to understand the underlying motivation. Nearly all choices are made from the underlying principles.
Interestingly, the Eclipse Foundation is one of the larger revenue organizations from member contributions, but they do not have that many projects - maybe 300 or so. The IP provenance requirements are so stringent that many smaller projects turn away because they do not desire such a level of review. So the Eclipse Foundation is about to introduce a dual IP mode where projects can self-certify their IP provenance. The entire process around releases will be different can instead of taking weeks to make a release, could be done nearly instantaneously, allowing many projects that have a small group or open source license to become a project of the foundation, if that was a desire.
Apache is also a 501(c)(3) charity for the public good -- as opposed to a 501(c)(6) business league like Eclipse and the the Linux Foundation.
One of these things is not like the others.
Some exceptions to this are Apache Http server, tomcat, svn etc.
Yes they adopt a lot of code (OpenOffice!) and weird abstract crapware, but this is not quite the norm. If you measure the success of the average Apache project, I'm certain it is vastly higher than any comparable organization, although I'm not sure who you could compare Apache to.. GNU?
Wasn't Struts a once-popular non-failure whose time has passed; rather than a corporate failure that was "dumped"?
Costs are low -- for about 200 projects, the ASF runs on a budget of around 1.4 million USD per year. It doesn't take that much to give a community a home -- the community itself is primarily responsible for making things happen.
My biggest gripe with the Apache community sphere is it is pain to contribute (I mentioned it here as well: https://news.ycombinator.com/item?id=11121563) and there is often interesting politics that develop on the mailinglist between developers. It seems when you start talking but "organizational" + "community" things some interesting behaviors happen (like who is the head honcho and who should we kick out).
On the other hand Apache does offer some continuity (in the event something happens to a lead developer) I suppose.
Why is Apache taking these up / wasting time on them? So far all of them have died shortly after, with no significant improvements landing once Apache has taken over.
Although "entrusted" to Apache, they're still controlled by the same people who change their titles from XXXX Project Manager at BigCorp to Apache PMS Chair for XXXX. These people are often the reason the project funding is cut off, and they'd rather keep control of a shrinking ecosystem than give up some control so the project can be saved, where they'd have a smaller share of a larger ecosystem.
Yeah I know this is an absurd concept (to some) that someone might use older than a few year old tech.
Being an Apache project means(to me at least) that the product is ready to use and someone has used it before with at least some success. I trust a random open source product much less than anything Apache.
Presumably they get some funding in return. It makes $$$ sense for those entrusting if they have an established user base they no longer want to support.
It's just you :)
Seriously though, that is a mistaken impression, bolstered by people who have a vested interest in that impression. Instead, Apache is a place where large open source projects of big companies go to build an independent and healthy community around the project. Sometimes it doesn't work out, for numerous reasons, but most of the time the change is one of the best things to happen to the project.
Netbeans was fine for a while and then better tools came out. I used Frontpage and Visual Interdev in the mid to late 1990s, discovered Netbeans later on. I remember downloading Netbeans with the Java SDK.
But I personally find myself using Apache Lucene by way of Apahce Solr quite frequently. If we were a bigger organization I'd likely look at Zookeeper and Kafka as well. Alas the library market can be a small and depressing market.
Besides, most Groovy downloads come from Gradle. Hardly anyone starts a new project with Groovy, it's become a niche language used exclusively to write build files.
Gradle 3.0, which came out last month, has replaced Groovy with Kotlin as its prefered choice for writing build scripts and plugins, so expect Groovy's use for build scripts to decrease.
I think Groovy will live long for scripting on the JVM, in the same way Bash is used for Linux. All the extra cruft Groovy bundles (e.g. MOP, static typing) will become irrelevant over time.
What I'm wondering is if they will succeed in keeping it very focused monolith as it is now, or some "design by commitee" will make it buggy monstrosity like Eclipse.
Maven projects are first-class citizens of NetBeans, which means that NetBeans can read POM files as NetBeans project files. NetBeans generates a small supplemental file (nbactions.xml) to cover the few project-related things the POM doesn't store (such as the name of the default main class or the path to the JVM), and it duplicates no information. IntelliJ, on the other hand, uses its own project format exclusively, it duplicates everything, and the IntelliJ project file regularly falls out of sync with the POM and has to be re-synced, which can be a nightmare.
At the company where we used IntelliJ, I ended up just using IntelliJ as an editor, and I did all my building by executing mvn on the command line (and we, as a company-wide thing, never ran projects in IntelliJ: we had special scripts for that). And the only reason I used IntelliJ there was because our coding standards were defined as an IntelliJ config file; if not for that, I would've just used NetBeans.
IntelliJ might be a better editor than NetBeans, and that's debatable because NetBeans is also a really good editor, but I simply cannot stand using IntelliJ for anything other than editing, while NetBeans handles non-editing tasks beautifully.
Me too, even for C++. Wish it had Dlang integration too.
One of the big differences with both NetBeans and Eclipse is that it's commercial software with nice non-paid offerings. But, for example, for my project Community Edition is not an alternative due to lack of JSP editing. NetBeans is great for editing JSP.
Other shortcomings of Community Edition are survivable. In my case this is Google App Engine support that with a lot of manual configuration can be made to run and debug in Community Edition.
Fadware with plugins. Plugins, upon plugins, upon plugins, upon plugins.
I mostly like Jetbrains, I just prefer Netbeans for the UX and Maven integration.
I was truly surprised by the code inspections (the "linter") and the depth of code analysis that it does. The first community edition would get stuck on some weird constructs from time to time, but every update improves upon it and I haven't seen the 2016 edition to have any issues with the weirdest code I have to maintain.
One of my favorite analogies is that Netbeans is the iOS of the IDEs and Eclipse is the Android. Eclipse supports way fore features than Netbeans but Netbeans "just works".
All in all, languages "shouldn't have IDE". They should provide services as separate apps that should be pluggable and used in any editor. That's something Go did well as it provides a code completion server and code quality tools and any dev can make a plugin out of them for any editor.
It makes things easier to develop and maintain for service developers, plugin developers and IDE developers.
I would love to be able to use Netbeans features without using Netbean itself, without being tied to the IDE.
https://www.redhat.com/en/about/press-releases/red-hat-coden...
I don't whether anyone is working on this for Netbeans, though.
The big piece that is missing is a language server registry so that any tool can discover, install and register locally a language service. That will come next.
According to the link:
> Language server registry: Language servers are published as part of a global registry, built by Codenvy as an Eclipse project and hosted by the Eclipse Foundation, to make language servers discoverable for any tool to consume.
Sounds pretty cool. It's certainly a sad state of affairs when we look at existing projects like http://editorconfig.org and see that it only really covers indentation; we programmers should be those most able to configure and improve our own tools!
I really think there's a lot of low-hanging fruit for improving the programming workflow, and I think it begins by decoupling basic functionality like this from the monolithic IDEs they've traditionally inhabited.
[0] https://plus.google.com/u/0/110981030061712822816/posts/KaSK...
Eclipse doesn't have a nice Swing/JavaFX UI designer like Netbeans does, EMAT isn't a match to the Netbeans profiling tools and the web tooling from Netbeans allows workflows not possible in Eclipse.
For example when editing JSF files you automatically get completion to the session beans, or JavaScript code. Editing JavaScript code takes into account the JSLint documentation and besides completion there is static analysis taking place as one types.
If anything Netbeans should be more attractive if it is released from Oracle.
Until the community around it solidifies and proves that it is committed and capable, it will probably be less attractive than when it was backed by Oracle.
Netbeans was always great for the more advanced Java platform features since it was "officially" supported and often the demo implementation for them.
I hope Oracle will continue invest in it because it is a polished platform. The profiling and sampling tools shared with visualvm are awesome.
Or maybe Oracle is just loosening the governance grip on the platform allowing some control for other organisations invested in the platform.
Time will tell.
Maybe we can even get a proper Python plugin out of this ;-)
It is one of the reasons why being part of Apache is attractive to projects.
http://www.apache.org/licenses/LICENSE-2.0#patent
An entity which contributes to an ALv2 project and then sues over a patent which reads on their contribution loses the the patent license grants from other contributors, effectively locking them out of the project.