Skip to content

Software Development News: .NET, Java, PHP, Ruby, Agile, Databases, SOA, JavaScript, Open Source

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Open Source

Characteristics of Great Open Source Documentation

SourceForge.net: Front page news - 1 hour 18 min ago

Where there’s an open source project, there’s bound to be documentation. But the question is, is it great documentation, or is it just “good enough”?

Documentation can often fall in the latter category, mainly because it isn’t given the proper respect and recognition that’s due. While documentation may not be considered the “meat” of a project, it certainly plays a significant role. Without it, you’d hardly have any users and contributions would cease to exist. And even if it is present, if it is not crafted well, it still won’t be effective in encouraging users and contributors.

It’s important therefore, not just to create documentation but to make it exceptional. Any less and it will fail to fulfill its purpose, which is to easily guide users and encourage them to use, share, adapt and contribute to the project.

Defining Greatness
In order to create great documentation, we must first define exactly what this “greatness” means. So what are the characteristics of great documentation?

  • Inclusive

The very nature of open source means that projects ought to be open to anyone who wants to use or change it. Documentation must therefore be as inclusive as possible. This means using simple, easy-to-understand language, making sure final docs are in the formats most users are familiar with and require, and offering clear invitations and opportunities for contributions.

  • User-friendly

Great documentation is not just read, it is easily understood and applied. To that end it needs to exhibit the three C’s : clear, consistent and concise. You have to use clear, unambiguous terms and keep the phrasing as simple and concise as possible. The less time readers spend trying to figure out what you’re saying, the more time they can work with your software and make meaningful contributions. It also has to be consistent: in word choices, in markup style and writing style. Apart from these three C’s, it’s important to offer documentation that’s less mechanical and more conversational, such as FAQs and blog posts. Offering samples and screenshots also goes a long way to making your documentation more user-friendly.

  • Tested

The best documentation is one that doesn’t need further clarification. One sure way you can achieve this is to test your documentation or better yet, have it tested by a beginner. By testing it you can check which areas are unclear, missing or don’t achieve intended results.

  • Forward-thinking

Aside from being accommodating to current users, great documentation considers the needs of future users. This means that you should keep word choices consistent to make future translations more efficient, be open to feedback and provide updates whenever it is needed.

These are just some of the most common characteristics of great documentation. In the end however, what really defines great documentation is how well it is able to attract contributors, enhance the quality of the code and grow the community.

What other features do you consider pivotal in great open source documentation? Share your thoughts in the comments section below.

Categories: Open Source

May 2016, “Staff Pick” Project of the Month – Arch Bang

SourceForge.net: Front page news - Thu, 05/05/2016 - 05:20

For our May “Staff Pick” Project of the Month, we selected ArchBang, a simple GNU/Linux distribution that provides a lightweight Arch Linux system combined with the OpenBox window manager. Mr. Green, the current developer of ArchBang, shared some thoughts about the project’s history, purpose, and direction.

SourceForge (SF): What made you start this?
ArchBang (AB): I took over development of iso for Will at the time to allow him to focus on his studies.

SF: Has the original vision been achieved?
AB: Mostly; we try to keep iso to a minimum with all the tools you need to install and set up archlinux.

SF: Who can benefit the most from your project?
AB: Newcomers to Arch, Linux or even more experienced users who want a comfortable portable system.

SF: What core need does ArchBang fulfill?
AB: [The need for an Arch Linux system] that’s light, easy-to-use, fast, and up-to-date (as possible).

SF: What’s the best way to get the most out of using ArchBang?
AB: Try it live or load and run from ram, get the feel of Archlinux without having to install, break or risk your own system.

SF: What has your project team done to help build and nurture your community?
AB: We tend to keep things friendly and light-hearted. [We] pride ourselves on helping out when we can or at least point a user in the right direction.

SF: Have you all found that more frequent releases helps build up your community of users?
AB: Not really noticed that so much; we aim to release every three months (seasonal) subject to any major changes in Archlinux.

SF: How has SourceForge and its tools helped your project reach success?
AB: [It has] allowed users to find and download isos easily.

SF: What is the next big thing for ArchBang?
AB: Working towards a system free iso…

SF: How long do you think that will take?
AB: Hopefully within a few months we can have a fully working release.

SF: Do you have the resources you need to make that happen?
AB: Always looking to upgrade hardware; builds currently limited to the power of my laptop.

