Tag: Open Source

Nextcloud: Open source file sync and share

Nextcloud Files is an open source solution for file sync and share. Think Dropbox, but distributed under an open source license (GNU AGPLv3) and installed your own servers. Today I decided to see what their latest release, version 13, has to offer.

Much like any web-based file sharing app you’ve seen, upon logging in to Nextcloud a user is presented with a list of their folders and files. Unlike more general Document Management or ECM repositories where the default mode of operation is typically that there is this giant repository of everything that a user may or may not be able to see, Nextcloud, by default, is user-centric–users see their own folders and files and chooses to share those with one or more team members.

With that said, there is a “group folders” feature that allows administrators to define folders shared by groups of users. That feature is not enabled by default, but it can be turned on in a couple of clicks.

The functionality is what you’d expect from basic file sync and share. You can:

  • Drag-and-drop one or more files into a folder to upload
  • Move, copy, and rename files and folders
  • Preview PDFs, images, and other file types
  • Share folders and files with users and groups, including setting an expiration date after which the item is no longer shared
  • Tag folders and files
  • Favorite folders and files
  • See a filterable activity stream of recent activity
  • Recover deleted documents from the trashcan

In addition to the browser-based user interface, iOS and Android users can download the Nextcloud mobile apps. Windows, macOS, and Linux users can download a desktop app. Regardless of your platform, these apps sync content between your devices and the Nextcloud server. Nextcloud also supports WebDAV, so if you already have a WebDAV client you like, you can use it to manage your files in Nextcloud.

There are a number of useful administrative features in Nextcloud, including:

  • Configuring authentication to leverage LDAP/AD
  • Server-side encryption of data at-rest (although the docs say this is not supported for group folders)
  • Linking to external storage using providers such as Amazon S3, FTP, OpenStack Object Storage, SMB, and WebDAV
  • The ability to federate your Nextcloud server with other Nextcloud or Pydio servers
  • Outlook and Thunderbird integration

If there are features you’d like to see that are not installed by default, they might be available in a community-developed app. Administrators can browse the currently installed applications as well as search for new applications to install without leaving the Nextcloud application. Noteworthy applications include integrations with Collabora Online and ONLYOFFICE, which are two online office suites similar to Google Docs, Metadata, which is an app for showing metadata extracted from files such as images, and Deck, which is a Trello-like kanban board for project management.

If there is nothing in the Nextcloud app store that meets your needs you can always develop your own. The Developer Documentation includes a small tutorial and API documentation.

Installing Nextcloud is quite easy. All you need is a web server, PHP, and a database such as MariaDB or PostgreSQL. The Administration Manual includes installation details. Leveraging that, I had everything up-and-running on an Ubuntu server in about ten minutes.

For the tinkerers in the crowd, you might be interested in Nextcloud Box. It is essentially a case, a hard drive, and a place to put your own Raspberry Pi (model 2 or 3) running the Nextcloud-provided microSD card. Once assembled you’ve got yourself an open source file sync and share server that looks great, is energy efficient, and removes the middleman from your file sharing needs. I’ve got a Synology Diskstation that I really like, but I love the open source DIY aspect of the Nextcloud Box.

Will it work for an “enterprise”?

To be sure, Nextcloud is not a full-scale, Enterprise Content Management repository. But not everyone needs one of those. What is it missing? A traditional ECM repository typically includes features like:

  • Custom metadata models
  • Fine-grained access control
  • Workflow/business process management
  • Standards-based, RESTful API (beyond WebDAV)
  • More complex transformation and rendering options
  • Full-text search out-of-the-box
  • Rules, events, or other “hooks” where custom logic can be added
  • Records Management functionality

Maybe you need those features and maybe you don’t. I often see people install and maintain a traditional open source ECM repository only to use its very basic file-sharing features, never progressing beyond that. If a company is early in its “ECM maturity” and plans to eventually take advantage of the more powerful features, then it’s acceptable to under-utilize your ECM platform for a time. But if the organization just needs a glorified file share that has good sync and sharing functionality with a nice user interface and the ability to manage files via WebDAV, Nextcloud might be the perfect fit.

I should also add that if you don’t want to support Nextcloud yourself, the commercial company behind the project has various pricing plans available based on the number of users and the SLA required.

Activiti founders fork the project to create Flowable, an open source BPM engine

flowable-with-taglineOn Thursday the news broke that Activiti had been forked to create a new open source Business Process Management (BPM) engine called Flowable. Activiti is a BPM engine that Alfresco Software, Inc. funded to replace JBoss jBPM. The Activiti engine can automate business processes as a standalone application, but it is also the embedded workflow engine that Alfresco ships as part of its ECM platform.

A fork is when the evolution of an open source project intentionally diverges. Instead of one code base controlled by a single entity, a fork creates a second code base from the first, allowing each project to evolve separately going forward in accordance with their own distinct roadmap and governance model.

Forks happen fairly frequently, and in places like GitHub, where a lot of collaboration around open source software takes place, they happen constantly, by design. But when a significant fork happens to a project, especially one that has commercial backing, like this one, it is worth taking note. Alfresco depends on Activiti for its ECM platform, so now it will be forced to either continue to develop Activiti under their own direction, or switch to the new project like any other upstream dependency.

The news of the fork comes about a month after my blog post reporting that multiple Activiti engineers had resigned from Alfresco. It is now public that those engineers were Joram Barrez and Tijs Rademakers, who were absolutely the heart and soul of the Activiti project. Those departures left a big question mark hanging over the future of Activiti.

