"Tagging" has been a long-requested feature for managing content in Studio, and now OpenCraft is finally designing and building it for Axim Collaborative! While there are big plans, the first release will be a user-friendly, minimal viable product. Here are some of the things everyone can look forward to:
So, get ready for more organized learning content. Tagging will make it easier for you to find, curate, and build relationships between course content. Your learners will thank you too! Think of courses that are effortlessly searchable and primed for personalization.
Contact us if you’d like to know more about the project.
A feature that will be released soon is copying and pasting course content. Talk about saving content authors more time! OpenCraft is very excited to be involved in the UX and development of this project. Ultimately, the feature will allow authors to copy sections, subsections, units and components, and then paste them into different locations within the same course or into a different course. No more duplicate work - whoop!
Keep your eye on the Open edX forum for the official public release of this feature.
We’re proud to announce that during the first six months of this year, three more OpenCrafters were bestowed the Core Contributor title. We now have 13 Core Contributors!
The Open edX Core Contributor program allows members to participate in defining and deciding the direction of the platform through design, coding, marketing, and more. To become a member you need to embody commitment to the project, exemplary conduct, and high caliber contributions. Well done to the following three team members:
Code Contributors:
UX and UI Contributor
Meet our amazing Chief Technology Officer! Braden hails from Vancouver, Canada. When he’s not doing awesome things with code, you’ll catch him hiking the glorious mountains right on his doorstep.
Braden started his journey at OpenCraft in 2014. But his journey in open source started with his first contribution at age 14! He loves being a part of the Open edX community, and the community loves him! He was made a Core Contributor in 2020. Projects that have received a lot of his attention are things related to XBlocks and how they're stored, including Modular Learning and Content Libraries. In fact, he’s super happy about being involved with the Modular Learning efforts where he’s building functionality that he and the community have wanted for a long time. Braden particularly loves being involved in architecture discussions. You’ll often catch him being extremely helpful on the Open edX forum.
Outside of OpenCraft and the Open edX community, Braden likes to work on open source JavaScript/TypeScript projects. He’s a big fan of Deno, TypeScript, and Next.js. He’s also the co-founder of Neolace and TechNotes, and owner of MacDonald Thoughtstuff Inc.
As I mentioned, Braden is really active on the Open edX forum, so reach out to him there!
After an unforgettable Open edX 2022 conference and co-working retreat last year in Lisbon, Portugal, we were eager to see what our 2023 trip had in store!
As our team is 100% remote, these two weeks of the year are a great way to connect, catch-up, and meet new team members. Sadly, not everyone was able to join in the fun, but we still had representatives from Australia, Europe, Asia, North America, South America, and Africa. Here’s the lowdown on the two weeks we spent together.
This year, Open edX went back to its roots and hosted its annual conference at MIT, the birthplace of the Open edX project. In fact, the conference was held in the very same building in which the first lines of code were written for the platform. Sitting there 12 years later, you couldn't help but think how much the platform has grown and how far we've come as a community over the years.
As some of Open edX's biggest fans and most active contributors, the OpenCraft team makes an effort to attend the conference whenever we can. It's a wonderful opportunity for us to reunite with the people we work with during the year - both within our own team and the community at large. Also, because our team members are often selected as speakers at the conference, we get the opportunity to show off what we've been working on and share our ideas with the community. In turn, we get the chance to learn about what others have been working on. We often leave a lecture hall feeling inspired by the efforts of other community members and brimming with new ideas!
Four OpenCraft team members presented a talk this year. Xavier Antoviaque spoke about "Building Collaborative Courses" by involving learners in the course creation process. Braden MacDonald joined other members of the Product Development team to introduce the Modular Learning Initiative to the community and discuss how community input helps shape product development. Jillian Vogel joined Brian Mesick to share the progress of the OARS (Open Analytics Reference System) project: an ambitious effort to improve the analytics of the Open edX platform. Lastly, Piotr Surowiec discussed the work that went into migrating a comprehensive theme from a legacy frontend to the MFE. He outlined the key differences between the theming options in the comprehensive theme and the MFE.
Every year, the welcome address and keynote talks are some of the main highlights of the conference. For those of you who couldn’t make it to Boston this year, we’ve linked to the videos of these talks below:
When not presenting talks, participating in workshops, or meeting with our clients, the OpenCraft team managed to sneak in some good old-fashioned fun! We beat the cold by visiting the Cambridge Brewing Company (who, by the way, serve delicious fried Brussel sprouts that even devout haters of the vegetable would enjoy!). We embarked on a self-guided tour through the MIT grounds where we marveled at the Biomimetic Robotics lab, got chased out of the library, and walked the campus grounds alongside a group of Canadian geese. On Wednesday night, we attended the conference reception where we wined and dined within the walls of the MIT Museum. And on the last day, just to throw in a little bit of culture, we visited the Isabella Stewart Gardner Museum where we found each display to be more interesting and opulent than the last.
The conference went by in a flash, but we certainly managed to make the most of our time! Not only were we able to interact with the community in a way that remote collaboration doesn't always allow, but we also got the chance to strengthen our bond as a team - something money just can't buy! Once the 2023 conference had drawn to a close, we headed back to our Airbnbs to prepare for our next adventure: an OpenCraft co-working week in Bogotá, Colombia!
We arrived around the 1st of April, ready to have fun in the vibrant city of Bogotá. The Colombian capital is a whopping 2,625 meters (8,660 feet) above sea-level. We were warned that the city’s dizzying heights can give you a touch of soroche, or altitude sickness. So we made sure to take it easy the first few days after we’d landed.
One week is definitely not enough to catch all the sights of Bogotá. The city sprawls as far as the eyes can see, cradled between the chilly peaks of the Andes mountains. We experienced four seasons in one day. Sun, rain, wind, hail - you name it. We never knew what to expect. Thank goodness for our cozy co-working space at CO+LABORA in Usaquén. The area oozes cool. Trendy restaurants and bars adorn cobblestone streets, while storefronts are painted with bright patterns and colors.
When we travel as a team, you never go hungry. Everyone is eager to try everything! This time it was arepas, empanadas, pescado frito, ceviche, bunuelos, arequipe, and, of course, coffee!
While we do work a bit and the face-to-face interactions are invaluable, we also play a lot. Our team has an amazing adventurous spirit. But there’s also no pressure if a proposed activity is not your jam. For example, only a few of us decided to tackle the mountain of Monserrate. It sits 3,152 m (10,341 feet) above sea level, and it dominates the center of Bogotá. At the top of the mountain rests a church with a shrine, devoted to El Señor Caído. We set out, and it was testing. But in the words of our intrepid leader, Xavier Antoviaque, “This mountain isn’t going to hike itself!” And it didn’t. We used every muscle and every breath to make it to the top. The steep rise in altitude is what makes the hike a beast. The route is scenic and peppered with colorful vendors and their canine friends.
We stopped multiple times, not just to take in the majestic views, but to also catch our breath. But, we did it in the end! And it was worth it. Magnificent gardens lie at the foot of the church. The views are so good that no picture can really do them justice.
Other highlights of the trip included visiting and working at the awesome EduNext offices. We’re so lucky to have such wonderful friends and colleagues like you!
We also visited the beating heart of Bogotá, La Candelaria. The neighborhood‘s narrow streets are adorned with out-of-this-world graffiti, shops selling emeralds, handcrafts, religious artifacts, crystals, and sacred herbs for smudging. This melting pot of culture leads to hotspots like the Gold Museum and Museo Botero. Both showcase absolutely amazing collections. Not to be missed!
Now back to food. Every year we end our week with a special team dinner. Our team dinner this year was nothing short of spectacular. We were treated to course after course at Humo Negro. The chef presented us with his preferred menu. He was full of passion and it just added to the beauty of the experience. The dishes were beyond original, and praised local ingredients. Think “salad” that comes in the form of a ball that pops in your mouth, grilled oysters with burnt cream and seaweed, sea urchin mousse, crispy sea snail with pumpkin seed puree and pickled guatila, chawanmushi with pirarucu, scallops and spirulina, and arracacha with grilled wild berries and yogurt. I would never have been so daring if the food hadn’t been set down in front of me. And man, it’ll remain one of the best memories of food I’ll ever have. Our team laughed and bonded over these strange, surreal dishes. Well done, Humo Negro. Well done, OpenCraft!
On the last night, we had a festive night in. We sat around the fireplace at Xavier, Jill, and Piotr’s Airbnb. Kshitj cooked us a delicious curry and we tried a variety of native Colombian fruits. Some were more palatable than others 😂. Watching everyone pull a variety of faces was priceless.
I can’t believe another conference and co-working week has come and gone. I’ll forever be grateful to be part of this kind, wonderful team and community.
Until next year…
After three years of not seeing each other in the flesh, the OpenCraft team flew to Lisbon, Portugal to attend a well-deserved team retreat and participate in the 2022 Open edX Conference. All OpenCraft team members work remotely — the Conference is always a great occasion for us to meet in person, to work together, and cram in a few team meals and fun activities. Our time at the Conference was preceded by a week-long team retreat around Lisbon, Portugal, where we spent quality time together! Here’s a recap of those two weeks:
Most of the team arrived around the weekend of April 16-17 — coming from all corners of Europe, North America, South America, Africa, Asia, and Oceania. While the majority of the team managed to fly to Lisbon, a few of us unfortunately could not make it, because of Covid-19 and visa-related issues. Sad. We'll see you next year! Still, there were more than 20 of us on-site, all ready to meet and have a good time!
Since the conference venue was located in the town of Carcavelos, roughly 20 km West of Central Lisbon, we decided to rent accommodations around that town to enjoy the weather, the beachfront location, and the relaxed atmosphere of the area. The Lisbon larger metropolitan area has a vast and efficient network of public transit, which made moving to other locations and getting to downtown very easy.
We bundled up in cozy Airbnbs, ready to work (a little), eat (a lot), and spend good times all together. Speaking of work — we rented two nice coworking spaces in nearby Estoril (another prime beachfront town!) to allow team members to catch up on work whenever they wished. Many of us also needed to prepare sessions for the conference, and the coworking spaces proved perfect for this.
During the first week, our days mostly consisted of going to the coworking space in the morning to get some work done, eating lunch together (often with a beach view!), working a little more, and spending the rest of the afternoon and evening doing stuff together. Oh, and we drank lots of strong espresso coffee, and ate unreasonable quantities of Portuguese pastries. Some went for the ubiquitous, sweet egg custard-filled pastel de natas, while others (such as myself) favored salty pastries such as the classic pastel de bacalhau, filled with cod fish. Portuguese take their pastries seriously, I'll tell you that — they're just everywhere!
Here are a few highlights from the first week:
We went on an e-bike tour, visiting a number of locations around Lisbon that offered gorgeous viewpoints of the city and its surroundings, featuring some of the city's brilliant street artwork. Things suddenly took an unexpected turn when our colleague Fox flew over his bike, and broke his arm. Yikes! Thankfully, he was taken good care of, and was able to enjoy the rest of his trip (although in a cast).
A board game night took place at Gabriel, Geoffrey, and Giovanni's place (a.k.a. the G-House). Many games were played, a bottle of fine whiskey was shared (thank you, Xavier!), pizza was eaten, and additional beverages were delivered to the apartment at a late hour. Success!
Some of us went diving in Cascais. After the logistical challenges (no car, no gear, zero knowledge of the area) were sorted out (Uber, gear hire and expertise from Bork), this was worth the effort. Xavier deserves all the credit for this, by the way — without his determined optimism, we never would have even gotten in! The water was cold, but the day was gorgeous. By swimming only a few meters off the coast, we saw octopus, many fishes, starfish, and sea urchins, buried amongst the rocky underwater ravines.
We went for an all-out bar crawl in the traditional neighborhood of Alfama, visiting all sorts of drinking and eating establishments. Which ones? How many? We don't remember exactly… but the food, ginjinha (cherry liqueur), cachaça (sugarcane spirit), and other delicacies were definitely abundant. To the great misfortune of one of our colleagues, one thing we definitely remember is that we did not find any chicken wings.
Following our team retreat, we all attended and participated in the 2022 Open edX Conference, hosted at the beautiful seaside campus of Nova School Of Business and Economics, in Carcavelos. The conference spanned from Tuesday, April 26th to Friday, April 29th — you can review the complete schedule in Sched.
We were truly eager to meet the Community again, and see old faces and new: people from The Centre for Reimagining Learning (tCRIL), friends at edX, team members from other service companies, and many of our clients attended in numbers. What a pleasure it was to reunite with familiar faces, and to meet new members of the community! After a lengthy period of isolation, coming all together again certainly felt like a blessing.
For this year's edition, the OpenCraft team got pretty involved in many aspects of the conference. Some of us had been busy for months helping tCRIL with the conference planning. Some volunteered for on-site help and many of us were invited to present sessions during the conference. In 2022, OpenCraft team members presented 4 hands-on tutorials, 4 breakout sessions, and 3 lightning talks — not bad! We were also the event's reception sponsor for this year.
This year's conference offered four distinct session tracks: Integrations and Extensions, Pedagogy and Instructional Design, Platform and Product, and a Virtual Track for those who could not attend in person. Our sessions touched on various topics, including UI/UX, Micro Front-Ends, platform deployment, LTI, and the Core Committers Program. By the way, all session recordings are available on Open edX's Youtube channel — go watch them!
We also enjoyed attending the excellent sessions prepared by our colleagues, clients, and friends, which explored a wealth of complementary topics. We were equally excited to attend the keynote speeches, and these two in particular:
Ed Zarecor and Jenna Makowski from tCRIL presented the much-awaited "State Of Open edX" keynote (watch here). The talk gave insights on the important changes happening in the Open edX project's governance following the 2U/edX acquisition and the creation of tCRIL, and touched on other important topics such as Core Contributors, and the product vision and evolution of the platform. The talk was concluded with a guest appearance by Racoon Gang CEO Sergiy Movchan, who explained how the Open edX platform can be leveraged to support and maintain educational programs in war-torn Ukraine.
Open Source evangelist Tobie Langel's keynote speech, titled "From Open Governance to Collective Ownership" (watch here), discussed the critical topic of collective ownership of open source software. He argued for the importance of true, community-driven open source projects that are based on openness, collaboration, and equality. Needless to say, as strong open source advocates ourselves, we were quite captivated by Tobie's presentation. A few of us even had the pleasure to sit down with Tobie and discuss some more.
Kudos and special thanks to tCRIL, edX, and every member of the Community who worked hard to make this event a success! We're thrilled to see that the broader Open edX Community is increasingly involved in the project's governance, and in the planning of activities such as the Conference. We're taking steps in the right direction : )
Another definitive highlight during the week of the conference was the OpenCraft-sponsored food & wine tour, organized by yours truly. What better way to mingle and discover Lisbon other than touring historical neighborhoods on foot, eating great food, and drinking great wine? We organized a lucky draw, formed a group of 12 lucky tour guests, and had a wonderful Thursday night walking Lisbon's colorful streets. Our tour guides took us off the beaten path, sharing intriguing anecdotes about Portugal and Lisbon's history in the process. We visited a specialty olive oil shop for some tastings, ate charcuterie in a traditional Portuguese grocery store, and sat down in three (!) different restaurants to sample Lisbon's finest traditional dishes. Needless to say, our stomachs were full, and our heads were now filled with memories. Faithful to what is seemingly becoming a tradition, I took the remaining survivors for a bar-hopping ride to end the night in true Portuguese fashion.
We ended the week with our traditional team dinner, sharing a few last bites of excellent vegetarian food at The Green Affair, a few drinks, and warm goodbyes until next year. It all went in the blink of an eye!
Some of us visited Sintra towards the end of the trip, which is a beautiful and well-preserved castle town near Lisbon that hosts a variety of fascinating historical buildings and stunning natural scenery. A perfect day trip!
Before we knew it, our two weeks in Portugal were over, and it was time to head back home. But what a time we had! We are all very grateful for our presence in Portugal this year, and can't wait to do this all over again next year in Cambridge, USA : ) Thanks to everyone who made this possible!
Photo credits: Gabriel D'Amours, Jill Vogel, Geoffrey Lehée, and Giovanni Cimolin da Silva.
Software development is a complex process. Anyone looking to invest in software for their company wants to know that they are investing well. However, most software development engagements of scale will take place over the course of many months or even years. How can you be sure your software team will meet your needs? We will show you how agile methodology impacts planning and budgets.
The obvious way to write software is to write all of it up front until it meets all the requirements. Companies release the product, and the project is ‘complete.’ For many years in the industry, programmers wrote software this way. However, this came with some problems.
If the software must be ‘complete and finalized’ before release, you cannot use it and reap the benefits it provides. And what’s worse, you may find that once you start using the tools you’ve built, they don’t work the way you imagined they would, even though everything went to plan. For example,
Imagine you were building an app that allows users to automatically create shopping lists based on recipes. You spec out all the requirements, which include the following:
You work with your software development team, they develop these features, and you release your product. You've spent your budget. You get your first several customers, but there’s little enthusiasm. People aren’t making orders as often as you expected. You begin interviewing your customers and ask, “What do you think is missing from the platform?”
The customers say, “I really wish there was a way to pick preexisting recipes and use them. I have to know the recipe already and enter it each time I want the app to figure out what ingredients to buy. It’s great after the first time—I never have to enter the same information twice. But it’s a lot of effort before I even get to the point of purchasing stuff.”
Now, you’re in trouble. You need customers to begin ordering things from the store in order to get your revenue. But customers aren’t entering in the information needed to make the orders, so they never even get that far! How could we have prevented this?
Rather than waiting for your project to be 100% complete, we first plan for the "Minimum Viable Product" or MVP. An MVP is not the final product—but it is a functioning one that allows you to begin using it, marketing it, and understanding how your customers interact with it.
For the shopping list app, this could have been the minimum viable product:
With that, the product already does something useful. It may not be everything you want, but customers can use the shopping list the program generates to shop at their local store.
Every two weeks you meet and plan with the software team. You decide which feature they should focus on for the next two weeks. Developers call this two week period a ‘Sprint,’ because after planning, the developers sit down, and focus only on those features until the sprint is complete. They do not change plans after the sprint starts. At the end of the sprint, they push the latest features and changes to production.
This cadence—planning, sprinting, and releasing—allows you to balance your ever-changing needs with the focus required to build the software. Developers work best with periods of time during which they can focus on their tasks, so the two weeks ensures this. However, the sprint is only two weeks at a time, so there are plenty of opportunities to tweak planning and direction as the project moves forward and we learn more.
This process is known as ‘Iterative Development’ or ‘Scrum.’ The process is key in understanding how agile methodology impacts planning and budgets.
The project begins, and the software team spends the first few sprints working on the MVP, only putting in the two critical features that we selected.
After the MVP goes live, the team starts to work on the next priority feature—the ability to order online. As they’re working on it, you get word back from your customers—they want preexisting recipes, and they want to share them.
As the sprint with online ordering finishes, you tell them to develop the coupon system and price comparison features later. You’ve learned you need a recipe library first. They release the ordering system, and you begin making a little money, even before all of your features are ready. Once the recipe library is finished, you make more money more consistently, even with two more features to develop!
Once we understand the sprint process, we understand that the budgets we set are limited in very specific ways. We can still get a good understanding of what our costs will be, but forming a picture of the ‘full cost’ of a programming project is not as cut and dry as a fixed price.
When we first meet with your team, we draw up plans for your project. We learn what your goals are, and work with you to define your MVP and other needs. We begin researching and create estimates for implementation.
However, by now you know that after the MVP your needs may change significantly. Sometimes, you may even find out your needs change BEFORE the MVP is complete. By trying out early demos, you might find that you come up with better ideas. Thanks to Scrum, we can then change course.
The estimates and timelines we give are based on what it would take to implement the project as we understand it in the initial planning phase. However, we prioritize getting something useful out the door first, and then giving you the flexibility to make changes. This means the final cost will not be known until we perform the work.
As your plans change, we will give you updates letting you know the expected impact of these changes on the project’s timeline. This way you can make informed decisions on what to prioritize.
It is best to think about your budget in terms of ‘how much each month you want to invest in improving the project, and how many months you want to spend engaged in the improvement.’ We will get the MVP out the door as quickly as possible while maintaining best practices. We will have a good idea of that initial timeline.
After that, it’s all improvements, and those improvements may be different from the ones you originally planned. The best part is that if at any point you decide you want to stop development, you will still have a working product. Because of the cycle of iterative development, after every sprint you’ll have an improved, newly released version. You will not leave empty handed even if you have to pause or stop funding the project.
Because of this, by the time you’re finished, you may have spent more or less than you originally planned and we originally estimated. However, with the freedom to stop development and still have a working product, you need not worry about overspending. And with the ability to add changes as you go, you can have confidence that you can adapt to your business’s ever-changing needs.
This blog post was written by our team member Aayush Agrawal
At OpenCraft, we do a lot of feature development for our clients. While the Open edX platform is great and feature-packed out of the box, the best part is its extensibility. And we take full advantage of that when we need to develop a new feature.
When developing a new feature, we believe the following two considerations are the most important of all:
So, usually, in addition to internal reviews, our code is reviewed by edX. To ease this process, our instance manager monitors repositories and automatically creates sandboxes, allowing testing of the feature without installing the platform locally.
It’s worth mentioning that we are members of edX's prestigious Core Committers program, which means we are involved in the process of designing, implementing, and reviewing new features for the global platform roadmap.
We aim to help our clients with the design process: We talk with them so that we can understand their needs, and then we envision how to fill the gap with a new feature.
At OpenCraft, developing a new feature starts with a technical discovery. This is where we create a document that lays down the scope of the work to be done, a description of our approach as to how to do it, a list of tasks, and how much time it will take. We then send this document to our clients to review and approve, and we’re off!
As already mentioned, we put a lot of effort into designing new features in a way that they can be included in the Open edX codebase. This allows us to keep sources open and guarantees the best possible quality, because edX keeps standards high and reviews contributions rigorously. That’s why discussions with edX and other members in the community are an important part of our work. For example, we participate in Open edX releases preparation, are active on community forums and in Slack, and maintain some popular Open edX extensions.
After having signed off on the scope of the work, it’s a simple task of getting to it!
A good practice in this step is getting all code covered with tests, and reviewed by another developer before merging. We make a lot of use of our open source instance manager and create testing sandboxes for everything. Only after ensuring that everything works as expected, we deploy changes using blue / green strategy, so we can easily roll back in case of unexpected issues.
At OpenCraft, we believe in Open Source. Depending on the work done here, we might be creating new modules like XBlocks and Django Apps in which case we’d upstream them by uploading them to our public GitHub or GitLab accounts for everybody to use and improve.
But some changes require changes to the Open edX platform itself. In this case, after a ticket has been through our thorough internal quality control, we’ll submit it to Open edX Core Committers for review. Core Committers are trusted, long-standing members of the Open edX community who have been granted permission to review and merge code into the Open edX codebase. OpenCraft has multiple Core Committers within its team, which is a great token of trust from edX!
Finally, delivery! Once the work is done, approved, and merged into the platform if needed, we are ready to deliver the finished product. This might mean installing a new XBlock or App that was created, or it might be as simple as redeploying the client’s Open edX instance to include the latest changes.
While the roadmap above is the standard process, it’s not always a straight line. Sometimes we work with features that are interconnected, or maybe we have multiple review passes, or requirements change down the line etc. But no matter what happens, we are always committed to the two pillars of OpenCraft’s success: Quality Code and Open Source.
If you’re interested in having a feature developed for your OpenEdX deployment, feel free to drop us a note! You can contact OpenCraft at this link.
Photo by Yancy Min on Unsplash
This article was written by team member Nizar Mahmoud.
Work often involves a lot of repetitive and time-heavy tasks. For example, at OpenCraft we automate the decommissioning of unneeded servers, the preparation of monthly invoices for our employees, and tasks like sending reminders about project and sprint planning. Since most of these tasks require following a step by step procedure, we work carefully to establish good procedures, and then automate these procedures. Doing these tasks manually takes a lot of time, but by instructing a computer on how to perform these tasks (therefore automating them), we save time.
By automating (almost) everything that can be automated, OpenCraft team members are liberated from mundane and tedious tasks. Accordingly, we can instead focus on challenging work that requires creativity and critical thinking.
Automation not only makes the workspace more enjoyable, but also improves quality, productivity, and security.
Automating tasks improves the quality of our code. One of the most common methods of automation is continuous integration/deployment. Here at OpenCraft, we use continuous integration to ensure that every change made on our maintained repositories is tested. This approach guarantees that every time we change the code, the previous features we added still work, bugs we've fixed before remain fixed, and the quality of the code stays high.
By identifying the issues in the changes early, results can be delivered without any unexpected failures.
Automating routine tasks also improves security. Executing such tasks manually can become boring quickly. When the person is no longer focused on the task at hand, the risk of human error usually increases. Such errors can have a serious impact on security when updating configuration files or applying updates or patches.
Ocim is our hosting platform which makes managing configurations, patches, updates, and customizations easy through automated deployments. Automated deployments help run a number of procedures that ensure proper security on the hosted applications.
Another common method of automation is monitoring for errors or attacks on deployments and alerting team members about those incidents. OpenCraft combines multiple tools to notify the team of any incident, instantly. This way we can address serious issues quickly, and minimize downtime. Since we are a fully remote company with team members all over the world, this means that our team can work around the clock to resolve issues.
Automating tasks results in increased productivity. By automating all tasks that don’t require critical thinking, team members can focus on complex tasks that cannot be solved by machines. Meanwhile, the tiresome work is getting done, without wasting the members’ time... nor our clients' budgets!
Automation also reduces the repetitive act of jumping from task to task (we call it "context switching"), which keeps us more focused.
The benefits of automation are various, including improvements in quality of work, productivity, and security. Even though some time has to be set aside for automating work, it is definitely worth the investment!
Want to learn more about how we work at OpenCraft? You can check out our public handbook. Or get in touch — we’d love to talk with you.
Photo by Eric Krull on Unsplash
This article was written by Jeff Miller, a member of the OpenCraft marketing team.
At OpenCraft, we work daily with top-tier universities. This probably isn’t all that surprising given that we specialize in developing and maintaining custom instances of Open edX, which is an open source course management platform that hosts Massive Open Online Courses (MOOCs) and online learning.
A massive number of institutions worldwide are members of edX.org, with more than 50 who are charter members. And they’re not just using the platform to power MOOCs, the original use case for Open edX. Today, they’re using Open edX to complement residential programs and offer blended learning experiences, especially in the face of the COVID-19 outbreak, because the platform's streamlined authoring experience allows instructors to easily shift to online courses and get them up and running quickly.
So, why are so many turning to the open source Open edX platform and, consequently, OpenCraft? After all, when it comes to learning management systems (LMS), Open edX is far from the only game in town, and prestigious institutions certainly have the budget to purchase proprietary software.
Universities have a dual humanitarian mission of providing high quality instruction and increasing our collective understanding of the world through research, but they still operate in a competitive environment. These institutions are constantly vying against each other for prestige, research funds and talented students. So, just as processes and business models evolve in the corporate world in response to competitive pressure, curriculum and research are constantly evolving at top-tier universities. This is especially critical in the wake of COVID-19, as higher ed institutions are now determining how they’ll continue instruction for the rest of 2020 and into 2021 — online learning will continue to play a key role.
Universities often need to expand, adapt and customize their LMS platform to meet their goals for learning innovation and research projects. Open edX is ideal for this purpose. It’s an open source, massively scalable platform that’s supported by an enthusiastic global community. And though its original use case, of course, was to power MOOCs, the platform has evolved into a powerful, flexible LMS.
For example, here’s some customizations we have done for our university clients:
A great example of a large-scale customization project is LabXChange. You can read much more about that particular project in our LabXChange launch blog post, but, briefly, LabXChange is an online science resource for students, teachers and the general public that we developed for Harvard University. It’s simple for anyone to build and share learning pathways (sort of like mini-courses) from smaller pieces of content that can be easily remixed and reused.
This was a two-year project built on Open edX, and it required extensive customization and new capabilities. This resulted in our contributing several major new Open edX features such as Blockstore (a new storage architecture), Content Libraries version 2, a new XBlock Runtime, anonymous platform access and a new visual assessment editor.
Having worked with dozens of universities over the past seven years, we’ve learned a great deal about how best to work with them.
You have to be patient. The academic world typically moves more slowly than the business world. We’ve had projects that took two years to come into place, from initial discussions to a signed contract.
Additionally, universities’ needs and goals change over time, which often affects the scope and timeline of our projects. Our iterative development approach allows us to be as nimble as our clients, so we can make changes, stay transparent and ensure that projects are delivered on time and with no surprises.
Finally, universities appreciate our commitment to open source and the larger Open edX community. They can expect that our solutions will be reviewed and approved by edX engineers and that they will align with edX's long-term roadmap. After all, it’s much less expensive to maintain new features and capabilities once a feature is merged into Open edX, because then it's maintained by edX and the community as a whole.
We really enjoy working with universities because they’re often pushing the boundaries of what’s been done before, giving us the opportunity to do creative, complex work. Plus, their high quality standards keep us sharp as we work to meet and exceed them, augmenting our expertise and increasing our ability to meet the challenges that all of our clients bring to us.
Learn more about our work with colleges and universities.
Photo by Christopher on Unsplash
This article was written by Jeff Miller, a member of the OpenCraft marketing team.
It’s probably not a surprise that a company that develops open source software values transparency. After all, transparency is one of open source’s biggest benefits. Concerned about the security of the software? Worried about whether it is compatible with other critical systems? Need to understand exactly which services the application relies on? With open source, there’s no need to simply take the word of the vendor or consultant for answers to any of these questions. You can go directly to the source.
Open source principles also diminish the chance of vendor lock-in. Our clients can see their code and can move to another vendor at any time.
Here at OpenCraft, we don’t just believe in the transparency of our code. We believe in transparency within our working environment, as well. And, once again, you don’t have to take our word for it. We make nearly all of our internal guide for operations and policies, the OpenCraft Handbook, available for anyone to read. We’re not alone in having a public handbook. Gitlab, Trello and Basecamp also make theirs accessible to everyone.
If you read it — and we encourage you to do so! — you’ll see that openness is listed first among OpenCraft’s four core values (the other three are quality, commitment and empathy). That’s not an arbitrary ordering. Openness comes first, because it forms the foundation of our company culture.
But while our handbook is publicly available, there are a few things we keep private. Our internal discussions, for the most part, remain internal. Certainly, reviews of pull requests and discussion on public edX Jira tickets are available to people outside the company. But we recognize that our clients have different needs and a different philosophy than we do, so we typically don’t perform client work in public, though internal discussions about projects are available to team members. That said, if a client is open to radical, public transparency of our work with them, we’re happy to oblige!
It’s also important to note that, even internally, we don’t make everything public. Financials, for example, and initial pull requests for new team members remain private. Occasionally, there’s justification for a private one-on-one. But our strong bias is toward transparency.
That said, our default is to practice radical transparency at OpenCraft. Private discussions are rare. In fact, we actively discourage them. Instead, nearly all discussions occur in the open, where anyone in the company can read them.
That may seem extreme. Some might wonder whether everyone really needs to know you’ll be 5 minutes late to a meeting. But just as writing code in the open results in better quality software because others are able to see flaws and improvements that you might overlook, we’ve found that our company runs better when it’s impossible to hide or spin information. When all communications are public, it forces people to think about the entire group in all their conversations, and that fosters a culture of inclusivity that reduces politics and the formation of cliques. Plus, you never know who might need to know something that seems trivial to you. What’s more, if that conversation about something “minor” leads to a broader discussion about something more important, it’s not always easy or natural to move it back into a public forum.
Our radical transparency with internal communications also creates a resource that comes in handy when we add new people to the team or need to pick up work from a colleague who’s out sick or on vacation. Our tools are searchable, so essentially the entire history of the company is readily accessible.
Of course, this level of openness might mean it takes longer to do something. A quick note that you might fire off to a single colleague requires a bit more consideration when you know it will be public to the entire company. But we find that extra consideration to be a feature, not a bug. It makes everyone act more thoughtfully and, in the long run, leads to smoother operations and more collegiality. Sharing information in the open results in clearer, higher quality communications. It’s worth the extra effort.
Another potential problem with radical transparency is that people can become overwhelmed by the constant stream of communications, much of it not relevant to your specific work. Even if you don’t work in a radically open environment like we do, many of you have probably experienced similar problems with Slack and other communications platforms.
So how do people at OpenCraft keep up with so much information and so many direct pings in real time?
The answer is simple: they don’t. We do not expect people to be “always-on”, as we mentioned in our previous post on how we enable remote work.
Writing good code is a creative activity, and people can’t do good creative work without big blocks of uninterrupted time. So long as people look through the main feed a couple of times a day and respond to direct pings within 24 hours (not including weekends — we don’t expect anyone to work weekends), we each make our own schedules. When you’ve worked under these kinds of expectations, you quickly find that the vast majority of communications don’t have to be immediate. For the most part, we work asynchronously.
Additionally, open discussions generate a lot of information and noise, so we don't expect team members to read everything. We provide ways to mitigate the noise effect and for team members to know and choose what is relevant to them. Team members can use email filters to screen out irrelevant conversations. Plus, we recently deprecated our @all email address, and instead use an internal forum with different categories, each with their own level of urgency and response time. Announcements, for example, need to be read within 24 hours. Discussions, on the other hand, can wait a full week and only require a response from those directly pinged. For many other categories, reading their content is entirely optional.
Openness creates better code. And we’ve found it also creates better companies.
Want to learn more about how we run OpenCraft? Read our company handbook. Or drop us a line and let’s video chat. We’d love to hear from you.
Photo by Matt Hardy on Unsplash
This article was written by Jeff Miller, a member of the OpenCraft marketing team
In the midst of the COVID-19 pandemic, hundreds of millions of people have suddenly had to adjust to working remotely, often with no more than a day or two to prepare. Not all companies have responded well. An internal memo sent out by management to Wall Street Journal employees, for example, recently drew a lot of criticism on Twitter. In case you didn’t see it, the memo tells employees to “respond in just a few minutes from a Slack or Google Hangout message” and “keep your phone’s ringer on … now is not the time to screen calls.”
That’s really not the best way to manage remote work. Especially, when you’re remote, people need the freedom to work asynchronously so they can manage their time to be the most productive.
We should know. I’ve been working remotely since 2007, and OpenCraft, itself, has always been a remote-first company, with employees working not just in different states, but in different countries. Even more, we value an open and transparent culture, as our entire company and core values are built upon open source principles.
OpenCraft is proud of our remote-first culture, and we know it's an effective and productive way to run a company for the long term. And since it doesn’t seem likely that most people will be heading back to an office any time soon, we thought it might be helpful to share a bit about our experience.
Obviously, we believe the pros outweigh the cons by a huge margin.
For employers, having a remote workforce means less overhead, because you don’t need to invest in office space, furniture or other necessities of a physical location. Plus, it allows you to access a global talent pool instead of just the folks who live within a reasonable commute to your office.
For employees, it eliminates the time spent commuting, which is huge. Plus you reduce emissions and spend less money on gas or public transit.
You can completely control your own work environment, and, if you don’t want to work from home, you can choose to work somewhere else, like a coffee shop or the library (though certainly not during a pandemic). You can cook lunch, which is especially helpful for people with special dietary needs, and if you need to run a quick errand or let a repair specialist into your house, it’s no big deal.
There are also cons to consider. For those employers who have a nationally or internationally dispersed workforce, you’ll need to stay abreast of tax and labor laws for each employee’s state and country.
Individuals may also feel isolated and can have trouble setting work/life boundaries. While the misconceptions about remote work are that people will be distracted or less productive, the truth is you have to take extra care not to over work. It’s very easy to continue working long past a typical quitting time because your office is just a few steps away from your home life. In a snap you could work a 12-hour day, which we don’t encourage at OpenCraft.
It takes extra work to build a strong, remote culture. Without everyone together in the office every day, building strong ties between teammates requires creativity and a dedicated effort -- it doesn’t just happen on its own.
To help offset this potential issue, we place strong emphasis on clear and concise writing and communication. We also foster complete transparency across our entire company. All of our work communications are open for the entire company to see. We don’t hide behind direct messages. This approach turns out to be very useful. Frequently, we'll have someone jump into an open discussion and provide useful information and context - this couldn't happen if our work conversations were private.
There are other ways to overcome these challenges. Here are a few tips for both employers and teams to make remote work successful.
Certainly, there are Agile experts who strongly recommend having all developers work in the same space, but we’ve been working remotely for years and have successfully operated on a model of two-week work sprints. The key is to find a platform for managing agile software development and tasks that works best for your culture and environment. Commit to strong usage within the company, train everyone thoroughly and ensure that everyone uses it daily.
At OpenCraft, we use Atlassian’s Jira to manage daily work, but there are plenty of options on the market. Some are lightweight, providing very simple task management, while others include chat rooms, document storage and complex to-do lists with dependencies. Whatever platform you choose, make sure everyone documents their work so that others can easily provide support or pick up where their colleagues left off.
Give your employees the freedom to work as it best suits them. Do not expect them to be always on, always available, and ready to text or chat back at the drop of a hat. That’s a recipe for burnout and implies a lack of trust on the part of leadership.
In addition to trusting our team, we work asynchronously because we appreciate a deep and thoughtful approach to work that goes uninterrupted for long stints of time -- and also because our team is dispersed across multiple time zones.
Coding is a creative activity. Developers need long stretches of uninterrupted time to focus in order to do good work. If they’re constantly getting pinged and checking Slack, Skype IMs or email, they’ll never get anything done.
This doesn’t mean people aren’t held accountable. It’s critical to make sure team members get their work done on time. But let your employees figure out what works best for them to accomplish that.
By now, almost everyone has seen the video of Professor Robert Kelly’s 2017 live interview. His toddler swaggers into the room, followed by a baby in a walker and their mother, Jung-a Kim, who heroically wrangles them out of the room.
Find a space in your house or a coworking site where you can work privately. If you have a home office, make sure those who share your living space — whether it’s family or roommates — understand that when you are working, they should only disturb you if it’s an emergency.
Set boundaries for yourself, as well. When your work shares your living space, it can feel like you never really go home. Set a schedule and hold yourself to it.
It feels ironic to talk about isolation right now, when everyone is working to social distance themselves from others. We see the memes and social media posts about people stuck in the house with no immediate plans to head to dinner or a movie. But isolation and loneliness can be a key issue when working remotely.
In the short-term, this probably won’t be an issue. However, as the weeks and months of working remotely pass, you may find yourself feeling lonely. Set aside time to chat with your colleagues about stuff other than work, and make time to get out of the house (only if you’re not on pandemic lockdown, of course).
There’s nothing wrong with going out to lunch with a friend or taking the dog for a walk in the middle of the day with a neighbor (not during a pandemic). Even introverts need human interaction. If you’re working without office mates physically by your side, you’ll want to make a conscious effort to engage with people 1:1 and in person.
For many employees worldwide, once the pandemic passes, work may go back to the office. But it may not. We suspect that many organizations will stick with the remote model as they will see strong productivity gains and employees will welcome the flexibility. The advantages are just too great and, with just a little extra work and thought, the disadvantages can be easily overcome.
Have a great way that your team works remote? Or have more questions about how to make this transition? Drop us a line and let’s video chat. We’d love to hear from you.
Header photo by Tim Trad on Unsplash
This article was written by team member James Tait
The OpenCraft team was present at the 2019 Open edX Conference that was taking place on March 23-26 at University of California San Diego. All OpenCraft team members work remotely - the Conference is always a great occasion for us to meet in person, to work together and to cram in a few team meals and fun activities. Our time at the Conference was followed by a week-long team retreat in Mexico where we spent even more quality time together. Here’s a recap of those two weeks:
Although most of us arrived over the weekend of March 23rd-24th (despite people missing connections due to delays at security!), the Conference itself didn’t kick off until March 26th.
Monday Mar 25 was our first coworking day at UCSD, and kicked off with our weekly sprint meeting. We had a wonderful team meal at Donna Jean, a delicious vegan restaurant in San Diego.
Tuesday was workshop day at the conference, so those who were involved headed over to Center Hall for that while the rest of us continued at the coworking room in The Village, UCSD.
Wednesday was the start of the conference proper and kicked off with breakfast and registration at Center Hall before keynote talks from edX® CEO and founder Anant Agarwal, edX COO Adam Medros, and Director of Learning Science and Engineering at Amazon Candace Thille, punctuated with a brief talk from Ned Batchelder in which several OpenCrafters got shout-outs, and followed by a panel discussion and lunch.
The breakfast and lunch bars were a good opportunity to mix with people from the Open edX community and put faces to names and GitHub handles. There was a healthy mix of in-depth technical discussions, general business talk and friendly chatter which was reflected throughout the conference.
Wednesday afternoon saw the arrival of the talks from the community; several of us gave talks ourselves: Xavier and Seamus co-presented “A Contributor’s Journey - The Impact of Our Work on Others, and on Ourselves”, and Piotr co-presented “Painless Open edX upgrades and maintainable UI customizations”.
When the formalities of the conference were finished for Wednesday, there was a reception at Birch Aquarium. We were greeted with margaritas and invited to walk around the tanks and see the exhibits while enjoying food and drinks. This, again, proved to be a useful networking opportunity, and we were treated to a glorious sunset.
Thursday kicked off with breakfast and juggling, followed by the more serious business of more keynotes: Mark Haseltine, Marco Morales and Nimisha Asthagiri presented The State of the Open edX Platform; Robert Lue gave an inspiring talk about An Open Source Pathway to Personalized and Collective Learning at Scale; Dean Baker talked about A Route for Saving Journalism and other creative work; and Walter Bender rounded up the morning with a thought-provoking piece about How transparent AI can transform learning.
After lunch, there were more community-provided talks. Our CTO Braden MacDonald co-presented a talk with David Ormsbee about the Blockstore Architecture, and team member Jill Vogel talked about Maintainably Extending Open edX: Why, When, How.
Friday was the day of the Developer Summit; for those who didn’t attend, it was a regular work day. Several of us attended a falconry lesson organized by Pooja, which was excellent, as well as providing some breathtaking views over Mesa Valley. We met some beautiful raptors and had a great time flying one of them. In the evening a group of us went along to Mesa Rim bouldering centre to test ourselves against immovable objects!
We made the trip from San Diego to Puerto Vallarta on Saturday March 30th, arriving shortly after midday, which gave us a nice relaxed afternoon to settle in. There was ceviche followed by margaritas by the sea to really get us into el spirito de México!
On Sunday most of us hiked from Boca de Tomatlán to Playa Las Ánimas. It was a glorious sunny day with some stunning beach views.
A couple of common themes in Puerto Vallarta: waiters have repeatedly told us we were ordering too much food, only for us to prove them wrong; seems we really do have an appetite! And a lot of places just aren’t set up to accommodate a group of 10 or more turistas to arrive unannounced - who knew?