SF: If you had it to do over again, what would you do differently for ArchBAng?
AB: For me keeping things light and gui free would be ideal.

SF: Is there anything else we should know?
AB: Special thanks goes to Oliver and Pablokal

Categories: Open Source

Lightning Workbench

Date Created: Wed, 2016-05-04 05:55Date Updated: Wed, 2016-05-04 09:17Submitted by: Loic Gammaitoni
  • Create modelling languages from scratch, following an agile design process read more
  • Provide intuitive domain specific visualisations to existing models read more
  • Seamlessly execute language specifications for both verification and validation purposes read more
  • Specify analysable and efficiently computable model transformations read more
  • Deploy in one click lightweight web editors for an easy access by your users of your language specification.
Categories: Open Source

XRay: a function call tracing system

Google Open Source Blog - Tue, 05/03/2016 - 15:58
At Google we spend a lot of time debugging and tuning the performance of our production systems. Some standard practices when doing this involves using profilers, debuggers, and analysis of logs and execution traces. Doing this at scale, in production, is difficult. One of the ways for getting high fidelity data from production systems is to build applications with instrumentation, and then reconstruct the instrumentation data into a form humans can consume (summary statistics, reports, etc.). Instrumentation comes at a cost though, sometimes too high to make it feasible to deploy in production.

Getting this balance right is hard. This is why we've developed XRay, a function call tracing system that has very little overhead when not enabled, but can be dynamically turned on and only impose moderate costs. XRay works as a combination of compiler-inserted instrumentation points which functionally do nothing (called "nop sleds") and a library that can be enabled and disabled at runtime which replaces the nop sleds with the appropriate instrumentation instructions.

We've been using XRay to debug internal systems, from core infrastructure services like Bigtable to ad serving systems. XRay's detailed function tracing has enabled several teams in Google to debug issues that would be really hard to solve without XRay.

We think XRay is an important piece of technology, not only at Google, but for developers around the world. It's because of this that we're working on making XRay opensource. To kick-start that process, we're releasing a white paper describing the technical details of XRay. In the following weeks, we will be engaging the LLVM community, where we are committed to making XRay available for wide use and distribution.

We hope that by open-sourcing XRay we can contribute to the advancement of debugging real-world applications. We're looking forward to working with the LLVM community and other projects to make the data XRay generates useful for debugging a wide variety of applications.

By Dean Michael Berris, Google Engineering
Categories: Open Source

eKite

Date Created: Tue, 2016-05-03 03:25Date Updated: Wed, 2016-05-04 09:16Submitted by: Felix Voituret

eKite is an Eclipse plugin that brings integration for Kite programming copilot for all text editors.

Categories: Open Source

May 2016, “Community Choice” Project of the Month – Libjpeg-turbo

SourceForge.net: Front page news - Mon, 05/02/2016 - 17:15

For our May “Community Choice” Project of the Month, the community elected Libjpeg-turbo, a SIMD-accelerated libjpeg-compatible JPEG codec library. D.R. Commander, the developer and maintainer of Libjpeg-turbo, shared some thoughts about the project’s history, purpose, and direction.

SourceForge (SF): Tell me about the Libjpeg-turbo project please.
D.R. Commander (DRC): Libjpeg-turbo is a high-speed JPEG compression/decompression library that implements the libjpeg API used by a wide variety of applications (both open source and proprietary.) libjpeg-turbo accelerates the most common compression and decompression paths for JPEG images by as much as 6x relative to libjpeg, through the use of SIMD instructions on x86, ARM, PowerPC, and MIPS CPUs. libjpeg-turbo is now included in most open source operating systems (soon including Android) and is used by popular web browsers (notably Firefox and Chrome), so most people reading this are probably using libjpeg-turbo on a daily basis, whether they realize it or not.