Then the big news came on Thursday. Tijs Rademakers released this tweet, announcing a new project, Flowable, with a link to a blog post.

tijs-tweet

The blog post outlined some high-level reasons for the fork:

“We acknowledge Alfresco’s stewardship of the Activiti.org project, and as employees we enjoyed considerable freedom to develop the project over several years. However, things didn’t work out as we expected or hoped. We came to the conclusion the only way to continue evolving our ideas was to fork.”

The blog post goes on to talk about forks, in general, and their potential impact.

I wanted more detail so I spent some time talking to members of the new Flowable project last week to understand why they forked Activiti and what we can expect going forward.

The first thing that is immediately obvious when talking to any of the former Activiti engineers is how much passion they have for the project. Leaving Alfresco was clearly a hard decision. But the hardest part was feeling disconnected from the software they created and the fear that the project would no longer have the stewardship it enjoyed prior to their departure. “We couldn’t just leave it there,” said one of the engineers. Indeed, looking at the Activiti forum as well as the commits for Activiti on GitHub, it is obvious that Alfresco is still working to rebuild the Activiti team.

Activiti Commits

After their departure, the former employees continued to discuss with Alfresco Software how they might be able to move forward, but the two sides could not reach an agreement. It soon became obvious to the team that in order to move the project forward they would have to take more direct control, and the only way to do that was to fork.

Specifically, the team started with the latest Activiti release, 5.21.0, and added a new feature called “transient variables” and some other small enhancements as well as bug fixes, and released that as Flowable 5.22.0 (GitHub).

It’s actually not unlike the creation of MariaDB after Oracle acquired Sun (and then became owners of MySQL). In fact, it is the stated goal of the engineers for Flowable to be a drop-in replacement for Activiti, just like MariaDB is for MySQL.

The engineers say they are looking forward to getting back to their open source roots. “In true open source fashion, we want people to get involved in whatever way they can, whether that’s documentation, testing, or code contributions,” said the team. The Flowable project will run as a meritocracy, with trusted developers earning commit rights over time, regardless of their commercial affiliation.

The fork has actually made many people in the community a lot more comfortable with the direction of the project because the engineers who created the software and made the vast majority of the commits during its life are now committed to moving it forward, and this fork gives them the freedom to do it. “Everyone has been supportive so far,” the team said, “Now the burden is on us to start releasing.”

Clearly, Alfresco Software is unhappy with the fork. In a blog post published Friday, John Newton, Alfresco co-founder and CTO, said he was hoping for a different outcome:

“Unfortunately, some of my early friends on the Activiti project have disagreed with our direction and have taken the step of forking the Activiti code. This is disappointing, because the work that they have done is very good and has generally been in the spirit of open source. However, the one thing that we could not continue to give them was exclusive control of the project. I truly wish that we could have found a way to work with them within a community framework.”

John’s post indicates that the company intends to continue to develop Activiti. John writes, “We are redoubling our determination to grow Activiti faster, better and more openly.”

Growing Activiti faster will be key. If Alfresco is slow to field a new Activiti team and then fails to give the market what it wants at the pace it wants it, those stuck on a lagging codebase may become frustrated, particularly if Flowable is able to out-innovate Alfresco. Flowable has the advantage here because they are the original core team, they are more nimble, and they can hit the ground running. But without Alfresco as a sponsor, Flowable engineers must find a way to earn a living as well as move the project forward. Ideally they will be able to make the two intersect by finding clients to pay them to stay focused on the project.

Alfresco’s product and strategy depends heavily on Activiti. From a purely commercial perspective it is understandable they would want as much control over the codebase as possible. However, there are other commercial open source companies that have strategic dependencies on upstream open source projects they don’t fully control. Elastic’s dependency on Lucene comes to mind. If Alfresco could participate in the Flowable project in a similar way it could potentially benefit everyone, but John’s post seems to indicate that is not in the cards. The next few months will tell us just how committed the company is to continuing with Activiti as a separate project.

Personally, regardless of what happens with Activiti, I hope Flowable flourishes. If team member passion was the only predictor of success I’d say it’s a sure bet it will.

Why Alfresco follows the same strategy as closed source commercial software companies

soundwalk_by_finishing-schoolMy friend and colleague, Peter Löfgren, recently wrote a blog post on what he sees as the two possible strategies Alfresco could pursue. He describes the two approaches as follows:

Vertical: You try to get as many as possible Community installs be converted to paying Enterprise customers. Convert from the bottom and up if you so like.

Horizontal: You try to get as many as possible to run Alfresco, even if they run the free Community version. A fair share will always want commercial support to have a professional backing. A broad approach, where you get market presence and self-sustained marketing.

Peter argues that, to date, Alfresco has used a vertical approach, which is really about pushing Enterprise Edition and begrudgingly acknowledging that Community Edition is an acceptable alternative, only when the client can’t currently justify the expense of an Enterprise Edition license.

Peter observes that the vertical approach pits Alfresco Enterprise Edition squarely against Community Edition making it very tempting for Alfresco sales people to badmouth Community Edition, because they often see it as cannibalizing their revenue. I actually don’t see this happening much anymore–sales people know that denigrating Community Edition is counter-productive because customers are savvy enough to know it is the same software and a good portion of the sales team understands the bigger picture.