SF: What made you start this?
DRC: My other pet projects (VirtualGL and TurboVNC) are high-performance open source remote display tools for 3D applications, so they have always needed some sort of high-speed image codec in order to stream the output of 3D applications in real time over various types of networks. “Back in the day”, I was using vendor-specific high-speed JPEG codecs, such as the Intel Performance Primitives and Sun mediaLib, but these weren’t always open source. Miyasaka Masaru developed MMX and SSE2 extensions for libjpeg in 2006. The TigerVNC developers adopted his code and did some further work on it, then they hired me in early 2009 to add 64-bit SSE2 support and to add colorspace extensions for compressing from/decompressing to 32-bit buffers. Eventually this codec matured enough that I was able to “eat my own dog food” and adopt it in VirtualGL and TurboVNC. At some point, developers in the streaming video community caught wind of our work and encouraged me to spin off the “libjpeg/SIMD” codec into a standalone project, so that other applications could easily take advantage of it. Thus, in early 2010, libjpeg-turbo was born. Some of the earliest adopters of it, outside of the remote display community, were applications that monitor security cameras.

SF: Has the original vision been achieved?
DRC: I believe it has. In fact, in most cases libjpeg-turbo now out-performs those proprietary/vendor-specific JPEG libraries that I used to use “back in the day.” Furthermore, I believe that libjpeg-turbo has helped to further Tom Lane’s original vision for libjpeg. In the release notes for libjpeg v6b, the last version that he worked on, he mentions performance enhancements as being “of great interest” for future development. Tom’s vision was to encourage wide adoption of the JPEG standard by providing a ubiquitous and legally-unencumbered JPEG codec library. libjpeg-turbo further encourages wide adoption of the JPEG standard by making JPEG fast enough to use with real-time compression/decompression tasks, which previously weren’t possible with libjpeg. Because libjpeg-turbo implements the industry-standard libjpeg API, applications that were already written to use this API can, without modification, take advantage of the additional speed in libjpeg-turbo. New applications also have the option of using the TurboJPEG API, which allows them to more straightforwardly compress/decompress images without dealing with the complexities of the libjpeg API. The TurboJPEG API also exposes functionality that would be very difficult to achieve with the libjpeg API, such as compressing from/decompressing to YUV planar image formats and doing multiple lossless transforms on the same JPEG image. We are making JPEG a lot faster and easier to use, and this enables use cases that previously wouldn’t have been possible with open source tools.

SF: Who can benefit the most from your project?
DRC: Applications that need to compress/decompress JPEG images in real time (for instance, video applications or remote display applications) benefit the most from libjpeg-turbo. Those applications were previously forced to trade off better performance for better compression, but libjpeg-turbo allows them to have both.

SF: What core need does Libjpeg-turbo fulfill?
DRC: The need for an industry-standard, ubiquitous, easy-to-use, high-speed JPEG library. Both libjpeg-turbo and libjpeg v7 and later evolved from Tom Lane’s work (he was the sole developer of libjpeg v6b and prior); but whereas libjpeg in the post-Tom Lane era has moved in the direction of introducing clever but incompatible and non-standard extensions to the JPEG format, libjpeg-turbo has instead moved in the direction of greatly speeding up the functionality that was already there, and making it easier to use. Apparently a lot of people preferred our approach.

SF: What’s the best way to get the most out of using Libjpeg-turbo?
DRC: Applications that were written to use the libjpeg API should “just work” with libjpeg-turbo, but if they have to compress from/decompress to 32-bit buffers, then they can take advantage of the libjpeg-turbo colorspace extensions in order to increase performance even more. A lot of new applications are using the TurboJPEG API instead, because it’s so much easier to use (although it doesn’t support some of the more advanced features of the libjpeg API, such as buffered I/O.) It also goes without saying that libjpeg-turbo will be of the most benefit on CPUs whose SIMD instructions we support (x86, ARM, PowerPC, MIPS.) Also, it will be necessary to compress/decompress baseline JPEG images in order to achieve peak performance (SIMD acceleration for progressive JPEGs is still a work in progress.)

SF: What has your project team done to help build and nurture your community?
DRC: libjpeg-turbo is a one-person shop. Over the years, I have received some big code contributions, particularly for things like SIMD support on ARM and MIPS processors, but I’ve always been the sole maintainer and, with the exception of outside patch submissions, the sole developer. The libjpeg-turbo community initially formed on its own, because there was a pent-up demand for a library that furthered Tom Lane’s work without breaking backward compatibility with libjpeg v6b. Also, a lot of developers liked the fact that our project maintains a fully open code repository and issue trackers, things that have traditionally not existed with libjpeg. Since its early days, I have built the libjpeg-turbo community simply by being as responsive as I could to the needs of libjpeg-turbo users, and evolving the project in the direction that most of them seemed to want it to go.

SF: Have you all found that more frequent releases helps build up your community of users?
DRC: There’s always a balance to be struck between releasing too often and not releasing often enough. Our community of “users” largely consists of application developers, and they (as I) are more concerned with quality over quantity. Thus, libjpeg-turbo has traditionally fallen somewhere between ESR’s classic metaphors of the cathedral and the bazaar. Major releases are dictated by new features, and new features are dictated by community demand. I always strive to implement and release bug fixes as quickly as possible, but I take great care to ensure that all new features are fully vetted– that they truly solve a well-defined problem in as elegant a way as possible, without creating any backward incompatibilities or regressions. Above all, I want libjpeg-turbo (and all of my other projects) to have the maximum possible utility, stability, and performance. I treat performance as a measure of quality, so any drop in performance is considered to be a bug. Our releases are dictated by whether there are sufficient changes relative to the prior release to justify a new release, and I would much rather delay a release than put out something that is half-baked or irrelevant. I use a traditional release model, whereby I put out a beta release, a final release (usually 3 months following the beta), then usually one or two subsequent bug-fix releases (minor revisions) for each major revision. So to answer your question, it isn’t the frequency of releases that builds the community of users– it’s being responsive to what the users really want. They mostly want libjpeg-turbo to change only if the change is compelling, and they want assurance that these changes will be implemented elegantly, with an eye toward ease of readability and maintenance, and without compromising stability or performance.

SF: What was the first big thing that happened for your project?
DRC: Probably the inclusion of libjpeg-turbo in Fedora. I never set out to build an industry-standard JPEG library. Originally I just wanted to build a fast, open source JPEG library that I could use in my own remote display projects. Red Hat was the first one to include libjpeg-turbo in their O/S distribution, and it kind of snowballed from there.

SF: What helped make that happen?
DRC: In addition to its increased performance, many O/S distributors (including Red Hat) and application developers also gravitated toward libjpeg-turbo because it maintained backward ABI compatibility with libjpeg v6b. Thus, if an O/S was already using libjpeg v6b, they could switch all of their bundled applications to libjpeg-turbo without rebuilding them. libjpeg v7 and later broke backward ABI compatibility, and thus applications had to be recompiled if they wanted to switch from libjpeg v6b to one of the newer IJG releases. Backward ABI compatibility has always been a problem in libjpeg, because all of the structures in the API are exposed. However, libjpeg v6b was out there for such a long time before libjpeg v7 was released (more than 11 years) that the libjpeg v6b ABI became something of a de facto standard, and when libjpeg v7 broke backward ABI compatibility, that caused problems for a lot of developers and integrators. Many of them decided that the features introduced in libjpeg v7 and later weren’t compelling enough to justify breaking backward compatibility, so that drove them toward libjpeg-turbo, irrespective of the performance improvements.

SF: How has SourceForge and its tools helped your project reach that success?
DRC: I particularly like the file release system on SourceForge, because it helps me track the number of downloads for a particular release (which helps to gauge its rate of adoption.) Also, because SourceForge supports SSH, I can easily push new releases and pre-releases to SF as part of my automated build process. Back when the Allura transition took place, I suggested (and the SF developers implemented) several enhancements to the code viewer that helped me maintain my preferred code review workflow.

SF: What is the next big thing for Libjpeg-turbo?
DRC: I’m currently working on extending the library to support AVX2 instructions, which we’re hoping will increase performance by 20-30% on newer x86 platforms that support that instruction set. This feature is being enabled by code contributions and funding from Intel. Another project on the horizon is SIMD acceleration for progressive JPEG compression, which should speed up the compression of progressive JPEGs by about 2x.

SF: How long do you think that will take?
DRC: I expect that both features will land this Fall.

SF: Do you have the resources you need to make that happen?
DRC: The two aforementioned features are funded, but in general, I rely on donations and funded development opportunities to keep this project moving forward. I am an independent developer, so I don’t draw a salary for my work on open source projects. I do things that way because it allows me to keep these projects vendor-agnostic and free of any one organization’s agenda, but the downside is that I have to frequently ask for money in order to keep the lights on. Even if someone else develops a new feature and submits it as a patch, the best-written patches will still require many hours of work to clean up and integrate. It’s hard sometimes to make people understand that maintaining a high-quality open source project costs money, even though the software itself is free. In general, only about half of the work I do on libjpeg-turbo is paid for (either directly, through funded development and donations, or indirectly, through funding from my other open source projects that use libjpeg-turbo.) The other half is pro bono, and it’s a constant struggle to balance the need to move the project forward with the need to put food on the table.