Before I go any further, I should refer you to a blog post I wrote about a year ago called, “The plain truth about Alfresco’s open source ethos“. In it, I argue that Alfresco’s marketing strategy isn’t the community’s concern, and that the company is basically a “normal” software company that won’t ever be the dogmatic open source company many of us wish it was.

But Peter brought it up and I like discussing such things, so I’ll ignore my own advice and provide my take on why I think Alfresco will continue to ignore the horizontal strategy and will continue to basically act like any other traditional software company…

Here’s my take

First, let’s compare Alfresco with another commercial open source company, Elastic. Elastic is the company behind the popular search engine Elasticsearch as well as a variety of related big data and analytics tools such as Logstash, Kibana, and Beats. Like Alfresco, Elastic makes money from support, and their incentive to get people to pay for support is to offer a set of products they make available only to paying customers. Unlike Alfresco, Elastic ships a single distribution of their products. For a given release of Elasticsearch, for example, there is no difference between what a paying and non-paying customer downloads and runs. It’s just that if you want some additional value-add on top of what’s freely-available, you have to pay.

So this is an example of a horizontal pursuit as Peter describes it. The reason it is working for Elastic, though, is that their offerings are much more horizontal than Alfresco’s. Elasticsearch is more popular and more widely used in all kinds of use cases. Their download stats are impressive and increasing steadily.

Alfresco, on the other hand, is niche software. It is quite narrowly focused on document management. Yes, there are a lot of use cases within that, but it isn’t something that you see embedded in all sorts of applications like you would a database, a workflow engine, or a search engine. I suspect download stats are flat or maybe even decreasing, although this is a bit of an apples/oranges comparison as the two products are in different phases of maturity and adoption.

The other issue is one of leadership. Elastic’s CEO, Steve Schuurman, exudes open source. He was a co-founder of SpringSource, for example. Both he and Shay Bannon, the creator of Elasticsearch, have said repeatedly that Elastic will always be open source and that they’ll never have an Enterprise-only distribution of their core software. That’s the kind of leadership I expect from a commercial open source company.

Contrast that with the current leadership at Alfresco. When former CEO John Powell announced his retirement, the board could have chosen someone with open source credibility like Elastic’s Steve Schuurman. Instead, they went with Doug Dennerline. He and his lieutenants have next to zero open source credibility or experience. It is clear they were brought on solely to take the company public. For them, open source is not a driving part of their worldview. Instead, their focus is simply to build a software company and take it public, employing whatever strategy gives them and their shareholders the biggest revenue numbers year-after-year. (I don’t mean to paint this in an overly-negative light–it is what it is. I’m just trying to point out the stark contrast in motivation and philosophy between the two leadership teams).

Unfortunately, a horizontal strategy does not necessarily equate to those kind of numbers. With Red Hat as the notable exception, it is hard to find a commercial open source company with financials that Doug, the board, and investors are looking for.

Do the math. Let’s assume there are 50,000 installs of Alfresco Community Edition. I have no reason to believe that is accurate–this is just an exercise. What kind of conversion rate would you expect? You’ll probably guess too high, forgetting that Alfresco is now very expensive, even for modest installations, and that the company is still working to add more differentiation in its paid offering compared to the free product. Let’s use 2%. So that’s 1,000 paying customers, which is roughly the number John Newton disclosed publicly in a keynote several years ago. It’s probably higher now, but remember that there is attrition we haven’t accounted for and those customers have to be earned year after year.

Now, what do you think the average sales price of Alfresco is across all of their paying customers? Again, just spit-balling, let’s say it is $100k annually. Multiply that times 1,000 and that’s “only” a company with $100 million in annual revenue. If you’re looking for a $1 billion IPO, that’s not enough. (If EMC sells Documentum to someone for 10x revenue I’ll have to update this post, but I think I’m pretty safe).

In a horizontal strategy, those are your levers: Total installs, conversion rate, attrition, average sales price. For example, using the horizontal approach, to increase revenue from $100 million to $300 million you would have to triple the number of Community Edition installs from 50,000 to 150,000. Alternatively, you could keep CE installs steady at 50,000 and instead triple your conversion rate from 2% to 6%. Which seems easier?

My bet is that rather than increasing total Community Edition installs, Alfresco will find it easier to increase the conversion rate by increasing differentiation between the two products, cutting attrition by implementing “customer success programs” and consulting, and continuing to put upward pressure on the average sales price by charging more for the core product and finding new paid add-ons to sell.

The horizontal approach Peter advocates may be the one we all wish would work, but I think that ship has sailed.

Would the commercial open source software you depend on survive a zombie apocalypse?

2596483147_58d6bae3b1_mPick a commercial open source software product that’s important to you. Now imagine that there’s been a global zombie attack. Fortunately, after much heroics and stylized cinematic violence, the attack is eventually thwarted. Unfortunately, it wasn’t soon enough. Everyone who receives a paycheck from the company behind your favorite commercial open source company is now a zombie in the steadfast pursuit of acquiring brains for food–they could care less about your sev one support ticket. The question is this: Can the open source software project survive without its commercial backer?

My blog readership consists of multiple audiences. For some of you, the question posed is interesting because your company depends on that software to run its business. For you, this is a “sole source supplier” problem with the primary concern being: If the software vendor goes away, is there another place I can get the same software?

Some of you are like me–you provide professional services around commercial open source software. The commercial company produces the software you deliver to your clients but may also provide other types of assistance such as marketing, business development, and training.

Still other readers might be classified as “community members” who give time and resources toward the project. Members of the first two groups are often members of this group as well. It is this group–the community–that becomes critical in answering this survivability question as we shall soon see.

Okay, so back to the scenario. Zombies attack. Zombies subdued. Sadly, all of the employees of our commercial open source software vendor are no more. Why is the question of survivability even a question? Remember, we are talking about open source software with a primary commercial backer. Your organic open source projects are safe from zombie attacks, for the most part, because there is no single company responsible for its development. For organic open source projects with a large, healthy community, the load of building and maintaining software is distributed across potentially hundreds or thousands of individuals employed by many different companies. Commercial open source, on the other hand, has a single company that pumps significant dollars into engineering, research and development, sales, and marketing. If that company goes away, there’s a clear risk to the project. Stakeholders need to understand this risk.

For the rest of this analysis, I’m going to ignore the very real investments commercial open source vendors make around marketing, business development, community management, and training. These things matter, of course, but they don’t matter at all unless you ship code. As the smoke clears from the zombie attack, the single most important thing facing the surviving stakeholders is getting out the next release.

Suppose our zombie-stricken company sold support for what was already an extremely successful open source project. There are many people who regularly make very significant contributions to the code base and documentation. There are lots of people answering questions in forums and on IRC. That healthy community means there is a viable population of non-zombies who will obviously mourn the loss of their former collaborators, but will no doubt bravely carry on.

Now, instead, imagine a commercial vendor who is really open source in license only–they lack a community entirely. There are exactly zero people outside of the company who know anything at all about where to get the code and how to build and test it, let alone the intricate details of how it works. It’s clear this project is doomed. Maybe someone would fork the code base and start a new company but that would be tough. Unlike what MariaDb did after the Oracle-MySQL acquisition, our scenario doesn’t allow a new company to bootstrap with experienced founders or engineers, at least those who were employed by the vendor at the time of the zombie attack.

From looking at these two extreme ends of the spectrum it is clear that the thing that allows the project to continue is the viability of the project as an independent open source project and that depends on the health and makeup of the community.

To answer this question–whether or not a commercial open source project could operate as an independent organic open source project–there are several aspects of the current community to assess:

Pre-commercial open source success. If the software project was a successful organic open source project before the commercial company appeared, this is a good indicator that if that company were to go away, the software project would survive.

Governance model. Is the software and associated trademarks under the control of an independent foundation? If so, that’s good–a lot of the details and processes will already be taken care of. Formal governance of this sort is designed around ensuring viability independent of a single commercial backer.

Number of external committers. How many committers are employed by the commercial company? If the answer is 100% that’s bad for survivability. In our scenario anyone working for the company is now a zombie which means there will be fewer experienced people to work on the next release.

Number of external contributions. What kind of contributions have typically come from the community? If it is low volume or mostly insignificant patches, this is another negative indicator. If the project stands a chance of survival post zombie attack it needs significant activity from independent contributors because that provides a population of people who are familiar with the technical details of the product.

Install base. A product installed in a large number of big companies would be ideal but even a few large “anchor” companies would be sufficient. The surviving community will need to pool its resources to move the project forward. If it is strategic to stakeholders with deep pockets, those stakeholders may be willing to invest in the software’s future.

Product complexity. The simpler, the better. When a product gets complex, its engineering team starts to specialize. A large community could do that too, but if the product is complex and the surviving community is too small, there may not be enough people who can go deep enough on every part of the system to maintain the entire thing. A complex product also requires more resources to test and build.

Upstream dependencies. If the product is a relatively thin veneer on a handful of well-known upstream dependencies, that’s good. It means you might be able to depend on some of those upstream communities for help. However if the system is complex and has a lot of smaller dependencies, it means the surviving community has a lot to learn and the upstream communities may lack the resources to be of much help.

Downstream dependencies. If the software is used by many other projects downstream, that’s a good thing because it significantly increases the number of people interested in keeping the project alive.

Company diaspora. How much turnover has there been over the life of this company’s engineering department? Low turnover means there will be fewer people in the market who know the deep dark secrets of the code base.

Community makeup. This is closely related to the “external contributions” aspect. If the community is mostly “power users” that’s a problem for survivability. What you need is a community that has a significant number of individuals who are passionate and technical enough to dedicate time and resources to moving the software forward. It obviously helps if the software is strategic to their employers.

You might assess your favorite commercial open source software and realize that it isn’t viable without commercial backing. That doesn’t mean it’s a bad company or a bad product. What it does mean depends on your perspective:

If you depend on the software for your business…

  • And you are evaluating the software for purchase, you cannot give “availability of source code” a much higher score against other alternatives because one of the benefits you derive from that–the ability to continue forward should the company go away–is less likely to be realized. (see “Why Clients Choose Open Source”).
  • And you already have the software installed, have a backup plan in mind should something happen to the vendor, just like you would a proprietary vendor. If you deem a major event to be likely, consider moving to an alternative now.

If you are part of the commercial open source software project’s community…

  • Push for changes in the aspects identified above that would make the project more viable as an independent project. Realize, however, that not all vendors are enlightened (or empowered) enough to execute these changes.
  • Be okay with the fact that you are dedicating time and energy to something that depends mostly (or entirely) on its commercial backing. This means not getting bent out of shape when the commercial company does something to further its commercial interests. Or don’t be okay with it and move on.
  • Assess your zombie attack survivability as a community and identify initiatives that address areas of weakness.