SF: If you had to do it over again, what would you do differently for Libjpeg-turbo?
DRC: I would have probably chosen a different name. There has been a great deal of confusion over the fact that our project is called “libjpeg-turbo” but we provide an API called “TurboJPEG”. However, there’s too much traction at this point to consider a name change.

[ Download Libjpeg-turbo ]

Categories: Open Source

Projects of the Week, May 2, 2016

SourceForge.net: Front page news - Mon, 05/02/2016 - 05:05

Here are the featured projects for the week, which appear on the front page of SourceForge.net:

Octave-Forge

Octave-Forge is a central location for the collaborative development of packages for GNU Octave. The Octave-Forge packages expand Octave’s core functionality by providing field specific features via Octave’s package system. For example, image and signal processing, fuzzy logic, instrument control, and statistics packages are examples of individual Octave-Forge packages. GNU Octave is a high-level interpreted language, primarily intended for numerical computations. It provides capabilities for the numerical solution of linear and nonlinear problems, and for performing other numerical experiments. It also provides extensive graphics capabilities for data visualization and manipulation. Octave is normally used through its interactive command line interface, but it can also be used to write non-interactive programs. The Octave language is quite similar to Matlab so that most programs are easily portable.
[ Download Octave-Forge ]


WinPython

WinPython is a free open-source portable distribution of the Python programming language for Windows XP/7/8, designed for scientists, supporting both 32bit and 64bit versions of Python 2 and Python 3. Since September 2014, Development has moved to https://winpython.github.io/
[ Download WinPython ]


gnuplot

A famous scientific plotting package, features include 2D and 3D plotting, a huge number of output formats, interactive input or script-driven options, and a large set of scripted examples.
[ Download gnuplot ]


iDempiere

iDempiere = OSGi + ADempiere iDempiere Business Suite ERP/CRM/SCM done the community way. Focus is on the Community that includes Subject Matter Specialists, Implementors and End-Users. iDempiere is based on original Compiere/Adempiere plus a new architecture to use state-of-the-art technologies like OSGi, Buckminster, zk.
[ Download iDempiere ]


GnuCash

GnuCash is a personal and small-business finance manager with a check-book like register GUI to enter and track bank accounts, stocks, income and expenses. GnuCash is designed to be simple and easy to use but still based on formal accounting principles.
[ Download GnuCash ]


rEFInd

rEFInd is a fork of the rEFIt boot manager. Like rEFIt, rEFInd can auto-detect your installed EFI boot loaders and it presents a pretty GUI menu of boot options. rEFInd goes beyond rEFIt in that rEFInd better handles systems with many boot loaders, gives better control over the boot loader search process, and provides the ability for users to define their own boot loader entries.
[ Download rEFInd ]


NAS4Free

The NAS4Free operating system can be installed on virtually any hardware platform to share computer data storage over a computer network. ‘NAS’ as in “Network-Attached Storage” and ‘4Free’ as in ‘Free and open source’, NAS4Free is the simplest and fastest way to create an centralized and easily-accessible server for all kinds of data! NAS4Free supports sharing across Windows, Apple, and UNIX-like systems. It includes ZFS, Software RAID (0,1,5), disk encryption, S.M.A.R.T / email reports etc. with following protocols/services: CIFS/SMB (samba), Samba AD, FTP, NFS v4, TFTP, AFP, RSYNC, Unison, iSCSI, UPnP, Bittorent, Syncthing, VirtualBox and noVNC, Bridge, CARP (Common Address Redundancy Protocol) and HAST (Highly Available Storage). This all can easy be managed by a configurale webinterface.
[ Download NAS4Free ]


GNS3

GNS3 is a graphical network simulator that allows you to design complex network topologies. You may run simulations or configure devices ranging from simple workstations to powerful Cisco routers. It is based on Dynamips, Pemu/Qemu and Dynagen.
[ Download GNS3 ]


GeoServer

GeoServer is an open source software server written in Java that allows users to share and edit geospatial data. Designed for interoperability, it publishes data from any major spatial data source using open standards: WMS, WFS, WCS, WPS and REST
[ Download GeoServer ]

Categories: Open Source

Announcing the release of pglogical 1.1

PostgreSQL News - Mon, 05/02/2016 - 01:00

2ndQuadrant, the leading developers of PostgreSQL, are delighted to announce the release of pglogical 1.1 – the next generation in replication systems for PostgreSQL.

The 1.1 release brings new features along with bug fixes to pglogical. Same salient features are listed below:

  • Sequence replication support
  • Support for replica triggers
  • Foreign keys are no longer checked on the replica
  • Multiple subscriptions between single pair of nodes
  • The create_subscription function does not synchronize structure change by default
  • User can specify affected replication sets in replicate_ddl_command function
  • New functions for manipulating connection strings of nodes
  • PGLogical processes are clearly marked in the pg_stat_activity
  • Better behavior on worker crashes
  • Logging improvements
  • Ubuntu Xenial package

pglogical offers Logical Replication as a PostgreSQL extension, which provides the flexibility of trigger-based replication with the efficiency of log-based replication. This ground-breaking new technology has benefits for many key use cases

  • UPGRADE Upgrade PostgreSQL from 9.4 to 9.5, without downtime
  • SCALE OUT Copy all or a selection of database tables to other nodes in a cluster
  • AGGREGATE Accumulate changes from sharded database servers into a Data Warehouse
  • INTEGRATE Feed database changes in real-time to other systems

pglogical is open source and available for download as binary packages for PostgreSQL 9.4 and 9.5 versions. Visit http://2ndquadrant.com/pglogical/ for more detail.

2ndQuadrant’s respected 24/7 Production Support provides the fastest and highest rated response service for PostgreSQL anywhere and is available now worldwide.

2ndQuadrant leads the drive for improving the enterprise functionality for PostgreSQL, contributing major features every year in performance, replication, business intelligence and usability.

Categories: Database, Open Source

Dojo Recap – April, 2016

The Dojo Toolkit - Announcements - Sat, 04/30/2016 - 13:53

It’s been a very productive and busy year to date as work towards Dojo 2. This post contains a quick summary of the updates we’ve made!

Dojo 1.11 released!

In late March, we released Dojo 1.11, along with updates to 1.10, 1.9, 1.8, and 1.7. Visit the Dojo download site to grab a tarball, or use GitHub, bower, or npm to install the latest versions. Note that the Google CDN has been slow to respond, and has not yet updated to 1.11.1.