If you are the commercial open source software vendor…

  • Be careful how you market your open source-ness. If your software fails the zombie survivability test but you tout open source as a major advantage, your marketing message may ring flat.
  • Be open to ideas that could give your software the ability to outlive you. This makes it more attractive to customers and community members alike. It makes your open source claim more genuine.

Obviously the specific threat of a zombie attack is far-fetched. But the risk of a commercial open source company being acquired, folding, or radically shifting their business model is quite real. Just because “commercial open source” has “open source” in it, does not magically give it a vibrant community that can fulfill the vital engineering and quality assurance role that the commercial company often provides. Even a vibrant community may lack the proper make-up to step in should it need to.

Regardless of which role you play, if you are a stakeholder in a commercial open source software product, it is important you assess this risk and have a plan should the need arise.

How my teen-aged son became a Mozilla contributor

Jeff and Justin zip-lining during Mozilla Work Week in Whistler
Jeff and Justin zip-lining during Mozilla Work Week in Whistler
I’m in Orlando for Mozilla Work Week, which is an event that happens a couple of times a year aimed at bringing the organization’s far-flung employees and contributors together to collaborate on projects.

But I’m not here because of my own code contributions–I’m here as a chaperone. My 17 year-old son, Justin, earned his third trip to Work Week as an invited guest by dedicating time and code towards Mozilla’s mission of a free and open web.

Mozilla has thousands of contributors worldwide. Only a handful get invited to Work Week, so this is a Proud Open Source Dad Moment® for me, but I thought I’d share his story in the off chance that it motivates you or your kids to participate.

A few years ago Justin asked how he could get more involved in an open source project. He had just finished Google Code-In, which matches up High School students with open source projects. It’s a cool program, but it only lasts a few months and the projects he contributed to were somewhat esoteric. He was looking for two things in a project: it needed to mean something to him personally so that it would hold his interest and it needed to offer a technical ramp that would help grow his skills.

I told him to take a look at Mozilla. My own experience contributing to Mozilla was that they were good at getting contributors aligned with projects based on their skills and interests (check out their signup page).

At the time, Justin was new to coding. I had taught him Python but he wasn’t feeling confident enough to put those skills to use on a public project. So he started reviewing and editing technical documentation. This was a perfect place to start because it offered a chance to learn more about the culture of the organization and its tools and processes while also being exposed to the dizzying array of products, acronyms, and technologies in play at Mozilla.

(For more on teaching kids to code, see “Kids these days: Learning to code then and now“).

Then one day I walked into Justin’s room. He was hammering away at his laptop. “What are you working on?”, I asked. Without looking up he replied, “I’m writing some automated test scripts in Python using Selenium.” He was clearly “in the zone” so I just said, “Oh, cool,” and headed back down the hall, but I was pretty pumped–my kid was committing code.

Justin had found his way onto the Web Quality Assurance team. They make sure all of Mozilla’s sites are running correctly. This led to a cool father-son moment. I had been contributing some code to Mozillians, which is one of the sites Justin’s Web QA team was responsible for. Justin came to me with a problem: He could improve the efficiency of his tests if a small change was made to one of the site’s pages. He was reluctant to make the change but he knew I could do it quickly, so I did, and we ended up spending an afternoon hanging out in his room, squashing bugs and testing.

As his confidence and skills grew, so did his influence and responsibilities within Mozilla. He became a “vouched” Mozillian and, later, was added to some of the internal systems reserved for trusted contributors, and was ultimately granted the ability to commit code directly to Web QA’s projects. He participated on as many of the team’s online meetings as his school schedule would allow, began mentoring other contributors, and was given his own project to run.

This gradual increase in trust and recognition that occurs over time as a contributor spends time with a project is a key part of what makes open source work. He and I had discussed “open source” as a concept a lot, but it didn’t really sink in until he became part of it, and it has been wonderful to watch.

Something that’s been particularly instructive is how Mozilla treats its contributors. During a family vacation to San Francisco we toured both of Mozilla’s offices. Every person we were introduced to stopped what they were doing and thanked us. We felt special and appreciated.

This attention extends to code contributions. When I made my first contribution I worked with a mentor of sorts who helped me understand the workflow and coding standards for the project. If he didn’t hear from me in a while he’d shoot me a note to see if I still had time to work on the project. His continued interest made me feel like my contributions mattered, even if they were small.

Justin’s mentor went even further, offering career advice and making personal introductions. He’s even been helping Justin find internship opportunities.

When I think about everything his Mozilla experience has given him, I’m amazed. Of course he’s been apply to apply his coding skills in real world applications. But there is also a set of important technical skills that are hard to teach in a classroom, like how to be productive in a multi-developer git workflow. Perhaps more crucial are the softer skills, like how to give constructive feedback to teammates or how to pitch an idea. And the cool thing is that while he’s soaking up all of this, he’s helping further Mozilla’s mission, which is something both of us believe in.

If you know someone who believes in a free and open web, and they have the time and interest to get involved and to stick with it, encourage them to signup and get involved. There’s plenty to do for all skill levels and interests.

Kids these days: Learning to code then and now

300px-Epson-hx-20This little beauty is an Epson HX-20. It’s one of the first laptop computers. What makes it special to me is that its 4 line LCD screen is where I took my first coding steps in the early 1980’s.