The upgrade from 1.10 to 1.11 should be very straightforward, as the release is primarily a bug fix release, along with the addition of the new flat theme and a small number of additions. See the complete list of bugs closed for this release or the commits within each repository (e.g. all Dojo 1.11 commits for more information on the release!

We received a tremendous amount of community support to make this release possible. Thank you for your help!

Note that a 1.11.2 release is planned for May.

High level Dojo 2 progress

The overall Dojo 2 progress is tracked at dojo/meta:

dojo/meta status

dojo/loader and dojo/compose are now in a beta state and dojo/core and dojo/dom, while still listed as alpha due to anticipated API changes, are very usable in their current state.

In the past month, the dojo/widgets prototype has been added, and feedback is greatly appreciated. dojo/actions is another recent package addition. Kitson Kelly and Dylan Schiemann gave a brief overview of dojo/widgets and dojo/compose at a recent London Ajax event.

Support for ImmutableJS and RxJS was also added to relevant packages within Dojo 2.

Detailed Dojo 2 updates

Over the past month, we completed the following:

Core loader dom compose parser meta dojo2-package-template Dojo 2 in progress

More than 100 issues are currently in progress. Some of the highlights include:

Please let us know if you would like to get involved! Either find us on IRC, leave a comment here, or start contributing on GitHub.

I’d like to specifically thank taoqf who has become actively involved through contributions and feedback on dts-generator, dom, meta, dstore, core and loader. We greatly appreciate the help!

Categories: Open Source, RIA

31 May 2016: NetBeans Day in London

NetBeans Highlights - Fri, 04/29/2016 - 11:29
Join NetBeans users all over the UK in London and learn about the latest NetBeans features while networking and getting to know others in this free event.
Categories: Java, Open Source

31 March 2016: NetBeans Day in Munich

NetBeans Highlights - Fri, 04/29/2016 - 11:29
Come to NetBeans Day in Munich, Germany, and meet great speakers and other NetBeans users, including Adam Bien, Jaroslav Tulach, and many others!
Categories: Java, Open Source

17 February 2016: NetBeans Day Netherlands

NetBeans Highlights - Fri, 04/29/2016 - 11:29
Free: Adam Bien, microservices, workshops, JavaScript, Java, and more! Join the latest NetBeans Day in the Netherlands.
Categories: Java, Open Source

NetBeans Community Approves NetBeans IDE 8.1 for Release

NetBeans Highlights - Fri, 04/29/2016 - 11:29
We are pleased to announce the results of the NetBeans IDE 8.1 Community Acceptance Survey that ended November 2nd: 85% of 89 respondents agree that NetBeans IDE 8.1 Release Candidate is stable enough to be shipped! A few respondents pointed out several serious issues. We evaluated them all not to overlook some important problem. We have noticed that majority of web programmers appreciate improved generic support for JavaScript development like enhanced Node.js support, debugging, inspection and especially testing and packaging so our investment into this area paid off. Another success worth mentioning is big (98%) satisfaction with redesigned Java Profiler. Check it out yourselves! Overall, this is a good news for the NetBeans IDE 8.1 from the community, and we thank all who provided this valuable feedback!
Categories: Java, Open Source

Build with NetBeans IDE, Deploy to Oracle Java Cloud Service

NetBeans Highlights - Fri, 04/29/2016 - 11:29
Save time and effort deploying applications. Learn to set up Oracle Java Cloud Service, then install and use the Oracle Cloud plugin in the NetBeans IDE.
Categories: Java, Open Source

Build a Rich Client Platform To-Do Application in NetBeans IDE

NetBeans Highlights - Fri, 04/29/2016 - 11:29
Practice using NetBeans IDE features that improve code quality and increase developer productivity.
Categories: Java, Open Source

Video: Installing and Using Java ME SDK 8.0 Plugins in NetBeans IDE

NetBeans Highlights - Fri, 04/29/2016 - 11:29
This screencast demonstrates installation and usage of Oracle Java ME SDK 8.0 Plugins in NetBeans IDE on the Windows operating system.
Categories: Java, Open Source

The Responsibilities of an Open Source User

SourceForge.net: Front page news - Fri, 04/29/2016 - 05:40

User.

There are a number of things that come to mind when we encounter this term. It could be a person who, quite simply, uses something. But it could also be a derogatory term, used to describe a person who has abused the use of something.

In the world of open source, the term “user” has been pulled toward both ends of this spectrum, between the former definition and the latter. In the end however, what it really is and what it needs to be is neither. In the world of open source, a user is more of a contributor with duties and responsibilities.

More than Just a User
Users are not mere recipients of open source software. By working with an open source project users automatically become part of that project’s development. Because open source projects don’t have the same areas of documentation, quality control and marketing that proprietary projects do, it needs added manpower for these areas. That’s where users come in.

The role of users is crucial to open source. It is one of the pillars that make open source what it is- a place where users are not simply users, but a community that’s building up and developing a project as it is being used.

What Users Ought to Do
This responsibility may seem intimidating at first . But if you’ve been in the open source space long enough, you’re probably already doing what is expected of any open source user, and that’s to contribute to the project. While this often means contributing code, this isn’t the only way one can contribute:

  • Testing the software and providing feedback on it is essential to refining the project’s quality, functionality and ability to meet users’ needs.
  • Reporting bugs is another significant way of improving the software without writing any code.
  • Creating documentation is another meaningful contribution. Even small ones like tutorials or articles posted on social media can be very helpful, and can also serve as marketing.
  • Speaking of marketing, this is another great contribution. If you’re fond of using the software and think it’s fantastic, let others know. Talk about it, write about it; you could even teach others about it through workshops and meetups.

There are plenty of ways that users can fulfill their role and be the responsible contributors that they ought to be in the area of open source. No matter how small, it is essential that users remember and act on their responsibilities as this is key to ensuring the continuation and effectiveness of the open source system.

SourceForge on User Contributions
Here at SourceForge, we highly encourage not just developers but also users to contribute to their favorite projects. Even the smallest contribution can be a big help in the long run. Still unsure of how you can begin giving back to open source? Stay tuned to SourceForge as we tackle this topic on our coming posts.

Categories: Open Source