My Dad was an IT guy. He’d bring home the Epson so he could work remotely. I’d been to his office before and had spent hours playing hide-and-seek in the data center with my sister or hucking write protect rings from mag tapes across the room like frisbees. To this day a raised floor and the smell of chilled, vaguely plastic, air brings back fond memories. But what he did all day at work was completely abstract to me until he brought that little Epson home.

Learning those first few lines of BASIC removed a lot of the mystery about how computers worked. It was clear I could tell the computer to do anything I wanted and it would follow those instructions to the letter. I quickly caught the bug and eventually got my own computer (We were a staunch Atari family–sorry Commodore fans!).

Fast forward 30 years…

Now I work in software and my own son is learning to code. When he was 12 or so he was running Linux on his laptop. Then he became interested in coding so I taught him Python. He has since picked up JavaScript, some HTML/CSS, and is now learning Java in high school.

When I think about his experience learning to code compared to mine, there are some similarities:

  • Exposure. He has access to various devices (laptops, PCs, Macs, tablets) and operating systems at home and at school.
  • Curiosity. More than using these devices for entertainment, he’s curious about how they work. I see plenty of kids with their faces buried in a tablet for hours on end. But if they don’t care to know how those apps or that game or that web site came to be they may not be ready to dive into coding.
  • Encouragement. What’s great is that not only does he have his Dad and Grandpa encouraging him to dive in, he’s got lots of teachers who understand the importance of code. (More on the curriculum in a minute).

So those are the ingredients that were the same for both of us. What’s different for this generation of kids learning to code? A lot, and it’s not just about ever-increasing computing power at lower and lower prices.

There are a ton of great resources kids have to help them learn to code these days. Let me call out some of them. I’ll put them in three buckets: Tools, Curriculum, and Communities.

Tools

When I learned to code the tools were virtually non-existent. I had a computer, the BASIC programming language, and a reference manual. Now there are all kinds of freely-available, cross-platform tools that are great for teaching kids to code. Here are a few.

For many kids, Lego Mindstorms is a great entry point into coding. This is coding that feels like play. Mindstorms comes with a drag-and-drop programming app that you use to build apps as if you were assembling building blocks. The app is then downloaded to the robot and boom–the kid sees their own creation obeying their commands.

If you don’t like the drag-and-drop IDE there are several traditional coding environments for a variety of languages that work with Mindstorms.

Scratch was the first coding tool my son was exposed to in school. Hosted at MIT, Scratch was purpose-built for teaching kids to code. Its graphical interface is similar to Mindstorms in some respects.

One of the things I love about Scratch is that kids can share their projects and use the projects of others as a starting point for their own creations. It’s never too early to start teaching kids about open source-style collaboration!

Alice is a story-telling tool. Kids manipulate 3D objects on a canvas. By giving instructions to the objects in the virtual world, kids learn the basics of object oriented programming.

Jeroo is another tool that teaches kids programming by manipulating objects in a virtual world. In this one you have an island. On the island are these mammals–Jeroos–who like to eat flowers. Coding lessons involve instantiating instances of Jeroos and getting them to eat instances of flowers.

Whereas Scratch, Alice, and Jeroo are similar to multiple object-oriented langauges, Greenfoot is about teaching kids a specific language: Java. Working in Greenfoot students write standard Java to build all kinds of programs. It’s a nice tool for learning Java before moving into a full-fledged IDE.

The RaspberryPi is a tiny computer and a code-learning tool all wrapped into one for $25 – $35. About the size of a credit card, you plug this little guy into a keyboard, mouse, and monitor and you’ve got yourself a Linux box with 512 MB of RAM that’s ready for code. Python, Java, C, C++, Ruby, Scratch are all installed by default.

Curriculum

I grew up in a small rural town. In the mid-80’s, my high school computer science curriculum consisted of a year of typing (on these things called typewriters) and a year of programming. The programming class was divided into a semester of typing and 10-keying (this time, on a computer) and a semester of BASIC.

In our school system programming starts fairly early in 7th grade using tools that don’t really feel like coding and then is offered every year, gradually getting more complex throughout high school.

Here is the curriculum by grade. I’ll include rough age equivalents so my readers outside the U.S. can map it to their grade levels:

  • 7th Grade (~13 years old): Technology, Tools: HTML, Scratch, Alice
  • 8th Grade (~14 years old): Principles of Communication in Business & Technology, Tools: HTML, Scratch, Alice
  • 8th Grade (~14 years old): Engineering, Tools: Google Sketch-Up, Lego MindStorms, Vex Robotics
  • 9th Grade (~15 years old): Pre-AP Computer Science, Tools: Scratch, Alice, Jeroo, Greenfoot (Java)
  • 10th Grade (~16 years old): AP Computer Science, Tools: Eclipse (Java)

Unfortunately, that’s it. Nothing is offered beyond AP Computer Science.

Community

When I was a kid there was no Internet, CompuServe was out of my financial reach, and Bulletin Board Systems were just taking off. That meant learning to code (especially in a small town) was largely a solitary pursuit.

With ubiquitous network connectivity, today’s kids have instant access to a globally connected community of learning resources, mentors, and others who are also learning to code. Here are a few examples of resources and communities my son has found helpful:

  • Codecademy is a community of educators and students. There are courses on Python, JavaScript, Ruby, HTML, and others, all available for free.
  • Khan Academy is another free learning community that offers computer programming.
  • Once kids know a little bit about programming, if they are interested in learning Python, my son found Google’s Python Class very useful.

The Role of Open Source in Teaching Kids to Code

Open source software plays a huge role in teaching kids to code. All of the tools I’ve mentioned in this blog post are open source and freely-available. But, more importantly, kids can dig into the hundreds of thousands of open source projects that are out there to see how they work and, eventually, to participate in those projects by writing documentation, helping with QA, and coding bug fixes. Open source doesn’t care how old you are. Mozilla, in particular, has been a wonderful and supportive project that my son has been participating in.

One of the ways high school students can get introduced to open source is through the Google Code-In. Each Fall various open source projects create a bunch of tasks they need done. Students participating in the Code-In work on these tasks. Tasks might be things like writing documentation, creating unit tests, working on a web site, you name it.

At the end of the Code-In, the open source projects select the students who made the most and best contributions and those students (and a parent) are flown to San Francisco for a tour of the Googleplex.

Encourage Your Kid and/or Somebody Else’s Kid

Today kids are exposed to computing nearly all day, every day. A small percentage of them will be curious enough to want to learn how it works. You can use some of the tools and resources I’ve listed here to encourage them to dive in and you can get them plugged in to open source and code-learning communities on the Internet so they can dig deeper on their own.

The hardware, software, and network have changed a lot since I was a kid, but one thing hasn’t changed: A wonderful world of discovery and opportunity awaits for young coders.

This week, December 9 – December 15, is Computer Science Education Week. They are encouraging people to spend an hour teaching someone to code. They’ve got tutorials ready to go. All they need is your time!

What tools, resources, or communities has your kids leveraged as they’ve learned to code? How does your local high school’s computer science curriculum differ from this one? Let me know!

Three watershed moments in my career (Hint: One just happened)

I’ve recently made a big shift in the career department. But rather than tell you what it is right off, I want to build up to it. I think it’s kind of a cool story, so if you’ll bear with me, here are the three watershed moments of my career thus far…

Watershed moment #1: Specialization leads to consulting

In 1992, I graduated college and went to work for Texas Instruments working on mainframes. Somehow, I got exposed to Lotus Notes development. I loved it. I dove in deep, eventually leaving for a job where I could be completely focused on Notes. Notes taught me a lot about managing unstructured data and how people collaborate to get work done. I learned that, for me, interesting IT problems are those where humans and systems have to work together to get something done. And it taught me a lot about what a passionate technical community looks like. Ultimately it led to a job at a small, but up-and-coming consulting firm where I would spend the next nine years. That decision to focus on Notes development was a watershed moment.

Watershed moment #2: My blog gets me a job in open source

Fast-forward to 2001. My content management practice was making a shift. Notes was falling out of favor and many of our clients were looking at WCM and DM solutions from large proprietary vendors. We started looking at open source technologies as well, but it was a tough sell to our traditional clients who had never heard of open source, and if they had, were skeptical or even fearful. We started implementing Documentum-based solutions and did that for the next three years, but I continued to dabble in open source. A revolution seemed afoot, but I couldn’t figure out the best way to jump in.

I started blogging in 2001, stopped, then started again in 2002. My rationale was simple: Writing helped me learn. And, for virtually no added cost, I could multiply the benefit by sharing what I learned–particularly with coworkers, but if others got value out of it, that was okay too. The idea that if my writing helped enough people it might help the open source movement in some tiny way was a romantic notion, but seemed remote.

Then I came across Alfresco. In October of 2005 I wrote my first Alfresco-related blog post. It said simply, “Alfresco is an open source enterprise content management solution founded by one of the co-founders of Documentum,” and then included a lengthy excerpt from a Gilbane post on Alfresco’s release candidate. A month later I published a more detailed review of the product. After three or four years of blogging, I was starting to find my voice. Little did I know that I had also found a passion.

By 2006, my firm had been acquired and Alfresco was starting to look like it had legs. I looked back on my past Documentum projects and realized that Alfresco was a viable alternative as the underlying repository in every case. Open source had been around for years but it had been sneaking quietly in the back doors of my clients in the form of operating systems, developer libraries, databases, and tooling. Alfresco, and other commercial open source companies, were poised to crash through the front door with business-facing open source applications. I wanted in. I left my firm to join Optaros, an open source consultancy I had discovered through fellow content management blogger and then Optaros employee, Seth Gottlieb. My blog had gotten me a job working with a technology I loved. That was the second watershed moment.

Watershed moment #3: Wait for it…

My four years at Optaros gave me the opportunity to focus on Alfresco full-time. Not just implementing projects, although there were many. Just as important, I was able to fully-engage with the Alfresco community. I wrote blog posts and tutorials. I created add-ons and integrations and released those as open source projects. I wrote a book. I conducted code camps. I attended every event Alfresco ever put on and gave talks at most of those. I didn’t set out to be an evangelist, but that’s what I became. Did it benefit me, Optaros, and later, my own start-up, Metaversant? Of course it did. But, here’s the kicker: Acting in my own self-interest turned out to be a huge benefit to the greater Alfresco community. And I’m not alone. Many people all around the world are participating in the community in all kinds of ways to everyone’s mutual benefit.

Which brings us to the next watershed moment: Alfresco has hired me as their new Chief Community Officer. My mission is essentially to make the Alfresco community an example for all other commercial open source companies to follow. It’s a significant challenge, and I’m going to need your help. Alfresco may sign my check, but I work for the community. Therefore, you’ve got to tell me where we should take this thing. We have our ideas but yours are critical.

What this means

I’ll give specifics on how you can help in a future post. I expect that the specific strategies we undertake together will fall roughly into these buckets:

  • Motivating community members, regardless of skill set or relationship to Alfresco to engage more deeply in the community
  • Enabling the community with tools, resources, and product enhancements that leverage community contributions
  • Exposing the greatness already existing in the community, whether that’s in the form of contributions that have been made that people just don’t know about or shining a light on community contributors doing awesome things

And, of course I get to continue to work on my own community contributions like my work with Apache Chemistry, my Google Code projects, the blog, and new stuff I haven’t even thought of yet.

It was a tough decision to put the growth of my content management-focused consulting firm, Metaversant, on hold, but when Alfresco approached me about this opportunity, I had to take it. My career and my passion are already dovetailed. I do what I love, and for that I am very lucky. Who wouldn’t take the opportunity to make that an even tighter fit?

I am very excited about what this means for the community and the importance Alfresco places on its growth and well-being. I hope you are excited too. Actually, “hope” is the wrong word–I need you to be excited. Who’s with me? Ready to pitch in?

Now available: Alfresco Fivestar Ratings add-on for Alfresco Share

A couple of weeks ago I posted a survey asking if anyone saw any value in a five star ratings widget for Alfresco Share. Honestly, it would have only taken one or two positive responses–even if no one needed one, there’s value in it for example’s sake. It turns out about 20 readers of this blog voted positively, so I went ahead and knocked it out.

This Alfresco Share customization makes it possible for any document in the repository to become “rateable”. When a document is rateable, the Alfresco Share user interface will show a clickable five star ratings widget. The stars light up to indicate the average rating for that document. Users simply click one of the stars to post their own rating. When clicked, the widget refreshes itself with the updated average.

Here is a short screencast that demonstrates the customization. You’ll want to make it full screen.

To implement this, I took the Someco Ratings Service from the Alfresco Developer Guide, moved it to the Metaversant namespace, and changed the names of my Spring beans and JavaScript root variable. Even though my initial target Alfresco version is 3.3, I didn’t want the code to conflict with Alfresco’s new back-end-only ratings service in 3.4 which uses some of the same names that were in the book. I also changed the JSON that the ratings web scripts use to be closer to what exists in 3.4. That way, when I do make a version that works with 3.4, it could potentially work with either my ratings back-end or Alfresco’s.

I then went to work on the UI side, integrating the widget into Share’s document details page, document library (both Share and repository views), search results page, and document-related dashlets. To go from what was in the book to a working integration I revamped the client-side ratings JavaScript from a set of functions to an actual object. Then, I started injecting my own methods into Alfresco’s client-side object prototypes to drop my widget in where appropriate.

Alfresco is still working to make customizations like this more modular and easier to plug in alongside their code and code from the community. Until then, be aware that if your Alfresco implementation already has customizations that override some of the same web scripts and client-side components this module does, there may be some manual integration needed. If you have an out-of-the-box installation (or a set of customizations that won’t conflict with this one) you can deploy the AMP to the Alfresco WAR and the Share customizations to the Share WAR and you’ll be set.

The Alfresco Fivestar Ratings project lives at Google Code. Feel free to check out the source, try it out, and use it on your projects. If you find a bug, log it, then fix it!

Apache Chemistry cmislib 0.4 incubating now available

Apache Chemistry LogoThe Apache Chemistry development team is pleased to announce that the 0.4 incubating release of cmislib, the Python client API for CMIS, is now available for download. You may have to use one of the backup servers until the mirrors fully update. Alternatively, you can use easy_install to install cmislib by typing “easy_install cmislib”.

This release has various fixes and enhancements that the community has contributed since cmislib joined the Apache Chemistry project with its 0.3 release. If you are using Alfresco, you might be interested in an enhancement in cmislib 0.4 that makes it possible to use ticket-based authentication instead of basic auth.

For those who haven’t used it, cmislib makes it easy to work with CMIS-compliant repositories from Python.

Any interest in a pre-3.4 five star ratings widget for Alfresco Share?

One of the examples I put in the Alfresco Developer Guide is a five star ratings widget. The example company in the book, SomeCo, uses it to let their web site users rate whitepapers published on the site. Metaversant recently took that code and implemented it in a production web site, and that client gave us permission to take the code (which wasn’t really changed that much from the book anyway) and release it as open source.

But in Alfresco 3.4 Community and Enterprise, Alfresco has implemented partial ratings functionality. Right now, it consists of the back-end, repository tier services and it is darn close to what’s in the book.

With the back end in place, I expect Alfresco to release ratings functionality in the Share front-end in an upcoming release. So, I’m somewhat reluctant to package up my ratings stuff and release it as it is partially obsolete in 3.4 anyway. On the other hand, it would give those of you on releases earlier than 3.4 a functional ratings widget, and, with some adjustments, I could make the front-end work with Alfresco’s rating service in 3.4, which would mean functional ratings in Share for those of you that have already upgraded.

If the code was ready to go, I’d just package it up and if only one person used it, great. But, the client we did the widget for was using a heavily customized version of Share–we didn’t integrate the widget into the out-of-the-box document library or document details page. That’s the last bit of work that needs to be done. Even if there is no interest, I might do it anyway just to have as an example. But, I’d be even more motivated if there were folks out there who would use it in their production implementations.

So what do you say? Any interest? Take the survey below and let me know.

Create your free online surveys with SurveyMonkey, the world’s leading questionnaire tool.